Re: [rtcweb] RTCWEB needs an Internet Codec

["Mandyam, Giridhar" <[e-mail]>]

>That's not what I said. I said that the *set* of MTI codecs should cover the use cases.
>We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case.

Apologies - inaccurate wording on my part.  I still think it is unrealistic for any suite of MTI codecs to cover all use cases.  I think the QoS-based use case still stands as an example of why this is unrealistic.

> You're not reading the latest draft. That section is now 4.2.6.

The version I linked to from the RTCWEB status pages is -09, which has the relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.7).  If the doc is rapidly evolving, then the use case doc may not be suitable for evaluation of codecs for MTI at this point in time.

> Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbits/sec".

The full text states  "Clients can be on narrowband (10s to 100s of Kbits/sec)".  Does this definition refer to codecs or the underlying access technology?  I think in the context one could reasonably conclude that "narrowband" refers to dial-up or low data rate cellular (e.g. GPRS, GSM HSCSD, 1X).  The text in 4.1 says nothing about bandlimiting of the input voice signal to a codec.  Moreover, the ensuing text states  "Clients can be on variable-media-quality networks (wireless)".  To me, this means that the sub-10 kbps case for voice codecs is still relevant.

> Respectfully ..... the slight advantage in quality that AMR-NB seems to offer over Opus at 8 kbps is very different from the advantage that Opus enjoys over G.711 at 64 Kbits and above.

I don't view the quality advantage as 6 kbps as slight, and implementers still have the option of using Opus at any all data rates without designating it as MTI.  Just as implementers can use AMR-WB, G.722 and so on.  Moreover, the study I cited did not consider codecs such as EVRC-B that can operate in the sub 5 kbps range.  

>>    The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case.

>Neither does it cover the case where there's not enough bits to carry an IP+RTP header every 20 milliseconds. There are cases where WebRTC won't work.

I'm not sure what you are trying to say.  Do you believe the use of Opus will not satisfy the QoS use case?  Or do you believe that the QoS use case is one where WebRTC will simply not work?

-----Original Message-----
From: Harald Alvestrand [mailto:[e-mail]] 
Sent: Thursday, August 30, 2012 12:41 PM
To: Mandyam, Giridhar
Cc: DRAGE, Keith (Keith); [e-mail]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

On 08/30/2012 09:13 PM, Mandyam, Giridhar wrote:
> Hello Harald,
> Can you clarify this viewpoint?  If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice.
That's not what I said. I said that the *set* of MTI codecs should cover the use cases.
We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case.
>    
>
> For instance, use case 4.2.7 - "... the user's provider of cellular access has QoS support enabled.  The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular."
You're not reading the latest draft. That section is now 4.2.6.
>    If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GPP defined networks) falls outside of the operating range where Opus is the best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' curve in http://www.opus-codec.org/comparison/), another codec would be required.
Section 4.1 of the draft defines "narrowband" to be "10s to 100s of 
Kbits/sec".
>
> The study available at http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly shows a significant advantage in MOS scores at 5.9 kbps for  AMR-NB as compared to Opus (Silk).
Respectfully ..... the slight advantage in quality that AMR-NB seems to 
offer over Opus at 8 kbps is very different from the advantage that Opus 
enjoys over G.711 at 64 Kbits and above.
>    The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case.
Neither does it cover the case where there's not enough bits to carry an 
IP+RTP header every 20 milliseconds. There are cases where WebRTC won't 
work.
>
> I think we shouldn't try to mandate codecs to try to cover every single use case.  Rather we should mandate as few as necessary to avoid codec negotiation failure.
Yes. And failure to negotiate an usable codec is a negotiation failure.
>
> -Giri
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Harald Alvestrand
> Sent: Thursday, August 30, 2012 5:51 AM
> To: DRAGE, Keith (Keith)
> Cc: [e-mail]
> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
>
> On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote:
>> Surely that argument extends to every possible codec.
> The set of MTI codecs should cover the set of use cases that have been identified.
> Additional MTI codecs that don't cover new use cases shouldn't be added.
>
> I believe the use case "distributed music band" in draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711.
>
>> If the codecs supported by both endpoints do not supply the characteristics needed for the communication, then you will get interoperability failure.
>>
>> If I want more bandwidth or quality than OPUS supplies, then I will also get interoperability failure.
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Harald Alvestrand
>>> Sent: 30 August 2012 11:56
>>> To: [e-mail]
>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
>>>
>>> The counterpoint is that having G.711 as the only MTI means that you
>>> get interoperability failure for any application in which G.711 sound
>>> quality is not acceptable.
>>>
>>> This includes all applications involving music.
>>>
>>> On 08/29/2012 06:30 PM, Randall Gellens wrote:
>>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote:
>>>>
>>>>>    I would argue G.711 should be the MTI codec. The rest can be left
>>>>> up to browser implementers.
>>>> I agree.
>>>>
>>>>>    We can argue all we want, but the best royalty free low bitrate
>>>>> codec available will be the one everybody supports.
>>>> Very good point, and why we should mandate only one audio codec.
>>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb