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

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