Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

From: James Hamlin <[email-masked]>
Date: Mon, 2 Sep 2019 08:39:40 +0000

Just to add: the VRS industry supports a variety of endpoints, many of which are hardware based and not built by VRS providers themselves. H.264 and G.711 therefore need to be in the MTI list.

I believe the FCC order related to compensation by compliant providers not that every call had to come from a compliant endpoint.

Best Regards

James

________________________________________
From: Rum <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: 28 August 2019 16:48
To: [email-masked]
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

On 8/28/19 11:25 AM, Eric Burger wrote:
> I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to pipe in here.]

Lets be clear about what we mean by "RUM compatible".

When Henning and I were working on this with the providers in 2014 and
2015 there was an expectation that the providers would be required to
support the defined RUE devices, but they would also be permitted to
support their existing proprietary devices. The RUE devices could have
requirements that their existing devices don't meet. But calls between
the two were expected to work.

There was great consternation when subsequently the FCC issued a
proposed order that said only VRS calls involving RUE-compatible devices
would be compensated. (But that was in 2015. I presume it has not happened.)

If there is an intent to exclude non-RUM-compliant devices from use in
VRS calls then there needs to be a migration plan to get from here to there.

        Thanks,
        Paul

>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked]> wrote:
>>
>> If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC.  Isn’t that what we want?
>>
>> Brian
>>
>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <[email-masked]> wrote:
>>>
>>> Inline...
>>>
>>> On 8/27/19 5:57 PM, Adam Roach wrote:
>>>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below.
>>>>  From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding.
>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage.
>>>
>>> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2.
>>>
>>> Making OPUS the only MTI audio codec would be problematic.
>>>
>>>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers.
>>>
>>> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8.
>>>
>>> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> /a
>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:
>>>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs.
>>>>>
>>>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint.
>>>>>
>>>>> Not sure how to say this.  Maybe Adam can help.
>>>>>
>>>>> Brian
>>>>>
>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked]> wrote:
>>>>>>
>>>>>> 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://www.ietf.org/mailman/listinfo/rum
>
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 3 Sep 2019 10:48:08 -0400

On 9/2/19 4:39 AM, James Hamlin wrote:
> 
> Just to add: the VRS industry supports a variety of endpoints, many of which are hardware based and not built by VRS providers themselves. H.264 and G..711 therefore need to be in the MTI list.
> 

Sorry if I got that wrong. I wrote that from memory and perhaps my 
memory is faulty.

	Thanks,
	Paul

>>>>>   From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec.. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Sep 2019 09:54:39 -0400

I think our consensus is MTI:
Audio: G.711 and Opus
Video: H.264

We need to get into the details of H.264 to maintain compatibility with the WebRTC specs and as much backwards compatibility as possible.

Anyone object?

> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Sorry if I got that wrong. I wrote that from memory and perhaps my memory is faulty.
> 
> 	Thanks,
> 	Paul
> 
>> Best Regards
>> James
>> From: Rum <[email-masked]> on behalf of Paul Kyzivat <pkyzivat@alum..mit.edu>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 4 Sep 2019 16:35:03 +0200

> I think our consensus is MTI:

  Real-time text: T.140        (I think you said it is mandatory for 
clients, and optional for services.)

All these need then transport and security details specified to assure 
interop with RUM.

How can you hope for backward compatibility with legacy devices when it 
is said in RUM that the security requirements must be met?

Regards

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Sep 2019 10:37:43 -0400

Yes, for sure T.140 (RFC4103).
The providers have SBCs that anchor media, so they can handle security on one side but not the other.  That’s not a great answer, but it’s an answer.  Transcoding video is not reasonable.

Brian

> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> 
>  Real-time text: T.140        (I think you said it is mandatory for clients, and optional for services.)
> 
> 
> All these need then transport and security details specified to assure interop with RUM.
> 
> How can you hope for backward compatibility with legacy devices when it is said in RUM that the security requirements must be met?
> 
> Regards
> 
> Gunnar
> 
>> 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288

---

From: James Hamlin <[email-masked]>
Date: Wed, 4 Sep 2019 17:52:35 +0000

I think making Opus mandatory will require transcoding for many calls. G.711 is likely to be the only option for calls that are relayed and therefore have a PSTN leg. Making G.711 mandatory and Opus recommended would allow for calls where Opus cannot sensibly be offered.

MTI as the term is used in the WebRTC context ( https://webrtcglossary.com/mti ), I think, refers to what must be implemented in a WebRTC stack whereas, I think, we are talking about what must be in an SDP offer.

Best regards

James

________________________________________
From: Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
Sent: 04 September 2019 14:54
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

Anyone object?

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Sep 2019 14:54:53 -0400

I believe way the spec reads, it’s MTI, and also mandatory to offer in SDP.  Adam, can you confirm?

If rue calls old machine, rue offers G.711 and OPUS.  Old machine answers G.711
If old machine calls rue, old machine offers G.711 and rue answers G.711

If I’m mistaken, I have no problem requiring offers to have G.711 and H.264 (and 4103).

Brian

> On Sep 4, 2019, at 1:52 PM, James Hamlin <[email-masked]> wrote:
> 
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 04 Sep 2019 15:15:50 -0400

That's the beauty of MTI. Old, old equipment will interoperate (G.711) and as the base upgrades / new users appear, they get the benefit of 46 years of codec development. It's not 1972 any more...
-------- Original message --------From: Brian Rosen <[email-masked]> Date: 9/4/19  2:54 PM  (GMT-05:00) To: James Hamlin <[email-masked]> Cc: [email-masked], Paul Kyzivat <[email-masked]> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 I believe way the spec reads, it’s MTI, and also mandatory to offer in SDP.  Adam, can you confirm?If rue calls old machine, rue offers G.711 and OPUS.  Old machine answers G.711If old machine calls rue, old machine offers G.711 and rue answers G.711If I’m mistaken, I have no problem requiring offers to have G.711 and H.264 (and 4103).Brian> On Sep 4, 2019, at 1:52 PM, James Hamlin <[email-masked]> wrote:> > > I think making Opus mandatory will require transcoding for many calls. G.711 is likely to be the only option for calls that are relayed and therefore have a PSTN leg. Making G.711 mandatory and Opus recommended would allow for calls where Opus cannot sensibly be offered.> > MTI as the term is used in the WebRTC context ( https://webrtcglossary.com/mti ), I think, refers to what must be implemented in a WebRTC stack whereas, I think, we are talking about what must be in an SDP offer.> > Best regards> > James> > ________________________________________> From: Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>> Sent: 04 September 2019 14:54> To: Paul Kyzivat> Cc: [email-masked]> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01> > I think our consensus is MTI:> Audio: G.711 and Opus> Video: H.264> > We need to get into the details of H.264 to maintain compatibility with the WebRTC specs and as much backwards compatibility as possible.> > Anyone object?> > > >> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <[email-masked]> wrote:>> >> On 9/2/19 4:39 AM, James Hamlin wrote:>>> Just to add: the VRS industry supports a variety of endpoints, many of which are hardware based and not built by VRS providers themselves. H.264 and G..711 therefore need to be in the MTI list.>>> I believe the FCC order related to compensation by compliant providers not that every call had to come from a compliant endpoint.>> >> Sorry if I got that wrong. I wrote that from memory and perhaps my memory is faulty.>> >>      Thanks,>>      Paul>> >>> Best Regards>>> James>>> ________________________________________>>> From: Rum <[email-masked]> on behalf of Paul Kyzivat <pkyzivat@alum..mit.edu>>>> Sent: 28 August 2019 16:48>>> To: [email-masked]>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01>>> On 8/28/19 11:25 AM, Eric Burger wrote:>>>> I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to pipe in here.]>>> Lets be clear about what we mean by "RUM compatible".>>> When Henning and I were working on this with the providers in 2014 and>>> 2015 there was an expectation that the providers would be required to>>> support the defined RUE devices, but they would also be permitted to>>> support their existing proprietary devices. The RUE devices could have>>> requirements that their existing devices don't meet. But calls between>>> the two were expected to work.>>> There was great consternation when subsequently the FCC issued a>>> proposed order that said only VRS calls involving RUE-compatible devices>>> would be compensated. (But that was in 2015. I presume it has not happened.)>>> If there is an intent to exclude non-RUM-compliant devices from use in>>> VRS calls then there needs to be a migration plan to get from here to there.>>>        Thanks,>>>        Paul>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked]> wrote:>>>>> >>>>> If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC.  Isn’t that what we want?>>>>> >>>>> Brian>>>>> >>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <[email-masked]> wrote:>>>>>> >>>>>> Inline...>>>>>> >>>>>> On 8/27/19 5:57 PM, Adam Roach wrote:>>>>>>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below.>>>>>>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec.. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding.>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage.>>>>>> >>>>>> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2.>>>>>> >>>>>> Making OPUS the only MTI audio codec would be problematic.>>>>>> >>>>>>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers.>>>>>> >>>>>> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8.>>>>>> >>>>>> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious.>>>>>> >>>>>>    Thanks,>>>>>>    Paul>>>>>> >>>>>>> /a>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:>>>>>>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs.>>>>>>>> >>>>>>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint.>>>>>>>> >>>>>>>> Not sure how to say this.  Maybe Adam can help.>>>>>>>> >>>>>>>> Brian>>>>>>>> >>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked]> wrote:>>>>>>>>> >>>>>>>>> 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://www.ietf.org/mailman/listinfo/rum>>>> >>>> >>> -->>> Rum mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/rum>> >> -->> Rum mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/rum> > --> Rum mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/rum-- Rum mailing [email-masked]://www.ietf.org/mailman/listinfo/rum

---

From: James Hamlin <[email-masked]>
Date: Wed, 4 Sep 2019 19:37:55 +0000

Just wanted to be clear that we aren't requiring the VRS provider's side to offer Opus.

Thanks

________________________________
From: Rum <[email-masked]> on behalf of Eric Burger <[email-masked]>
Sent: 04 September 2019 20:15
To: [email-masked]
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

That's the beauty of MTI. Old, old equipment will interoperate (G.711) and as the base upgrades / new users appear, they get the benefit of 46 years of codec development.

It's not 1972 any more...

-------- Original message --------
From: Brian Rosen <[email-masked]>
Date: 9/4/19 2:54 PM (GMT-05:00)
To: James Hamlin <[email-masked]>
Cc: [email-masked], Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Sep 2019 16:31:24 -0400

On 9/4/19 10:37 AM, Brian Rosen wrote:
> The providers have SBCs that anchor media, so they can handle security 
> on one side but not the other.  That’s not a great answer, but it’s an 
> answer.  Transcoding video is not reasonable.

The soon to be released updated version of the Provider Profile 
specifies opportunistic media security [RFC8643].

Also, while providers use SBCs, some of them can set up e2e media for 
point to point calls, where the media won't be anchored and security 
can't be twiddled.

I think this can be a problem if RUM requires the RUE to signal 
mandatory media security, which (I think) WebRTC requires.

	Thanks,
	Paul

> Brian
> 
>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>> How can you hope for backward compatibility with legacy devices when 
>> it is said in RUM that the security requirements must be met?
>>
>> Regards
>>
>> Gunnar
>>
>>>
>>> We need to get into the details of H.264 to maintain compatibility 
>>> with the WebRTC specs and as much backwards compatibility as possible.
>>>
>>> Anyone object?
>>>
>>>
>>>
>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>> Just to add: the VRS industry supports a variety of endpoints, many 
>>>>> of which are hardware based and not built by VRS providers 
>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list.
>>>>> I believe the FCC order related to compensation by compliant 
>>>>> providers not that every call had to come from a compliant endpoint.
>>>>> From: Rum <[email-masked] <mailto:[email-masked]>> on 
>>>>> behalf of Paul Kyzivat <pkyzivat@alum..mit.edu <http://mit.edu>>
>>>>> To: [email-masked] <mailto:[email-masked]>
>>>>>> I guess the question is whether we want today’s devices to have a 
>>>>>> chance of being RUM compatible. I don’t think anyone will be 
>>>>>> surprised if a five-year-old device is history. Is it realistic 
>>>>>> for current devices to get VP8 upgrade? [Would be nice for some 
>>>>>> manufacturers or others building such devices to pipe in here.]
>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked] 
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 and 
>>>>>>> VP8 as MTI, then we get backwards compatibility without 
>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t that 
>>>>>>> what we want?
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat 
>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>> Inline...
>>>>>>>>
>>>>>>>>> I certainly have thoughts. The executive summary is that I 
>>>>>>>>> personally believe RUM should specify Opus as the one audio 
>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements for 
>>>>>>>>> the video codec MTI. Rationale below.
>>>>>>>>>  From an interop perspective, the important thing is that any 
>>>>>>>>> given profile has (at least) one MTI video codec and (at least) 
>>>>>>>>> one MTI audio codec.. I know there is a strong desire -- one 
>>>>>>>>> that I share -- that these endpoints can talk to/be implemented 
>>>>>>>>> in web browsers without the need for media transcoding.
>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the 
>>>>>>>>> former because it works without transcoding to landline PSTN 
>>>>>>>>> destinations, and the latter because it sounds much, much 
>>>>>>>>> better. RUM could make the same decision; or it could decide to 
>>>>>>>>> move away from a codec that is as old as I am and opt to 
>>>>>>>>> designate Opus as the only MTI. Given that RUM inherently needs 
>>>>>>>>> to deploy into audio/video environments, backwards 
>>>>>>>>> compatibility with the PSTN seems to be unnecessary baggage.
>>>>>>>> Please keep in mind where we are coming from. The RUM will be a 
>>>>>>>> new interface to the *existing* VRS infrastructure. That 
>>>>>>>> infrastructure currently has proprietary devices that serve the 
>>>>>>>> RUE function, deployed to VRS users and to Communications 
>>>>>>>> Assistants (CAs, Interpreters). These have G.711 MTI, and also 
>>>>>>>> *recommend* G.722.2.
>>>>>>>>
>>>>>>>>> For video: While specifying either VP8 or H.264 would be 
>>>>>>>>> sufficient for system interop, and for interop with compliant 
>>>>>>>>> WebRTC endpoints, I'd really prefer not to re-live the WebRTC 
>>>>>>>>> video codec wars. Concretely, what I would propose is that RUM 
>>>>>>>>> indicate that the video codec requirements are defined to be 
>>>>>>>>> identical to those defined for "WebRTC Non-Browsers" in Section 
>>>>>>>>> 5 of RFC 7742. It should be made clear that RUM endpoints *are* 
>>>>>>>>> *not* WebRTC Non-Browsers per se; merely that they comply with 
>>>>>>>>> the same video codec requirements as WebRTC Non-Browsers.
>>>>>>>> Continuing my comment above, existing devices have H.264 
>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 1 as 
>>>>>>>> the MTI codec. Odds are many of these devices aren't capable of VP8.
>>>>>>>>
>>>>>>>> We can't realistically require a wholesale swap out of existing 
>>>>>>>> devices before the RUE defined by RUM can work. We can *discuss* 
>>>>>>>> whether forcing the providers to transcode is a practical way 
>>>>>>>> forward. I'm dubious.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Paul
>>>>>>>>
>>>>>>>>> /a
>>>>>>>>>> I think we really are talking about a WebRTC-compatible 
>>>>>>>>>> endpoint, but we want interoperability with a WebRTC browser 
>>>>>>>>>> endpoint.
>>>>>>>>>>
>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat 
>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>> 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] <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>