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

The "problem" of transcoding is easily avoided on the Gateway by offering the same codecs as the browser does. If additional codecs are added, the Gateway must be able to transcode to those codecs.  If doing so is undesirable, it should not include them.

On Aug 12, 2014, at 2:51, "Harald Alvestrand" <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:

Kiran, it is not clear to me what you consider the right result in your scenario. Do you want to end up with G.711 or do you want to end up with transcoding?

G.711 gives you bad sound quality and lots of wasted bandwidth.
Opus/AMR-WB + transcoding gives you good sound quality, but load on the gateway and some added delay.

What is the result you want, and what is the reason for saying that this is the right result?

Harald


On 08/12/2014 10:52 AM, Kiran Kumar Guduru wrote:

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.



<mime-attachment.gif>




Regards,
Kiran.



From: Justin Uberti [mailto:juberti@google.com]
Sent: Wednesday, July 23, 2014 9:13 AM
To: Kiran Kumar Guduru
Cc: franklin blek; public-webrtc@w3.org<mailto:public-webrtc@w3.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
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.







<mime-attachment.gif>