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
