Re: Fwd: RTT note in WebRTC 1.0

Hi Janina,

A few comments / corrections in-line.

Le 09/10/2019 à 11:58, Janina Sajka a écrit :
> Accessibility considerations [New section, informative]
> 
> The WebRTC 1.0 specification exposes an API to control protocols
> (defined within the IETF) necessary to establish real-time
> audio, video and data exchange.
> 
> Real-time Text, defined in RFC 4103 on which people
> who are deaf or hard of hearing (among others) rely on for their communication needs, utilizes T.140
> encapsulated in RTP to enable the transition from TDD/TTY devices to
> IP-based communications. Support for RFC 4103 is especially important is it is
> being established as the new and more reliable mechanism for text
> communications with emergency service centers.

Replace "is it is" with "as it is" (I assume)


> Since Real-time Text requires the ability to send and receive data in near
> real time, it can be best supported via the WebRTC 1.0 data channel API. As
> defined by the IETF, the data channel protocol utilizes the SCTP/DTLS/UDP
> protocol stack, which supports both reliable and unreliable data channels. The
> IETF chose to standardize SCTP/DTLS/UDP over proposals for an RTP data channel
> which relied on SRTP key management and were focused on unreliable
> communications.
> 
> Since the IETF chose a different approach than the RTP data channel as part of
> the WebRTC suite of protocols, as of the time of this publication there is no
> standardized way for the WebRTC APIs to directly support Real-time Text as
> defined at IETF and implemented in U.S. (FCC) regulations.  The WebRTC working
> group will be actively looking to address this gap in future specification
> revisions, as well as at progressing technical API requirements.  We hope to
> do this in conjunction with developing IETF protocols.

I don't know if the WebRTC WG is ready to commit to address the gap -
depending on what the protocols emerge to be, the value of having it
exposed directly in the browser may vary considerably.

Maybe a phrasing around "the WebRTC WG will evaluate if the developing
IETF protocols in this space warrant direct exposure in the browser APIs
and is looking for input from the relevant user communities on this
potential gap"?


> 
> Within the IETF MMUSIC WG, work is ongoing to enable Real-time text to
> be sent over the WebRTC data channel, allowing gateways to be deployed
> to translate between the SCTP data channel protocol and RFC 4103
> Real-time text. This work, once completed, would enable a unified and
> interoperable approach for integrating real-time text in WebRTC
> user-agents (including browsers) - through a gateway or otherwise.
> 
> MMUSIC-T140:
> https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel
> 
> As of this publication polyfill implementations exist that do enable
> effective RTT support in WebRTC applications. This is deemed sufficient until
> such time as future
> gateways are enabled via IETF protocols such as the SCTP data channel protocol
> and RFC 4103 Real-time text. This will need to be defined at IETF in
> conjunction with related work at W3C groups to effectively and consistently standardise RTT
> support internationally.

I wouldn't talk about "polyfill implementations" here - polyfill usually
refers to a specific approach in JavaScript development where a missing
native feature is replaced by a library. If anything exists in this
space, it is much more likely to be a gateway than a polyfill.

As Jason pointed out, unless we receive confirmation that such gateways
exist, this probably should be worded more cautiously (e.g. "At the time
of this publication, gateways that enable effective RTT support in
WebRTC clients can be developed e.g. through a custom WebRTC data channel.")

If so, the following reference to "future gateways" should be rephrased
as "future standardized gateways".

Dom

Received on Wednesday, 9 October 2019 12:19:22 UTC