Re: [Rum] Zaheduzzaman Sarker's Discuss on draft-ietf-rum-rue-09: (with DISCUSS)

[Brian Rosen <[e-mail]>]

On the last point, the text already says:
While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices. 

> On Jan 12, 2022, at 8:30 AM, Zaheduzzaman Sarker <[e-mail]> wrote:
> 
> 
> 
>> On 11 Jan 2022, at 19:14, Brian Rosen <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>>> On Jan 11, 2022, at 8:38 AM, Zaheduzzaman Sarker <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> 
>>>> On 23 Dec 2021, at 20:36, Brian Rosen <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Thank you for these comments.
>>>> 
>>>> We did not have a specific conversation on handling rate control and congestion feedback.  
>>>> The RUE server and client are required to support RTCP, so I think that part is easy.  Both ends are required to support the WebRTC media spec, so I think if it happened if both RUE clients were implemented with WebRTC clients, everything would work the way we expect it to.
>>>> 
>>>> So I think the issue reduces to a situation where one end is a WebRTC client, and the other is not.  They both have to implement the media congestion mechanisms.  They both have RTCP to work with.  SDP negotiation should work,
>>> This sounds like requirements to me, is this described in the document?
>> The requirements that both have to implement RTCP, the media congestion mechanisms, and SDP negotiations are already in the document, yes.
> Ok. Good.
>> 
>>>> 
>>>> I’m down to thinking the gateway doesn’t have to mess with this.  It’s possible that the gateway could have more expansive goals to be backwards compatible with existing VRS devices that don’t conform to this document, and I could imagine that there might need to be some work there.  But that would not be covered in this document. 
>>> Would be good to be explicit about this in this document. The thing if the gateway does not want to mess with the RTCP signalling then the signalling and the negotiation of what to use for rate and congestion control need to be end to end. This should be clear in this document.
>> But that is why the document requires support for 8825/8834.  I will add a statement that "Conformance to this document allows end-to-end RTCP and media congestion control for audio and video."  “Allows” is the right word, because many provides anchor media.
> Looks good to me.
>> 
>>>> I’m not personally a WebRTC expert although I had help writing the text from some folks who were.  So, II easily could be missing something here.
>>>> 
>>>> On “Clarification of the use of ICE”, I propose to add "Implementations MUST implement full ICE, although they MAY interwork with User Agents that implement ICE-lite.”  There is an unqualified requirement to support RFC8839.
>>> OK.
>>>> 
>>>> I propose to add the following text in the media section where we introduce the WebRTC media specs:
>>>> To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser, and a RUE client interface towards a provider is assumed.  The gateway would interwork signaling, and as noted below, interwork at least any real time text media, in order to allow a standard browser baed WebRTC client to be a VRS client.  The combination of the browser client and the gateway would be a RUE user.
>>> I think interworking will also be necessary for A/V media traffic
>> I certainly hope not.  Between conforming RUEs, there won’t be any issues.  The only things I worry about are talking to older devices that may not implement all the mechanisms and where SDP negotiation might not result in a compatible option.   
> And I understand you are saying those use case is out of the scope of this document. I would expect this to be explicit in the specification.
> 
> //Zahed