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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 14 Dec 2021 13:43:45 -0800

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://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/

----------------------------------------------------------------------
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://mailarchive.ietf.org/arch/msg/tsv-art/Z_Ne5au4rCHwcig8bospMcLyzTc/)
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: Thu, 23 Dec 2021 14:36:08 -0500

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,

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. 

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.

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.

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