Subject: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

From: [email-masked]
Date: Mon, 04 Nov 2019 13:20:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Relay User Machine WG of the IETF.

        Title           : Interoperability Profile for Relay User Equipment
        Author          : Brian Rosen
	Filename        : draft-ietf-rum-rue-01.txt
	Pages           : 28
	Date            : 2019-11-04

Abstract:
   Video Relay Service (VRS) is a term used to describe a method by
   which a hearing persons can communicate with deaf/Hard of Hearing
   user using an interpreter ("Communications Assistant") connected via
   a videophone to the deaf/HoH user and an audio telephone call to the
   hearing user.  The CA interprets using sign language on the
   videophone link and voice on the telephone link.  Often the
   interpreters may be supplied by a company or agency termed a
   "provider" in this document.  The provider also provides a video
   service that allows users to connect video devices to their service,
   and subsequently to CAs and other dead/HoH users.  It is desirable
   that the videophones used by the deaf/HoH/H-I user conform to a
   standard so that any device may be used with any provider and that
   video calls direct between deaf/HoH users work.  This document
   describes the interface between a videophone and a provider.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rum-rue-01
https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 Nov 2019 13:44:34 -0500

The new text in section 6 on Mandatory to Implement is confusing. A 
G.711 call originating in the PSTN is never going to be *originated* by 
a RUE.

Calls *originated* by a RUE should *offer* all MTI codecs including 
OPUS. If the call terminates in the PSTN then OPUS won't be selected in 
the answer.

OTOH, a VRS provider when relaying a call to a RUE that originated in 
the PSTN may offer G.711 and not OPUS. In normal use cases such a call 
will be a VRS call with an interpreter. I *think* in that case audio 
gets relayed to the RUE, in which case continuing G.711 makes sense. But 
does audio from interpreter also go to the RUE? If so, transcoding up to 
OPUS and then mixing in the interpreter might make sense.

So this is heavily entangled in the need for different requirements for 
the RUE and the VRS Provider.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2019 14:08:49 -0500

The Pulakka paper I referenced for Keith might be why one would transcode from G.711 to Opus. However, I would not mandate it.
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>

> On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> The new text in section 6 on Mandatory to Implement is confusing. A G.711 call originating in the PSTN is never going to be *originated* by a RUE.
> 
> Calls *originated* by a RUE should *offer* all MTI codecs including OPUS. If the call terminates in the PSTN then OPUS won't be selected in the answer.
> 
> OTOH, a VRS provider when relaying a call to a RUE that originated in the PSTN may offer G.711 and not OPUS. In normal use cases such a call will be a VRS call with an interpreter. I *think* in that case audio gets relayed to the RUE, in which case continuing G.711 makes sense. But does audio from interpreter also go to the RUE? If so, transcoding up to OPUS and then mixing in the interpreter might make sense.
> 
> So this is heavily entangled in the need for different requirements for the RUE and the VRS Provider.
> 
> 	Thanks,
> 	Paul
> 
> --
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Isaac Roach <[email-masked]>
Date: Tue, 5 Nov 2019 19:22:08 +0000

Sorenson has a concern about making OPUS mandatory to implement as part of the RUM.  We don’t necessarily object to improvements that might have benefits for users in the long-run, but making OPUS mandatory specifically at this time in the RUM seems to be beyond what is necessary to implement the FCC’s interoperability requirements.  There’s nothing inherent in establishing a standard interface between devices and providers that requires implementation of OPUS.  This would instead appear to create a new minimum standard for VRS that goes beyond the FCC’s requirements.  In addition, Sorenson is concerned that mandatory implementation of OPUS would be expensive as it would require implementation of the CODEC on endpoints and backend systems when it would likely not be used in the near future for Relay PSTN G.711 calls. It would more likely be used for P2P calls but that is out of scope per the RUM charter.

We’re happy to discuss the merits of these and other long-term goals and improvements for VRS, but this is not the right place to create new minimum requirements that are not necessary for interoperability.

Thanks,

Isaac

From: Rum <[email-masked]> on behalf of Eric Burger <[email-masked]>
Date: Tuesday, November 5, 2019 at 12:09 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

The Pulakka paper I referenced for Keith might be why one would transcode from G.711 to Opus. However, I would not mandate it.
https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf

On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Paul

On 11/4/19 4:20 PM, [email-masked]<mailto:[email-masked]> wrote:

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

---

From: Richard Shockey <[email-masked]>
Date: Tue, 05 Nov 2019 16:38:39 -0500

This is certainly the place to discuss minimum requirements, interoperability  and conformance with generally accepted Internet standards (read OPUS)
IMHO your argument is <fill in the blank> 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: Rum <[email-masked]> on behalf of Isaac Roach <[email-masked]>
Date: Tuesday, November 5, 2019 at 2:22 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Thanks,

Isaac

Thanks,
Paul

-- Rum mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rum

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2019 16:40:59 -0500

From the Charter at https://datatracker.ietf.org/wg/rum/about/: <https://datatracker.ietf.org/wg/rum/about/:>

RUM will not assume hearing users are on the PSTN.

and (emphasis added):

Devices used in VRS can be used to place point-to-point calls where both communicating parties use sign language. When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers. Both of these uses impose additional requirements on a RUM device and are in scope for this work.

Thus Opus is a sensible Mandatory to Implement.

> On Nov 5, 2019, at 2:22 PM, Isaac Roach <[email-masked]> wrote:
> 
>> On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>> 
[snip]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 5 Nov 2019 16:51:14 -0500

In this case I think the IETF considers OPUS to be the best practice audio codec, its free, small, and efficient.  There is only one Wideband codec that is MTI in the WebRTC specs.  I think it would be very hard to get this profile through the IETF without it.  

This effort, while some of the motivation is from the US FCC, is broader scope, and thus not limited to FCC interoperability requirements.  One of the things that happens when you take work to the IETF consensus process is that it’s hard to limit to some external organizations requirements.  

Brian

>> On 11/4/19 4:20 PM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>
>> [email-masked] <mailto:[email-masked]>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 05 Nov 2019 17:54:01 -0500

+ + 1 and I’d like to add that the requirements here do actually have an international scope.  RUM will certainly be looked at closely by other National Regulatory Authorities looking to support the hearing impaired community writ large.  

To take Brian’s comment further, IMHO it will be impossible to get IESG approval for any IETF specification that does not include OPUS mandatory to implement.  I certainly will not support it. 

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
Date: Tuesday, November 5, 2019 at 4:51 PM
To: Isaac Roach <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Brian

Thanks,

Isaac

Thanks,
Paul

---

From: Richard Shields <[email-masked]>
Date: Tue, 5 Nov 2019 22:54:33 +0000

OPUS looks like an interesting audio codec. Considering that we support older devices, where video is already pushing the limits of CPU and memory usage, making OPUS MTI raises concerns about how well it would perform on older hardware.

Richard

From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: Tuesday, November 5, 2019 2:51 PM
To: Isaac Roach <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

[EXTERNAL] In this case I think the IETF considers OPUS to be the best practice audio codec, its free, small, and efficient.  There is only one Wideband codec that is MTI in the WebRTC specs.  I think it would be very hard to get this profile through the IETF without it.

Brian

On Nov 5, 2019, at 2:22 PM, Isaac Roach <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Isaac

From: Rum <[email-masked]<mailto:[email-masked]>> on behalf of Eric Burger <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2019 at 12:09 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Thanks,
Paul

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2019 18:53:14 -0500

I don’t think we are required to be backwards compatible with everything. No one expects this to work with RUM:

Image CC 2.0 Methodshop.com <http://methodshop.com/> (https://www.flickr.com/photos/methodshop/21638277765/in/photostream/ <https://www.flickr.com/photos/methodshop/21638277765/in/photostream/>)

> On Nov 5, 2019, at 5:54 PM, Richard Shields <[email-masked]> wrote:
> 
> From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Rosen
> To: Isaac Roach <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Nov 5, 2019, at 2:22 PM, Isaac Roach <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Rum <[email-masked] <mailto:[email-masked]>> on behalf of Eric Burger <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> https://tools.ietf.org/html/draft-ietf-rum-rue-01 <https://tools.ietf.org/html/draft-ietf-rum-rue-01>
> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01 <https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01 <https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01>
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

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

Thanks Eric, that was a nice reminder of the situation that kicked me into working with total conversation in the 90's.

On the codec requirements, there is already a requirement in Sections 255 and 508 about it.

It says:

"412.4 Digital Encoding of Speech. ICT in IP-based networks shall transmit and receive speech that is digitally encoded in the manner specified by ITU-T Recommendation G.722.2 (incorporated by reference, see 702.7.2) or IETF RFC 6716 (incorporated by reference, see 702.8.1)."

RFC 6716 is Opus, and G722.2 is AMR-WB.

So, if you want to sell in USA that should be what to follow.

From:
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#412-two-way-communication

Regards

Gunnar

Den 2019-11-06 kl. 00:53, skrev Eric Burger:
I don’t think we are required to be backwards compatible with everything. No one expects this to work with RUM:

Image CC 2.0 Methodshop.com<http://Methodshop.com> (https://www.flickr.com/photos/methodshop/21638277765/in/photostream/)

On Nov 5, 2019, at 5:54 PM, Richard Shields <[email-masked]<mailto:[email-masked]>> wrote:

Richard

From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Rosen
Sent: Tuesday, November 5, 2019 2:51 PM
To: Isaac Roach <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Brian

Thanks,

Isaac

Thanks,
Paul

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

--

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

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

---

From: James Hamlin <[email-masked]>
Date: Thu, 7 Nov 2019 17:39:58 +0000

Paul

We've discussed rtcweb-overview provides for a "WebRTC-compatible Endpoint"; the intent is to support legacy systems such as the PSTN and older VRS endpoints.

This text would clarify things:-

At the start of section 6:-

On the Relay Service Provider side of the RUM interface, there are connections to the PSTN and legacy endpoints which cannot be upgraded soon. The Relay Service Provider is regarded here as a WebRTC-compatible Endpoint as described in draft-ietf-rtcweb-overview. Relay Service Providers therefore do not have to offer, or be willing to accept all the WEBRTC codecs but will always have at least one codec in common with any RUE that is compliant with this profile.

In section 6.3 Video:-

The RUE and Relay Service Provider MUST conform to [RFC7742] with the exception that, since backwards compatibility is desirable and older devices do not support VP8, that only H.264, as specified in [RFC7742] is Mandatory to Implement by Relay Service Providers.

In section 6.4.  Audio:-

The RUE and Relay Service Provider MUST conform to [RFC7874] with the exception that, since backwards compatibility is desirable and older devices only G.711 is mandatory to implement by Relay Service Provider.

Best regards

James

________________________________________
From: Rum <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: 05 November 2019 18:44
To: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

        Thanks,
        Paul

On 11/4/19 4:20 PM, [email-masked] wrote:
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-ietf-rum-rue%2f&c=E,1,I2pLDuP9kDOqy0C6pdthtTmu_RFATqCMS2D_LN1CQtPuT_R5nJ1R1LBA2mSUavnqIsghvMURdwO20SVX6HUM7nJMmiPmxU_8Vwhd6_0QNbI5n-yKP8Z5U7v9rl0,&typo=0
>
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-rum-rue-01&c=E,1,MWR5OWQx40XIr3x539rleCUMVJqMml6UoobFNi3LqtVYvskf4qmVHelEG7DXIxYrxWKq2Y6m26xEiUE1MjQEXUXQpV8erzhIVOCdMbvXXyyFxZ4QKaEfPeiulw,,&typo=0
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fhtml%2fdraft-ietf-rum-rue-01&c=E,1,i5xFLAheos-mTzQGdU3JuMkX5DtrGxCWlemx7HGjphPZ37P_zsYYxsNx46meAjeouqBKqpkDDBzy-gXRZnQZVvR1YgLTcNVg_mByKniPQIiV1QF5MA,,&typo=0
>
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-ietf-rum-rue-01&c=E,1,TEmEj1k443-Te2py0L7ec5xiK5pD7ITyazUQoeW05PZGB0vPhi90ohpiMxSiPoemnM7gM9mQ80ouGMzTTOnR_M07J5SWRbygAAnoF30JcA,,&typo=0
>
>
> https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2finternet-drafts%2f&c=E,1,F5kMy0HPxpwZGTTbkvKinQAFkSsDV0z9S1IYNgIdQMiPISfCgHuB8foYzOnXJ7dtY1kJ21GHgi4v_hFKHIHY3C8_3DxLOLQ0akYcSaJNZbw8CsQ,&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,ANxha7oZqejOC1IAQ9J9lBR5rVW3cOiTi5v5Y3XBZwV-QxAHx3Z0BNmJco8zmLV5hWyxbIu5F4ptM7kQ3E8cqrl5o7sLgrOfmJCv9Dd_&typo=0