Re: [Sip-implementors] Codec Negotiation issue

[Dale R. Worley]

Rakesh  writes:
> 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?

As Paul notes, some "middlebox" in the call is adding codecs to the
re-INVITE.  As such, it is prepared to transcode between EVS (to B) and
AMR-WB (to A).  It appears that it actually is doing the transcoding,
but the problem is that the transcoding is not done well.  According to
the rules of SIP this is acceptable, but of course, the customer
experience is poor.

Ideally, the middlebox should either be improved to do the transcoding
well, or not add AMR-WB as a codec when the original re-INVITE contained
only AVR.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Codec Negotiation issue

[Paul Kyzivat]

On 2/22/18 3:34 AM, Rakesh wrote:

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?


In general, if the UA offers some codecs, those are the ones it is 
prepared to use. A proxy is not permitted to alter those. If it did, it 
would risk a situation where the codec selected in the answer isn't 
supported by the offerer.


I gather that this is an IMS case, and that the middle box that is 
altering the offer is a B2BUA. In that case it takes on the 
responsibility of making things right between the two sides of the call. 
When it adds codecs, that implies that it is prepared to transcode 
between them if necessary. And I presume that is what must happen in the 
second case.


This sort of behavior isn't covered by any standards. Hardly any 
behavior of B2BUAs is covered by standards, except that the B2BUA must 
follow the rules for a UA independently on each "side".


The result you see is a consequence of what the middle box did, and can 
be considered a quality of implementation issue. It may be exactly what 
was intended.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Codec Negotiation issue

[Rakesh]

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 .  Audio Only 1

   Alice wishes to establish an audio session with Bob using either PCMU
   codec or iLBC codec with 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
.






Johnston & SparksInformational  [Page 8]

--

  RFC 4317
   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 
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

Re: [Sip-implementors] Codec Negotiation issue

[Asim Sulaiman]

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

[Sip-implementors] Codec Negotiation issue

[Rakesh]

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