Re: RTT note in WebRTC 1.0

Regarding the polyfill implementations: I would suggest confirming that they are available to be used today. If they are feasible to implement, but not readily available to WebRTC application developers yet, I would change the text slightly to indicate that they should be further developed and used in the interim - until a standard protocol and any necessary, associated API support exist.

Janina's draft otherwise seems clear and reasonable to me, but I do not have WebRTC expertise.



´╗┐On 10/9/19, 05:58, "Janina Sajka" <> wrote:

    Hello All:

    I have revised Dom's text somewhat and included suggested language from
    Josh. Before we send this out to APA for approval, can we please
    determine I have improved the language--and not impaired it!

    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.

    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

    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.

    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.


    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.





    Janina Sajka

    Linux Foundation Fellow
    Executive Chair, Accessibility Workgroup:;;sdata=hepIF9qfRdI7wM2wZFa1fVlZ3DeKkYmbzdA734V4XHc%3D&amp;reserved=0

    The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
    Chair, Accessible Platform Architectures;;sdata=uPQmDD78RMtIa52q5%2FueyKxuVxKpEt%2BeJoCPc%2Fjqwtk%3D&amp;reserved=0


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Wednesday, 9 October 2019 12:01:14 UTC