Incorrect Re-INVITE SDP handling when payload type changes

[rafaltelaczynski]

Describe the bug

• incoming INVITE without SDP
• answer with the offer of all codecs presented in 200OK
• ACK is received with single codec selected
• Re-INVITE message is received with exactly the same codec definition but using different payload type
• new payload type is ignored and response to that offer has the same payload type for this codec as was used in initial offer presented in 200OK

E.g.:
Initial offer presented in 200OK:

Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): FreeSWITCH 1728449501 1728449502 IN IP4 172.240.0.1
        Session Name (s): FreeSWITCH
        Connection Information (c): IN IP4 127.0.0.1
        Time Description, active time (t): 0 0
        Media Description, name and address (m): audio 17010 RTP/AVP 102 103 0 8 104 105 101 13
        Media Attribute (a): rtpmap:102 AMR-WB/16000
        Media Attribute (a): fmtp:102 octet-align=0; mode-set=0,1,2; max-red=0; mode-change-capability=2
        Media Attribute (a): rtpmap:103 AMR/8000
        Media Attribute (a): fmtp:103 octet-align=0; mode-set=0,1,2
        Media Attribute (a): rtpmap:0 PCMU/8000
        Media Attribute (a): rtpmap:8 PCMA/8000
        Media Attribute (a): rtpmap:104 telephone-event/16000
        Media Attribute (a): fmtp:104 0-15
        Media Attribute (a): rtpmap:105 CN/16000
        Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute (a): fmtp:101 0-15
        Media Attribute (a): rtpmap:13 CN/8000
        Media Attribute (a): ptime:20

Initial answer in ACK:

Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): - 3769329783 3769329783 IN IP4 127.0.0.1
        Session Name (s): test-session
        Connection Information (c): IN IP4 127.0.0.1
        Time Description, active time (t): 0 0
        Media Description, name and address (m): audio 8904 RTP/AVP 0
        Media Attribute (a): rtpmap:0 PCMU/8000

Re-INVITE offer(exactly the same as initial answer, only payload type is different):

Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): - 3769329783 3769329783 IN IP4 127.0.0.1
        Session Name (s): test-session
        Connection Information (c): IN IP4 127.0.0.1
        Time Description, active time (t): 0 0
        Media Description, name and address (m): audio 8904 RTP/AVP 10
        Media Attribute (a): rtpmap:10 PCMU/8000

answer to Re-INVITE offer(new payload type ignored, using initial value):

Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): FreeSWITCH 1728449501 1728449502 IN IP4 172.240.0.1
        Session Name (s): FreeSWITCH
        Connection Information (c): IN IP4 127.0.0.1
        Time Description, active time (t): 0 0
        Media Description, name and address (m): audio 17010 RTP/AVP 0 104 105 101 13
        Media Attribute (a): rtpmap:0 PCMU/8000
        Media Attribute (a): rtpmap:104 telephone-event/16000
        Media Attribute (a): fmtp:104 0-15
        Media Attribute (a): rtpmap:105 CN/16000
        Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute (a): fmtp:101 0-15
        Media Attribute (a): rtpmap:13 CN/8000
        Media Attribute (a): ptime:20

Intrestingly, new payload type is respected and is being used while sending RTP packets. This issue here is that the other party either rejects this answer as it is invalid(breaking RFC3264), or accepts it and starts sending RTP packets for this invalid payload type.

According to RFC 3264 8.3.2 this should be allowed:

The list of media formats used in the session MAY be changed.  To do
   this, the offerer creates a new media description, with the list of
   media formats in the "m=" line different from the corresponding media
   stream in the previous SDP.  This list MAY include new formats, and
   MAY remove formats present from the previous SDP.  However, in the
   case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session.  However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

and it is working well in exactly the same scenario but when there is SDP present in initial INVITE, so the only difference between the two is that there is no offer in initial INVITE.

To Reproduce
Steps to reproduce the behavior:

1. Plain call with no SDP in initial INVITE
2. Call answered
3. Re-INVITE from originating party with SDP using different payload

Expected behavior
Answer Re-INVITE with 200OK with valid payload type, e.g. 10 in the example

Package version or git hash

• sofia-sip v1.13.17

Trace logs
freeswitch_invalid_payload_type.log

[rafaltelaczynski]

Any idea what might be wrong in this case?

[kuba-gasiorowski]

I haven't dive deeply in the code, but I think this is because the origin in the SDP is the same as in previously sent to the peer:

Request	Origin value
ACK	- 3769329783 3769329783 IN IP4 127.0.0.1
re-INVITE	- 3769329783 3769329783 IN IP4 127.0.0.1

RFC 3264, sec. 8 - Modifing the session:

When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6.

In fact, such request is typically recognized as session refresh request (RFC 4028, sec. 7.4), when also Session-Expires header is present.

I suggest to try to send the re-INVITE with version in origin incremented to indicate this is an update of the session.

[rafaltelaczynski]

Thanks for the suggestion, but this is not the case here unfortunately. PT is still not updated correctly.

Attaching trace from local testing: 20241220_freeswitch_issue_276.zip