Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[James Hamlin <[e-mail]>]

Paul

"... the goal of the WG is just to specify the RUE..." isn't consistent with the charter which, talks of a "a RUM-compliant provider" and the document scope which contains things like "the provider MUST". 

I don't think we will need to peer inside provider's networks except to point out - as we have - that there are some limitations on what codecs can realistically be offered at the provider's side of the RUE interface.

I think the text will need to recognise - as previous versions have done - some asymmetry between the RUE which is new and providers which are established.

Best regards

James 


________________________________________
From: Paul Kyzivat <[e-mail]>
Sent: 13 September 2019 20:12
To: James Hamlin; Richard Shields; [e-mail]
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

On 9/13/19 11:55 AM, James Hamlin wrote:
> Richard
>
> Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provider a "WebRTC-compatible endpoint" but the current text doesn't make any distinction.

I agree that we need to clarify that requirements differ between the RUE
and the VRS provider. I think it is worth some discussion if the
provider should be "WebRTC-compatible" or perhaps something more
specific than that though not all the way to "WebRTC endpoint".

While the goal of the WG is just to specify the RUE, I think it may well
be helpful to specify (somewhere) more about the environment in which it
will be used, including the other pieces that play in that environment
and interact with the RUE. For instance media relays, Interactive Media
Response devices, Communications Assistant devices, video mail devices.

That will allow us to discuss constraints on the RUE that we need to
consider and/or the potential need to develop requirements for some of
those other devices.

        Thanks,
        Paul

> I just wanted to make sure that we will establish wording that makes clear points that are important for compatibility.
>
> Best regards
>
> James
>
>
> ________________________________________
> From: Richard Shields <[e-mail]>
> Sent: 13 September 2019 16:22
> To: James Hamlin; [e-mail]
> Cc: Paul Kyzivat
> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01
>
> Thanks, James.
>
> Section 5 of RFC 7742 states this:
>
> "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.
>
> Does that not alleviate the requirement to implement VP8?
>
> Thanks,
> Richard
>
> -----Original Message-----
> From: James Hamlin [mailto:[e-mail]]
> Sent: Friday, September 13, 2019 9:19 AM
> To: Richard Shields <[e-mail]>; [e-mail]
> Cc: Paul Kyzivat <[e-mail]>
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
>
> [EXTERNAL]
>
> Richard
>
> This was mentioned and I think the provider side is "WebRTC-compatible endpoint". But the text currently in 7.3 and 7.4 treats provider and RUE identically.
>
> Best regards
>
> James
> ________________________________________
> From: Richard Shields <[e-mail]>
> Sent: 13 September 2019 16:02
> To: James Hamlin; [e-mail]
> Cc: Paul Kyzivat
> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01
>
> This may have been brought up before. RFC 7742, referenced in section 7.3, has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and a WebRTC-compatible endpoint,  with different levels of MTI regarding VP8. With the proposed RUE document, what are VRS endpoints considered?
>
> Thanks,
> Richard
>
> -----Original Message-----
> From: Rum [mailto:[e-mail]] On Behalf Of James Hamlin
> Sent: Friday, September 13, 2019 8:41 AM
> To: [e-mail]
> Cc: Paul Kyzivat <[e-mail]>
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
>
> [EXTERNAL]
>
> Paul
>
> I think we agreed that OPUS and VP8 wouldn't need to be supported on the provider side, for good reasons. The draft proposed for adoption seems to contradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .
>
> Is the procedure that the document is adopted, with some agreed changes missing, and then amended?
>
> Best regards
>
> James
> ________________________________________
> From: Rum <[e-mail]> on behalf of Paul Kyzivat <[e-mail]>
> Sent: 10 September 2019 20:53
> To: [e-mail]
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
>
> Reminder,
>
> This call for adoption will end next Sunday. All responses so far have been in support, but there haven't been a lot of them. If you haven't yet responded, please do.
>
>          Thanks,
>          Paul, as RUM co-chair
>
> On 8/29/19 9:50 AM, Paul Kyzivat wrote:
>> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg
>> document. This is intended to evolve into the document our charter
>> calls for.
>>
>> Comments, pro or con, on this proposal are due by Sunday September 15.
>>
>>       Thanks,
>>       Paul Kyzivat, as RUM co-chair
>>
>
> --
> Rum mailing list
> [e-mail]
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,,&typo=0
>
> --
> Rum mailing list
> [e-mail]
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,5gFM03FhLeAehgyM5wopwvqisH_DKkNfsMVfqIMUtoJYZexefZEADQ9aHKc-74KC8XOuzmOWQEvBaAcc6pYgXOkk4ObSl_YHXWvalJG72uy_OQ6v038vyjCsoVU3&typo=0
>
>
>