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

[Brian Rosen <[e-mail]>]

> On Jan 11, 2022, at 8:38 AM, Zaheduzzaman Sarker <[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.

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


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

> 
> //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 <[e-mail]> 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 <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 <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 <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).