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?

• 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.

• 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.

Sip-implementors mailing list

Reply via email to