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

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 11 Jan 2022 13:38:21 +0000

> On 23 Dec 2021, at 20:36, Brian Rosen <[email-masked]> 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?
> 
> 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.
> 
> 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

//Zahed
.
> 
> Since the discussion of WebRTC is limited to the media section, I don’t think we need to have more definitions, but I can add them if we can show where they would be used.
> 
> Brian
> 
>> On Dec 15, 2021, at 3:13 AM, Zaheduzzaman Sarker via Datatracker <[email-masked]> wrote:
>> 
>> Zaheduzzaman Sarker has entered the following ballot position for
>> draft-ietf-rum-rue-09: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-daabe057359b7059&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5f21db66ba2ee3f6&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rum-rue%2F
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> First of all thanks for working on this technology to make communication
>> available and easy for special human beings. (I have worked with them to
>> converter text to sign language in my bachelor hence had a special feeling
>> while reading this specification).
>> 
>> I understood from the email discussions on the TSVART review
>> (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b6cf7e1cc91dc9fe&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsv-art%2FZ_Ne5au4rCHwcig8bospMcLyzTc%2F)
>> that in the system RUI is deployed, we will have gateway(s) with two legs - one
>> with WebRTC (client <--> gateway) and one with RUI client communicating with
>> RUI server (gateway <--> server). With this understanding I have some points
>> which I believe worth discussing.
>> 
>> - WebRTC communication will be congestion and rate controlled. This will use
>> RTCP feedbacks to make the rate control and congestion control happen in the
>> WebRTC peers. On the WebRTC part of the leg, this RTCP feedbacks will be
>> available according to the WebRTC specification. However, this specification
>> does not discuss how those RTCP feedback will be converted from the RUI
>> server to RUI client (i.e the gateway) direction and vice versa. This will
>> require the gateway to have such conversion functions to actually work. what
>> is the thinking here? has this been considered? as I am not sure how is the
>> network looks like between the RUI client and RUI server, there might be the
>> Internet connecting them hence need to have congestion controlled traffic.
>> 
>> - Thanks to Bernard Aboba for a comprehensive TSVART review of this draft and
>> I would like to bring some issues, identified in that review, here to make
>> sure they are addressed-
>> 
>>   * clarification on the use of ICE
>>   * clarification on what is a WebRTC client, WebRTC server, gateway, RUI
>>   client and RUI server. I believe all four have been conceptually used in
>>   the specification without concretely defining their roles. for example - if
>>   server is mentioned it need to be distinguishable if it is WebRTC server or
>>   RUI server ( I noted that there are servers in this specification which are
>>   clearly understandable).
>> 
>> 
>> 
>> 
>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Jan 2022 13:14:49 -0500

> On Jan 11, 2022, at 8:38 AM, Zaheduzzaman Sarker <[email-masked]> wrote:
> 
> 
> 
>> On 23 Dec 2021, at 20:36, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
The requirements that both have to implement RTCP, the media congestion mechanisms, and SDP negotiations are already in the document, yes.

> 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…
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.

> 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.   

>>> Please refer to https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-daabe057359b7059&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-daabe057359b7059&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F>
>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5f21db66ba2ee3f6&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rum-rue%2F <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5f21db66ba2ee3f6&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rum-rue%2F>
>>> 
>>> 
>>> 
>>> (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b6cf7e1cc91dc9fe&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsv-art%2FZ_Ne5au4rCHwcig8bospMcLyzTc%2F <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b6cf7e1cc91dc9fe&q=1&e=74bc0e4e-1cad-4540-ae4b-6a8304ba7746&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsv-art%2FZ_Ne5au4rCHwcig8bospMcLyzTc%2F>)

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 12 Jan 2022 13:30:23 +0000

> On 11 Jan 2022, at 19:14, Brian Rosen <[email-masked]> wrote:
> 
> 
> 
>> On Jan 11, 2022, at 8:38 AM, Zaheduzzaman Sarker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
Ok. Good.
> 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."  “A…
Looks good to me.
> 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 negoti…
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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 12 Jan 2022 11:42:20 -0500

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 <[email-masked]> wrote:
> 
> 
> 
>> On 11 Jan 2022, at 19:14, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 13 Jan 2022 08:36:57 +0000

The statement in the specification actually raises some confusions. Like, section 6.3 says backward compatibility is desired, now given the context of the Section 6.3 my interpretation would be the backward compatibility is scoped there to codec of choice. But then the referred text makes me think that it is not only coded but also end to end video we are talking about. So old devices those are not WebRTC compatible comes into play which “may” require some interworking which is not provided in this specification.  That is why I think it would be better to mention where the implementers should and should not care about backward compatibility and to what extend. I will suggest to add statements along the lines what you wrote for video traffic - “older devices that may not implement all the mechanisms and where SDP negotiation might not result in a compatible option” hence media session should not be established. The main point here is that we don’t want non-congestion controlled media traffic in the Internet ( RFC8834), Hence if a gateway has a leg where we have older devices those are not capable of congestion/rate controlled media then even if they support desired video codec the end to end video session must not be established. I was really hoping that as RUI claims to be non-browser webRTC client, older devices that does not implement all the mechanisms are completely out of scope of RUI profile,  

//Zahed

> On 12 Jan 2022, at 17:42, Brian Rosen <[email-masked]> wrote:
> 
>> On Jan 12, 2022, at 8:30 AM, Zaheduzzaman Sarker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>