Hi Asim, It is not answer to my question since the section that you refer is not answering my above question. I am aware of this already. Thanks. I need to know any specific order or priority to handle the coded and why not all codec listed is not send back in answer as both A and B support all the EVS, AMR WB, AMR NB?
I think you have not follow the scenario mentioned above. 2.6 <https://tools.ietf.org/html/rfc4317#section-2.6>. Audio Only 1 Alice wishes to establish an audio session with Bob using either PCMU codec or iLBC codec with RFC2833 <https://tools.ietf.org/html/rfc2833> tones, but not both at the same time. The offer contains these two media streams. Bob declines the first one and accepts the second one. If both media streams had been accepted, Alice would have sent a second declining one of the streams, as shown in Section 4.3 <https://tools.ietf.org/html/rfc4317#section-4.3>. Johnston & Sparks Informational [Page 8] ------------------------------ <https://tools.ietf.org/html/rfc4317#page-9>RFC 4317 <https://tools.ietf.org/html/rfc4317> SDP Offer/Answer Examples December 2005 [Offer] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 51372 RTP/AVP 97 101 a=rtpmap:97 iLBC/8000 a=rtpmap:101 telephone-event/8000 [Answer] v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 49170 RTP/AVP 97 101 a=rtpmap:97 iLBC/8000 a=rtpmap:101 telephone-event/8000 BR/// Rakesh Kumar Mohanty On Thu, Feb 22, 2018 at 2:25 PM, Asim Sulaiman <asim.sulai...@emircom.com> wrote: > Please have a look to RFC 4317 and Section 2 > > Regards, > Asim Sulaiman > ________________________________________ > From: sip-implementors-boun...@lists.cs.columbia.edu [ > sip-implementors-boun...@lists.cs.columbia.edu] on behalf of Rakesh [ > rak...@gmail.com] > Sent: Thursday, February 22, 2018 12:34 PM > To: sip-implementors > Subject: [Sip-implementors] Codec Negotiation issue > > Hi Expert, > > I have a scenario here can anyone help me to undrstand is the behaviour is > correct on both cases? > > FIRST CASE: > • User A calls User B > • Negoziation for EVS codec > • User A put in hold User B > • REINVITE from User A, contains sendonly, with only EVS (codec negotiated > and used). > • REINVITE arrives to User B, it contains sendonly with all the codecs > handled by volte network in the following order: EVS, AMR WB, AMR NB. > • User B answer with 200 OK just with EVS and the call has not any call > quality issue. > > SECOND CASE: > • User B put in Hold User A > • User B sends REINVITE with sendonly containing only EVS, > • REINVITE arrives to User A with sendonly and it contains all the VoLTE > codecsin the following order: AMR WB, EVS, AMR NB. > • User A answer with 200 OK recvonly that contains only AMR-WB because is > the first in the list and the call quality has degraded > > So is the codec negotiation in both cases OK I am asking since in one case > call quality is OK and in other case call quality is NOK? > > Any RFC standard or reference to understand completely the codec order and > priority to handle? > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ________________________________ > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously received this message, > please delete it immediately and notify the sender. The recipient > acknowledges that EMIRCOM, as the case may be, are unable to exercise > control or ensure or guarantee the integrity of/over the contents of the > information contained in e-mail transmissions and further acknowledges that > any views expressed in this message are those of the individual sender and > no binding nature of the message shall be implied or assumed unless the > sender does so expressly with due authority of EMIRCOM. Before opening any > attachments please check them for viruses and defects. > > ________________________________ > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously received this message, > please delete it immediately and notify the sender. The recipient > acknowledges that EMIRCOM, as the case may be, are unable to exercise > control or ensure or guarantee the integrity of/over the contents of the > information contained in e-mail transmissions and further acknowledges that > any views expressed in this message are those of the individual sender and > no binding nature of the message shall be implied or assumed unless the > sender does so expressly with due authority of EMIRCOM. Before opening any > attachments please check them for viruses and defects. > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
