Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt

[Kiran Kumar Guduru <[e-mail]>]

Hi Justin,

I was on my biz trip so not able to respond to your mails promptly.

Sorry for the delayed response.

 

The reason you specified seems not suitable in all scenarios.

Please find the scenario explained through below figure

Here Browser supports Opus, G.711, Gateway supports Opus, G.711 and AMR-WB, If we consider a call between a third party application instead of browser, like IMS or RCS application which supports AMR-WB,

Then the call flow will be like,

1.       Browser sends offer with Opus, G.711 as supported codecs in the same order respectively.

2.       Since Gateway supports AMR-WB also, it sends the offer to third party app with Opus, G.711 and AMR-WB in same order respectively. (The reason for moving AMR-WB last is to avoid transcoding, if the remote client supports either Opus or G.711)

3.       If the third party app responds with AMR-WB using its own order of preference in the answer, as explained by you. (Saying some reason of quality or etc). (Since 3GPP specifications allows sending only single codec in answer, the Gateway might receive only AMR-WB)

4.       As per the RFC 3264 Gateway MUST establish the call with remote client using AMR-WB and that of with Browser with Opus, which forces it to do transcoding. (This results in bad user experience).

5.       So most of the Implementations will respond with the codec preferences specified by offerer and try to re-negotiate with its preferences with a re-offer. And that was the reason why RFC 3264 RECOMMENDs to use the codec order same as that specified by the offerer.

 

 

 

 

 

Regards,

Kiran.

 

 

 

From: Justin Uberti [mailto:[e-mail]]
Sent: Wednesday, July 23, 2014 9:13 AM
To: Kiran Kumar Guduru
Cc: franklin blek; [e-mail]; [e-mail]
Subject: Re: Re: Re: New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt

 

 

 

This is a useful example, thanks for explaining this. But I think this is the wrong solution. Quoth RFC3264, S. 7:

 

   When the offerer receives the answer, it MAY send media on the

   accepted stream(s) (assuming it is listed as sendrecv or recvonly in

   the answer).  It MUST send using a media format listed in the answer,

   and it SHOULD use the first media format listed in the answer when it

   does send.

 

Note the use of SHOULD vs MUST.

[KIRAN] section 7 explains about "offerer processing of the Answer". But I think the correct section for my explanation is section 6, " Generating the Answer", which recommonds to use the same order of preference as that in the offer.

   "Although the answerer MAY list the formats in their desired order of

   preference, it is RECOMMENDED that unless there is a specific reason,

   the answerer list formats in the same relative order they were

   present in the offer."

 

The text says "unless there is a specific reason". You have a specific reason. Just do it. 

 

It is far more sensible to change the order of codecs in the answer, than to send a reoffer with changed codecs immediately afterwards.