Hi Richard, thanks for your answer.
I totally agree to you when you interprete this as a change of payload type number from 118 to 8. But I think it is also a legitimate view, that this Re-Invite does not represent a change of payload type number, but a change of the attributes of payload 8. So in this case, parameters of codec 118 did not change, but only the parameter of 8 changed. Is this actually possible that different payload type numbers have the same attributes? Best Regards Philipp Schöning Am Mo., 29. Okt. 2018 um 08:06 Uhr schrieb Richard Phernambucq < r.phernamb...@cuperus.nl>: > Hi Philipp, > > According to RFC 3264 the server sending the Re-Invite is wrong. See > chapter 8.3.2 (Changing of 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. > > So changing the payload type number from 8 to 118 during the session is > not allowed. It would have been allowed though if payload type number > 118 wasn't already in use (see same chapter): > > (...) 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 > > > > Best regards, > Richard Phernambucq > > > > On 27-10-2018 14:52, Philipp Schöning wrote: > > Hi all, > > > > we saw a SIP implementation violating the SDP offer/answer procedure when > > answering a Re-Invite. > > > > Here is the signalling: > > > > Server Client > > > > > > > > +----------------INVITE---------------------> > > > > m=audio 18410 RTP/AVP 8 100 118 > > > > b=AS:87 > > > > b=RS:1087 > > > > b=RR:3262 > > > > a=rtpmap:8 PCMA/8000 > > > > a=fmtp:8 vad=no > > > > a=rtpmap:100 telephone-event/8000 > > > > a=fmtp:100 0-15 > > > > a=rtpmap:118 PCMA/8000 > > > > a=gpmd:118 vbd=yes > > > > a=sendrecv > > > > > > > > <----------------200 OK---------------------+ > > > > m=audio 9158 RTP/AVP 8 118 100 > > > > a=rtpmap:8 PCMA/8000 > > > > a=fmtp:8 vad=no > > > > a=rtpmap:118 PCMA/8000 > > > > a=rtpmap:100 telephone-event/8000 > > > > a=fmtp:100 0-15 > > > > a=sendrecv > > > > > > > > +-----------------Re-Invite-----------------> > > > > m=audio 18410 RTP/AVP 8 > > > > a=rtpmap:8 PCMA/8000 > > > > a=gpmd:8 vbd=yes > > > > a=silenceSupp:off - - - - > > > > > > > > <----------------200 OK---------------------+ > > > > m=audio 9158 RTP/AVP 118 > > > > a=rtpmap:118 PCMA/8000 > > > > a=sendrecv > > > > > > In the last 200OK Client is sending a Payload type (118) which was not > > offered in the Re-Invite. The Re-Invite is generated when the SIP Server > is > > detecting a fax transmission and applies ITU V.152 (Voice Band Data), > this > > is also how gpmd Attribute is introduced. > > > > > > The SIP Client vendor commented this on the case: > > > > *"after call is answered (media session is established), provider > > renegotiates codec set and changes PCMA codec description bound to > payload > > 8 with the description which was bound to payload 118 in initial > > negotiation of media session.* > > > > *It causes conflict, because new description of PCMA codec is already > bound > > to payload 118 in initial offer/answer.* > > > > > > *Voip provider can configure own side of trunk and avoid usage of > > non-standard extensions in payload description (remove unnecessary > > duplication of codecs). Also, provider need to preserve payload > definitions > > when renegotiate media session."* > > > > > > So is the vendor right by saying that payload description have to be > > preserved during a session? It did not find this in the SDP offer/answer > > RFCs. > > > > We never saw any other vendor having issues with this signalling. > > > > > > Best Regards > > Philipp Schöning > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
