Subject: [Rum] Distinguishing RUE and Provider requirements

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Oct 2019 15:15:10 -0400

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://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Oct 2019 16:14:05 -0400

I would like to revive the point raised in the attached message that had 
no followup discussion.

The problem with calling for mandatory media security on the RUE is that 
current VRS calls use insecure media. The VRS Provider Profile currently 
does not specify the RUE interface. It is the responsibility of the 
provider to interface (using SDP rewriting or media bridging) the 
calling RUE to either the terminating RUE or the other provider where 
the terminating RUE is connected. But it would be inappropriate 
(deceptive) to interface secure media to insecure media.

There are plans to upgrade media security over the VRS Provider Profile. 
The following is a likely path forward, though steps 3-5 are speculation 
on my part:

1) The current VRS Provider Profile (v1) specifies insecure media. That 
is what is currently deployed by VRS providers.

2) There is a revised VRS Provider Profile (v2) in development. It 
hopefully will be approved by the end of this year. It calls for 
opportunistic media security [RFC8643] between providers. The reason is 
to allow gradual migration of providers to the revised profile.

3) Based on past history it may well take a year or more to accomplish a 
complete migration of all providers to the new profile. At that time all 
calls will be using secure media.

4) Once that migration is complete it will be possible to make a further 
revision to the profile (v3) that mandates offering unprovisional media 
security while still allowing the acceptance of offers of provisional 
media security. Again this is to allow a phase-in period.

5) Once that is complete, a v4 of the profile could then mandate 
unprovisional media security.

If the new RUE spec isn't introduced until step (5) then media security 
can be achieved without any bridging or SDP rewriting. But that will 
likely be multiple years in the future.

To incorporate the new RUE spec earlier some compromises will be required.

It would be easy to change the RUE spec to use opportunistic media 
security. This would still result in secure media if all entities on the 
signaling path support it. It that won't be assured until step (3). 
Getting this to work with a WebRTC-based RUE (that requires secure 
media) will require at least SDP rewriting.

Thoughts?

	Thanks,
	Paul

On 9/5/19 4:31 PM, Paul Kyzivat wrote:
> On 9/4/19 10:37 AM, Brian Rosen wrote:
>> 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.
> 
> 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:
>>>
>>>
>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen:
>>>> I think our consensus is MTI:
>>>> Audio: G.711 and Opus
>>>> Video: H.264
>>>
>>>  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
>>>
>>>>
>>>> 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:
>>>>>
>>>>> 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] <mailto:[email-masked]>> on 
>>>>>> behalf of Paul Kyzivat <pkyzivat@alum..mit.edu <http://mit.edu>>
>>>>>> Sent: 28 August 2019 16:48
>>>>>> To: [email-masked] <mailto:[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] 
>>>>>>>> <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...
>>>>>>>>>
>>>>>>>>> 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] <mailto:[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:
>>>>>>>>>>>>
>>>>>>>>>>>> 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]>
>>> -----------------------------------------
>>> Gunnar Hellström
>>> Omnitor
>>> [email-masked] <mailto:[email-masked]>
>>> +46 708 204 288
>>
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 1 Oct 2019 20:19:33 +0000

Agree w Paul

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

I would like to revive the point raised in the attached message that had no followup discussion.

The problem with calling for mandatory media security on the RUE is that current VRS calls use insecure media. The VRS Provider Profile currently does not specify the RUE interface. It is the responsibility of the provider to interface (using SDP rewriting or media bridging) the calling RUE to either the terminating RUE or the other provider where the terminating RUE is connected. But it would be inappropriate (deceptive) to interface secure media to insecure media.

There are plans to upgrade media security over the VRS Provider Profile. The following is a likely path forward, though steps 3-5 are speculation on my part:

1) The current VRS Provider Profile (v1) specifies insecure media. That is what is currently deployed by VRS providers.

2) There is a revised VRS Provider Profile (v2) in development. It hopefully will be approved by the end of this year. It calls for opportunistic media security [RFC8643] between providers. The reason is to allow gradual migration of providers to the revised profile.

3) Based on past history it may well take a year or more to accomplish a complete migration of all providers to the new profile. At that time all calls will be using secure media.

4) Once that migration is complete it will be possible to make a further revision to the profile (v3) that mandates offering unprovisional media security while still allowing the acceptance of offers of provisional media security. Again this is to allow a phase-in period.

5) Once that is complete, a v4 of the profile could then mandate unprovisional media security.

If the new RUE spec isn't introduced until step (5) then media security can be achieved without any bridging or SDP rewriting. But that will likely be multiple years in the future.

It would be easy to change the RUE spec to use opportunistic media security. This would still result in secure media if all entities on the signaling path support it. It that won't be assured until step (3). Getting this to work with a WebRTC-based RUE (that requires secure media) will require at least SDP rewriting.

Thoughts?

   Thanks,
   Paul

On 9/5/19 4:31 PM, Paul Kyzivat wrote:
On 9/4/19 10:37 AM, Brian Rosen wrote:
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.
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]> <mailto:[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

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]> <mailto:[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]<mailto:[email-masked]> <mailto:[email-masked]>> on behalf of Paul Kyzivat <pkyzivat@alum..mit.edu<http://mit.edu> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>
Sent: 28 August 2019 16:48
To: [email-masked]<mailto:[email-masked]> <mailto:[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]<mailto:[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]> <mailto:[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.

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.

Brian

On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]> <mailto:[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:

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]> <mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=

--
Rum mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
--
Rum mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=

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

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=

---

From: Brian Rosen <[email-masked]>
Date: Tue, 1 Oct 2019 17:13:23 -0400

As a practical matter, isn’t it the case that all providers have Session Border Controllers in the path, and they anchor media at the SBC?

If that is true, the RUE can be secure and still connect to an insecure older device.

Brian

> On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Agree w Paul
> 
> Martin C. Dolly
> Cell: +1.609.903..3360 <tel:+1.609.903.3360>
> Email: [email-masked] <mailto:[email-masked]>
> 
> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>> 
>>>>> 
>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>> 
>>>>>>>> From: Rum <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> on behalf of Paul Kyzivat <pkyzivat@alum..mit.edu <http://mit.edu/> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>>
>>>>>>>> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>>> would be compensated. (But that was in 2015.. I presume it has not happened.)
>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Inline...
>>>>>>>>>>> 
>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>    compatible endpoint"..  It is, of course, advisable to implement at
>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
>>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Rum mailing list
>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
>>>>>>> -- 
>>>>>>> Rum mailing list
>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
>>>>> 
>>>>> -- 
>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>> +46 708 204 288
>>>> 
>> 
>> -- 
>> Rum mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
> -- 
> Rum mailing list
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Oct 2019 19:51:36 -0400

On 10/1/19 5:13 PM, Brian Rosen wrote:
> As a practical matter, isn’t it the case that all providers have Session 
> Border Controllers in the path, and they anchor media at the SBC?

Not entirely. There is some use of ICE, along with e2e media for p2p 
calls. And there is a desire to encourage that.

> If that is true, the RUE can be secure and still connect to an insecure 

I don't think it is forbidden (as it is with SIPS) but downgrading 
security along the path is at least deceptive in that it might lead the 
user into a false sense of security.

	Thanks,
	Paul

> Brian
> 
>> On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Agree w Paul
>>
>> Martin C. Dolly
>>> The problem with calling for mandatory media security on the RUE is 
>>> that current VRS calls use insecure media. The VRS Provider Profile 
>>> currently does not specify the RUE interface. It is the 
>>> responsibility of the provider to interface (using SDP rewriting or 
>>> media bridging) the calling RUE to either the terminating RUE or the 
>>> other provider where the terminating RUE is connected. But it would 
>>> be inappropriate (deceptive) to interface secure media to insecure media.
>>>
>>> There are plans to upgrade media security over the VRS Provider 
>>> Profile. The following is a likely path forward, though steps 3-5 are 
>>> speculation on my part:
>>>
>>> 1) The current VRS Provider Profile (v1) specifies insecure media. 
>>> That is what is currently deployed by VRS providers.
>>>
>>> opportunistic media security [RFC8643] between providers. The reason 
>>> is to allow gradual migration of providers to the revised profile.
>>>
>>> 3) Based on past history it may well take a year or more to 
>>> accomplish a complete migration of all providers to the new profile. 
>>> At that time all calls will be using secure media.
>>>
>>> 4) Once that migration is complete it will be possible to make a 
>>> further revision to the profile (v3) that mandates offering 
>>> unprovisional media security while still allowing the acceptance of 
>>> offers of provisional media security. Again this is to allow a 
>>> phase-in period.
>>>
>>> If the new RUE spec isn't introduced until step (5) then media 
>>> security can be achieved without any bridging or SDP rewriting. But 
>>> that will likely be multiple years in the future.
>>>
>>> security. This would still result in secure media if all entities on 
>>> the signaling path support it. It that won't be assured until step 
>>> (3). Getting this to work with a WebRTC-based RUE (that requires 
>>> secure media) will require at least SDP rewriting.
>>>
>>> Thoughts?
>>>
>>>    Thanks,
>>>    Paul
>>>
>>>>> 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.
>>>> 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.
>>>>>> <[email-masked] <mailto:[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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From: Rum <[email-masked] <mailto:[email-masked]> 
>>>>>>>>> <mailto:[email-masked]>> on behalf of Paul Kyzivat 
>>>>>>>>> <pkyzivat@alum..mit.edu <http://mit.edu/> 
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>
>>>>>>>>> To: [email-masked] <mailto:[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.]
>>>>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t 
>>>>>>>>>>> that what we want?
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>>
>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>> 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
>>>>>>>>>>>>>> endpoint, but we want interoperability with a WebRTC 
>>>>>>>>>>>>>> browser endpoint.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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]> <mailto:[email-masked]>
>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]>
>>>>>> +46 708 204 288
>>>>>
>>>
>>> -- 
>>> Rum mailing list
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
>> -- 
>> Rum mailing list

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Oct 2019 19:53:22 -0400

> Martin C. Dolly

Thanks Martin. Can you be more explicit about what you are agreeing with?

	Thanks,
	Paul

> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
> 
>> currently does not specify the RUE interface. It is the responsibility 
>> of the provider to interface (using SDP rewriting or media bridging) 
>> the calling RUE to either the terminating RUE or the other provider 
>> where the terminating RUE is connected. But it would be inappropriate 
>> 3) Based on past history it may well take a year or more to accomplish 
>> a complete migration of all providers to the new profile. At that time 
>> all calls will be using secure media.
>>
>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>> <pkyzivat@alum..mit.edu <http://mit.edu> 
>>>>>>>>> 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 
>>>>>>>>>>>> any given profile has (at least) one MTI video codec and (at 
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>>> 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 
>>>>>>>>>>> as the MTI codec. Odds are many of these devices aren't 
>>>>>>>>>>> capable of VP8.
>>>>>>>>>>>
>>>>>>>>>>> can *discuss* whether forcing the providers to transcode is a 
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 3 Oct 2019 20:47:30 -0400

I would express my agreement maybe a different way.  What doesn’t make complete sense to me is the specification of RUM/RUE devices that seem to try to live in two different worlds.  What maybe i could call a traditional SIP UE/terminal world, but also trying to stick on a vision of moving to webrtc media, etc. and modern video conferencing world.

While i understand this is all possible theoretically, I’m not sure it is reality for most current webrtc supporting eco-systems.  Most i’m familiar with are using different signaling protocols, support multiple participants, simulcast and multi-bitrate stream and modern communications practices/identities etc.  I think this is why we had such a hard time finding a direction for NAANC IVC and beyond just basic IR.94 a point to point SIP protocol based eco-system, other than the standard deployment in the VRS world, this barely exists elsewhere, and I would guess is trending smaller, not larger.

So, i think it would be nice to sort of come to a reality check on where this is all going.

If we are talking about putting SBC/gateways in front of RUM/RUE devices anyway, it might be better to envision gateways into webrtc devices that look/feel more like messaging and video apps and use gateways into SIP networks for standard NNI protocol but allow for what typically seems to be proprietary SIP to webrtc gateway + app or SIP to webrtc gateway + device style deployments.  I know maybe that’s not a great message for in the IETF and the work in this group, but i think it’s really reality for most of what i know is being deployed going forward in general.  For a lot of good reasons, point to point vs multi-point calling supporting devices/apps are what people like to use.  I feel like that is what i seem to be hearing from the communities that depend on these devices and services generally as well, but i won’t claim to be an authority for that opinion.

-Chris

> On Oct 1, 2019, at 7:53 PM, Paul Kyzivat <[email-masked]> wrote:
> 
>>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> 
>>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>> 
>>>>>>>>> From: Rum <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> on behalf of Paul Kyzivat <pkyzivat@alum..mit.edu <http://mit.edu> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>
>>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Inline...
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>>> 
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>> +46 708 204 288
>>>>> 
>>> 
>>> -- 
>>> Rum mailing list

---

From: Eric Burger <[email-masked]>
Date: Fri, 4 Oct 2019 10:03:08 -0400

Said a different way, since we know it takes a while for implementors to build to specifications once the specifications are complete, why not specify what we need, and leave transition to industry organizations?

Using Paul’s terminology, we would specify V3 here, and in the VRS case V2 could be negotiated by industry and, in the U.S. case, perhaps the FCC?

The point being that since it takes years to get a standard done, and year (singular) to release product, we set the target and let the laggards in industry (because there will always be a vendor or two and open source that will have it done before the document pops out of the RFC Editor queue) catch up?

> On Oct 3, 2019, at 8:47 PM, Chris Wendt <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Oct 2019 11:41:08 -0400

Chris,

> If we are talking about putting SBC/gateways in front of RUM/RUE devices anyway, it might be better to envision gateways into webrtc devices that look/feel more like messaging and video apps and us…

I'm not clear on what you are suggesting here.

For use with VRS there are some constraints that come into play. 
(Perhaps these constraints can be eased over time, but the transition 
must be smooth.)

1) The point of VRS is to give deaf people parity and interoperability 
with hearing users. Because it is a federal government program under the 
FCC, subsidized by a tax on telephone service, it is based on the 
existing telephone network. AFAIK the FCC doesn't have authority to 
expand it further. It must be possible for someone using a RUE to 
communicate with any telephone number.

I didn't participate in the NAANC IVC. My understanding is that it was 
trying to bridge newer (proprietary) communications systems to the 
existing phone system. I'd appreciate having more about that introduced 
here where appropriate.

2) VRS is deployed to many deaf users who depend on it now. Existing VRS 
services use proprietary RUE devices, both in users homes and on the 
desks of the interpreters. Anything we do must integrate with that.

Chris, can you restate what you are suggesting while making clear how it 
fits with constraints?

	Thanks,
	Paul