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

Reply via email to