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
