Subject: Re: [Rum] Distinguishing RUE and Provider requirements

From: James Hamlin <[email-masked]>
Date: Mon, 4 Nov 2019 12:56:21 +0000

Paul

In the draft-ietf-rum-rue-00, there's an exemption from VP8 support for providers but no exemption from Opus support. The implication is that, in a call from the PSTN using Voice Carry Over, the provider must offer OPUS even though the audio content is constrained to 8bit*8kHz PCM over the PSTN. I don't recall seeing any argument for requiring transcoding in this case; there would be no benefit in audio quality.

Best regards

James

________________________________________
From: Rum <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: 01 October 2019 20:15
To: [email-masked]
Subject: [Rum] Distinguishing RUE and Provider requirements

In the discussion thread that followed the attached message it started
to become apparent that there is a need to distinguish the requirements,
and/or requirement strength, that apply to the RUE itself from those
that apply when a RUE connects to a VRS Provider.

Now that we have a wg draft to work from, I would like to see people
step forward and make proposal(s) for what those differences should be.

While the prior discussion focused on codecs, please also consider what
else might need to differ.

        Thanks,
        Paul

-------- Forwarded Message --------
Subject: [Rum] Codec requirements in draft-rosen-rue-01
Resent-From: [email-masked]
Date: Mon, 12 Aug 2019 16:20:51 -0400
From: Paul Kyzivat <[email-masked]>
To: [email-masked]

draft-rosen-rue-01 changes the video codec requirements. It now simply
references webrtc RFC7742.

RFC7742 distinguishes three types of endpoints: "WebRTC browser",
"WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes
that each end is one of these.

Is the expectation here that both the RUE and the provider comply with
one of these? In particular, that the provider may simply be a
"WebRTC-compatible endpoint? Notably:

    "WebRTC-compatible endpoints" are free to implement any video codecs
    they see fit.  This follows logically from the definition of "WebRTC-
    compatible endpoint".  It is, of course, advisable to implement at
    least one of the video codecs that is mandated for WebRTC browsers,
    and implementors are encouraged to do so.

Similarly, the audio requirements have been changed to reference webrtc
RFC7874. That one doesn't have the distinction between "WebRTC browser",
"WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the
same requirements to all. In particular, it requires OPUS support. I
don't know why it doesn't make the same endpoint distinctions as for video.

I think simply referencing these documents isn't sufficient. Seems like
we need a more nuanced specification of what is required, though we may
still reference these docs with qualifications.

        Thanks,
        Paul

--
Rum mailing list
[email-masked]
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0

--
Rum mailing list
[email-masked]
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0

---

From: Brian Rosen <[email-masked]>
Date: Mon, 4 Nov 2019 10:33:21 -0500

Mandatory to Implement doesn’t mean mandatory to use.  In the example of an incoming call from the PSTN, offering G.711 only is appropriate, and transcoding would not be advisable.

The IETF folk understand MTI, but perhaps some explanatory text would be helpful in the document.

Brian

> On Nov 4, 2019, at 7:56 AM, James Hamlin <[email-masked]> wrote:
> 
> Paul
> 
> From: Rum <[email-masked] <mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0 <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0>
> 
> --
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0 <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0>
> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Nov 2019 10:39:50 -0500

The point is that if we say it’s OK not to implement Opus, it means we will still be using G.711 in 2120, long after the last 3,000 Hz toll facility has crumbled into dust.

By saying Opus is Mandatory to Implement, it means you can feel free to use G.711 if that’s what is offered, but when you look in the other direction you are able to accept a more modern codec. Also, Opus is infinitely better for people with partial hearing loss than G.711 - it can be the difference between being able to still use audio, being able to use just a CTS service, or if needed a full VRS service. These are the kinds of things we think about in the IETF to support legacy networks while creating useful services that are not simply replicas of legacy services.

> On Nov 4, 2019, at 10:33 AM, Brian Rosen <[email-masked]> wrote:
> 
>> On Nov 4, 2019, at 7:56 AM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Paul
>> 
>> Resent-From: [email-masked] <mailto:[email-masked]>
>> From: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/rum

---

From: James Hamlin <[email-masked]>
Date: Mon, 4 Nov 2019 16:23:04 +0000

Thanks Brian

I understand your interpretation of MTI, but I know that someone writing a test schedule based on the RUM document will write a test that expects to see all MTI codecs in any offer SDP; and from reading the RFCs it will be difficult to positively show that they are wrong.

So I agree that some explanatory text would fix this.

James

________________________________
From: Brian Rosen <[email-masked]>
Sent: 04 November 2019 15:33
To: James Hamlin
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [Rum] Distinguishing RUE and Provider requirements

Brian

On Nov 4, 2019, at 7:56 AM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

Paul

Best regards

James

________________________________________
From: Rum <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Sent: 01 October 2019 20:15
To: [email-masked]<mailto:[email-masked]>
Subject: [Rum] Distinguishing RUE and Provider requirements

       Thanks,
       Paul

-------- Forwarded Message --------
Subject: [Rum] Codec requirements in draft-rosen-rue-01
Resent-From: [email-masked]<mailto:[email-masked]>
Date: Mon, 12 Aug 2019 16:20:51 -0400
From: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>

       Thanks,
       Paul

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Bi037ncYkGLDqRgIKBuu8VhgsDlD2z_xAy0Yvgpkik9j3_SwXmvpWpRQ7OutVSaBAaChuS42DJ3dBcx3O1_XYHu82ah9COcj5k8eMAjsbWoOy95Oqf-YiiE5gQ,,&typo=0>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 4 Nov 2019 11:36:30 -0500

I’ll add some explanatory text.

I think the example you gave is probably a good illustration of MTI vs MTU.

Brian

> On Nov 4, 2019, at 11:23 AM, James Hamlin <[email-masked]> wrote:
> 
> Thanks Brian
> 
>> https://www.ietf.org/mailman/listinfo/rum <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Bi037ncYkGLDqRgIKBuu8VhgsDlD2z_xAy0Yvgpkik9j3_SwXmvpWpRQ7OutVSaBAaChuS42DJ3dBcx3O1_XYHu82ah9COcj5k8eMAjsbWoOy95Oqf-YiiE5gQ,,&typo=0>
>

---

From: Keith Drage <[email-masked]>
Date: Mon, 4 Nov 2019 18:38:02 +0000

Out of interest, do you have any reference to research papers that have 
evaluated different codecs for use by the hard of hearing, and in 
particular that justify the statement "Opus is infinitely better for 
people with partial hearing loss than G.711".

Keith

On 04/11/2019 15:39, Eric Burger wrote:
> The point is that if we say it’s OK not to implement Opus, it means we 
> will still be using G.711 in 2120, long after the last 3,000 Hz toll 
> facility has crumbled into dust.
>
> By saying Opus is Mandatory to Implement, it means you can feel free 
> to use G.711 if that’s what is offered, but when you look in the other 
> direction you are able to accept a more modern codec. Also, Opus is 
> infinitely better for people with partial hearing loss than G.711 - it 
> can be the difference between being able to still use audio, being 
> able to use just a CTS service, or if needed a full VRS service. These 
> are the kinds of things we think about in the IETF to support legacy 
> networks while creating useful services that are not simply replicas 
> of legacy services.
>
>> On Nov 4, 2019, at 10:33 AM, Brian Rosen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Mandatory to Implement doesn’t mean mandatory to use.  In the example 
>> of an incoming call from the PSTN, offering G.711 only is 
>> appropriate, and transcoding would not be advisable.
>>
>>> In the draft-ietf-rum-rue-00, there's an exemption from VP8 support 
>>> for providers but no exemption from Opus support. The implication is 
>>> that, in a call from the PSTN using Voice Carry Over, the provider 
>>> must offer OPUS even though the audio content is constrained to 
>>> 8bit*8kHz PCM over the PSTN. I don't recall seeing any argument for 
>>> requiring transcoding in this case; there would be no benefit in 
>>> audio quality.
>>>
>>> Best regards
>>>
>>> James
>>>
>>> From: Rum <[email-masked] <mailto:[email-masked]>> on 
>>> behalf of Paul Kyzivat <[email-masked] 
>>> <mailto:[email-masked]>>
>>> To:[email-masked] <mailto:[email-masked]>

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2019 10:01:41 -0500

To name a few:

Mantokoudis, Georgios; Kompis, Martin; Dubach, Patrick; Caversaccio, Marco; Senn, Pascal, Speech Perception Benefits of Internet Versus Conventional Telephony for Hearing-Impaired Individuals, https://www.jmir.org/2012/4/e102/ <https://www.jmir.org/2012/4/e102/>

Wältermann, M.; Raake, A.; Möller, S., Quality Dimensions of Narrowband and Wideband Speech Transmission, https://www.ingentaconnect.com/content/dav/aaua/2010/00000096/00000006/art00009 <https://www.ingentaconnect.com/content/dav/aaua/2010/00000096/00000006/art00009>

Hannu Pulakka, Laura Laaksonen, Paavo Alku, Quality Improvement of Telephone Speech by Artificial Bandwidth Expansion – Listening Tests in Three Languages, https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf <https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf>

Yang, Xiangui, Effects of Digital Audio Quality on Students' Performance in LAN Delivered English Listening Comprehension Tests, https://etd.ohiolink.edu/pg_10?0::NO:10:P10_ACCESSION_NUM:ohiou1236796324 <https://etd.ohiolink.edu/pg_10?0::NO:10:P10_ACCESSION_NUM:ohiou1236796324>

> On Nov 4, 2019, at 1:38 PM, Keith Drage <drageke=[email-masked]> wrote:
> 
> Out of interest, do you have any reference to research papers that have evaluated different codecs for use by the hard of hearing, and in particular that justify the statement "Opus is infinitely better for people with partial hearing loss than G.711".
> 
> 
> 
> Keith
> 
>>> On Nov 4, 2019, at 10:33 AM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 6 Nov 2019 06:34:30 +0000

Here is one more, from AT&T and Gallaudet University 2016.

https://tap.gallaudet.edu/IPTransition/Wideband%20Audio/

Regards

Gunnar

Den 2019-11-05 kl. 16:01, skrev Eric Burger:
To name a few:

Mantokoudis, Georgios; Kompis, Martin; Dubach, Patrick; Caversaccio, Marco; Senn, Pascal, Speech Perception Benefits of Internet Versus Conventional Telephony for Hearing-Impaired Individuals, https://www.jmir.org/2012/4/e102/

Wältermann, M.; Raake, A.; Möller, S., Quality Dimensions of Narrowband and Wideband Speech Transmission, https://www.ingentaconnect.com/content/dav/aaua/2010/00000096/00000006/art00009

Hannu Pulakka, Laura Laaksonen, Paavo Alku, Quality Improvement of Telephone Speech by Artificial Bandwidth Expansion – Listening Tests in Three Languages, https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf

Yang, Xiangui, Effects of Digital Audio Quality on Students' Performance in LAN Delivered English Listening Comprehension Tests, https://etd.ohiolink.edu/pg_10?0::NO:10:P10_ACCESSION_NUM:ohiou1236796324

On Nov 4, 2019, at 1:38 PM, Keith Drage <drageke=[email-masked]<mailto:drageke=[email-masked]>> wrote:

Keith

On Nov 4, 2019, at 10:33 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Paul

Best regards

James

       Thanks,
       Paul

-------- Forwarded Message --------
Subject: [Rum] Codec requirements in draft-rosen-rue-01
Resent-From: [email-masked]<mailto:[email-masked]>
Date: Mon, 12 Aug 2019 16:20:51 -0400
From: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>

       Thanks,
       Paul

--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288