99 and 101 are for dynamic payloads. Notice that it is supported by both; they just assigned different numbers to it.
See RFC 3264 and RFC 4566 for more details concerning the dynamic payloads. > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar > Chaudhuri > Sent: Tuesday, November 04, 2014 2:20 PM > To: ankur bansal > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query regarding SDP negotiation > > Hi Ankur, > Thanks for your clarification. My question still remains. > > In the offer from A does not have the support for payload no 101. So why > you are saying it A SHOULD use it towards B instead of BYE. where only B has > mentioned any payload support on 101. What is the basis of A should do that > activity ? Is it best possible SDP negotiation in case not exact matching ? > > Moreover how will B sends the telephony event with payload 99. B has not > mentioned it support for payload 99. > > Thanks > > Sourav > > > On Tuesday, 4 November 2014 9:48 PM, ankur bansal > <abh.an...@gmail.com> wrote: > > > > Hi Saurav > > I believe there is no issue due to rtpmap as its required only for dynamic > payloads and not for static payloads . > Reason of UE A sending BYE could be mismatch in payload no for telephony > event . > A is sending 99 but B is sending 101 .So A finds this wrong and send BYE But > UE Ashould not send BYE and accept this answer sending telephony events > with payload no 101 instead of 99 which is expected by UE B. > And UE B needs to send telephony events with payload no 99 towards UE A. > > Hope this helps > > > Thanks & Regards > Ankur Bansal > > > > On Tue, Nov 4, 2014 at 9:12 PM, Sourav Dhar Chaudhuri > <sourav_mi...@yahoo.co.in> wrote: > > Hi, > > I am observing a behavior SDP negotiation. In the Below Example just > After Media Negotiation. A is sending BYE without any media flow . Please > refer the below call flow & my query. > > > > > >A --------------------------- INVITE with SDP > >-------------------------> B > > > >########## SDP details in Offer ############## > > > >v=0 > >o=- 1414764441 1414764441 IN IP4 172.29.62.182 s=Basic Session c=IN IP4 > >172.29.62.182 > >t=0 0 > >m=audio 37620 RTP/AVP 18 8 0 99 106 107 > >a=rtpmap:99 telephone-event/8000 > >a=fmtp:99 0-15 > >a=rtpmap:106 PCMU/8000 > >a=rtpmap:107 PCMA/8000 > >a=ptime:20 > > > >A <------------------------- 100 Trying > >-------------------------------------- B > > > >A <------------------------ 180 Ringing > >(unreliable)------------------------------------- B > > > >A <------------------------ 200 OK with SDP > >------------------------------ B > > > >########## SDP details in Answer ################ > > > >v=0 > >o=0000000000 37448557 1 IN IP4 172.29.62.11 > >s=- > >c=IN IP4 172.29.62.11 > >t=0 0 > >m=audio 53378 RTP/AVP 8 101 > >a=sendrecv > >a=ptime:20 > >a=rtpmap:101 telephone-event/8000 > >a=fmtp:101 0-15 > > > >A -------------------------- ACK > >-------------------------------------------> B A > >-------------------------- BYE > >------------------------------------------> B > > > >the call is getting disconnected without any media transfer. > > > >I can see there are six codecs [ 18 8 0 99 106 107 ] with attribute for only for > three [ 99 106 107 ] in SDP offer. Those three [ 99 106 107 ] only having > rtpmap details. > > > >But in SDP answer two codec [ 8 101 ] with attribute for only [ 101 ]. The > rtpmap is also for only [ 101 ]. > > > >So is the A is behaving correctly ? Whether there is failure in SDP > negotiation? If yes then why? _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
