Rakesh <rak...@gmail.com> 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
Sip-implementors mailing list