Re: Fwd: RTT note in WebRTC 1.0

Thanks, Dom, All. Here's another version with Dom's revisions I have
also changed "emergency service centers" to the term used by the FCC and
provided the link to their official order. ...

----------------
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 as it is
being established as the new and more reliable mechanism for text
communications with Public Safety Access Points (PSAP).[1]

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 evaluate whether 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
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.  This is deemed sufficient until such time as future
standardized 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.
 
[1] https://www.ecfr.gov/cgi-bin/text-idx?SID=ada7cebd65433a9e05c35426a2bc76b8&mc=true&node=pt47.3.67&rgn=div5
------------------

Dominique Hazael-Massieux writes:
> 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

-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Received on Wednesday, 9 October 2019 12:58:31 UTC