Hello dear team.
Could you please help determine if RFC 3264 violated in the following scenario? Unfortunately, I wasn’t able to find appropriate email thread to answer my question. And I'm sorry for lengthy explanation. Scenario. 1) PartyA creates a dialog to SIP Server (further – “SIPS”; it is B2BUA; application server; it does not generate SDP by itself, only re-sends the offers between the parties) 2) SIPS creates a dialog to PartyB 3) Offer from PartyA: “v=0 o=Sonus_UAC 11094 21605 IN IP4 10.113.254.130 s=SIP Media Capabilities c=IN IP4 10.113.254.130 t=0 0 m=audio 27282 RTP/AVP 8 18 2 102 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:2 G726-32/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:102 0-15 a=sendrecv a=ptime:20” Please note that *102* is mapped to telephone-event 4) Offer from PartyB: “v=0 o=- 272923319 1 IN IP4 10.113.248.23 s=phone-call c=IN IP4 10.113.248.23 t=0 0 m=audio 14530 RTP/AVP 8 102 a=rtpmap:8 pcma/8000 a=ptime:20 a=rtpmap:102 telephone-event/8000 a=fmtp:102 0-15 a=sendrecv” 5) Session is started, no issues 6) SIPS now ends the dialog to PartyB and creates new one to PartyC 7) Dialog between PartyA and SIPS remains 8) PartyC in INVITEd with no SDP and responds with its offer: “v=0 o=- 272961713 1 IN IP4 10.113.248.24 s=phone-call c=IN IP4 10.113.248.24 t=0 0 m=audio 11688 RTP/AVP 8 101 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv” Please note, now *101* is mapped to telephone-event 9) This offer is used in the re-INVITE towards Party A Can you please tell if “old” mapping of 102-to-telephone-event should be present in this re-INVITE? --- My opinion is that mapping may be absent and no RFC violation happens. While my opponent says that because of the following quote: “8.3.2 Changing the Set of Media Formats … 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” From my point of view, “mapping” is not violated in terms that 102 was NOT mapped to some different codec like g711; this mapping was simply omitted. And it is allowed to add, remove media formats as well as map multiple numbers to the same codec. --- Could you please tell if, in the given scenario, the mapping of 102-to-telephone-event should (MUST?) be present in the subsequent re-negotiations with PartyA? Can you please also tell the meaning of “mapping from a particular dynamic payload type number to a particular codec” from RFC? Does it mean that once number-to-codec mapping appears it must not be changed as a mapping fact? Or does it mean that it also has to be present in all further offers? Thank you very much. Best regards, Oleksandr Fadieiev. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
