Hi, I have observed two points here,
1. UA A doing wrong here in SDP Offer Here dynamic payload is used for registered CODER ALAW(8) & uLAW(0) & repetition of the same coder with different payload two times(one registered payload (e.g. 8,0) and one dynamic payload(e.g. 106,107)). > >a=rtpmap:106 PCMU/8000 > >a=rtpmap:107 PCMA/8000 2. UA A can tear down call by BYE( So it is not violation of RFC) if UA not satisfied with SDP answer from UA B Regards, Rasik Jesadiya On Wed, Nov 5, 2014 at 4:30 PM, Jan Bollen <jan.bol...@scarlet.be> wrote: > > Hi Sourav, > > Well, yes, there might be an indication in the BYE message or the UA's > error log why the BYE is sent and/or why no media has been exchanged. If a > media mismatch is the cause, one might have expected a 4XX response instead. > You need a closer look at UA A to determine why it sends a BYE if that is > the problem. > > cheers, > Jan > > On 5/11/2014 9:24, Sourav Dhar Chaudhuri wrote: > > Hi Brett & Ankur, > At first thanks to both of you for your prompt answer. > > So after considering RFC 3264 ( importantly the section 8.3.2 mentioned in > Ankur's latest reply) & RFC 4566, I came to this conclusion instead of > sending A could have continue the call. > > But my newer question is even by sending BYE for this flow A is not violating > any RFC. Since from the booth RFCs mentioned above the expected behavior > mentioned by Ankur is SHOULD way not in MUST. So A behavior may not the be > best one but also not a violation of RFC. > > Whether my above conclusion is correct? > > Thanks > > Sourav > > > On Wednesday, 5 November 2014 1:20 AM, Brett Tate <br...@broadsoft.com> > <br...@broadsoft.com> wrote: > > > > 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 > <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> > <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> <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 > listsip-implement...@lists.cs.columbia.eduhttps://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
