Thanks Richard for your extensive comments, this helps a lot. You wrote:
> Furthermore, it is acceptable that offerer and answerer end up using > different payload type number for the same codec. In that case the > number indicates the payload type field the offerer/answerer expects to > receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite the > session is actually still valid: both sides send PCMA RTP; the server > fills the payload type field with value 118 and the client with value 8. But in RFC 3264, 6.1 it is stated: > For streams marked as sendrecv in the answer, > the "m=" line MUST contain at least one codec the answerer is willing > to both send and receive, from amongst those listed in the offer. So the "m="line has to contain one payload value of the offer?! Best Regards Philipp Schöning Am Mo., 29. Okt. 2018 um 11:34 Uhr schrieb Richard Phernambucq < r.phernamb...@cuperus.nl>: > Hi Philipp, > > >> Is this actually possible that different payload type numbers have the > >> same attributes? > > Yes, see the second quote from RFC 3264. > > You have a point when you say this is not a change of codecs, but a > change of attributes for the same codec. This is allowed as stated in > RFC 3264 8.3.4 (Changing attributes). But you're not making it easy for > the answerer, especially since the new attributes have already been > negotiated for another payload type number during the original Invite. > To prevent interoperability issues you'd probably use payload type > number 118 in the Re-Invite, instead of changing the attributes for > payload type number 8. > > Furthermore, it is acceptable that offerer and answerer end up using > different payload type number for the same codec. In that case the > number indicates the payload type field the offerer/answerer expects to > receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite the > session is actually still valid: both sides send PCMA RTP; the server > fills the payload type field with value 118 and the client with value 8. > > Actually, according to RFC 3264, it isn't even necessary for the server > to send the Re-Invite. The codec in the Re-Invite offer/answer has > already been negotiated during the original Invite offer/anwer and the > offerer (server) is allowed switch between codecs during a session. This > is stated in chapter 5.1: > > If multiple formats are listed, it > means that the offerer is capable of making use of any of those > formats during the session. In other words, the answerer MAY change > formats in the middle of the session, making use of any of the > formats listed, without sending a new offer. > > > Best regards, > Richard Phernambucq > > On 29-10-2018 10:14, Philipp Schöning wrote: > > 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 > > _______________________________________________ > 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
