4.16 - RTT - Interoperability (PSTN, VoIP using SIP)

Design Guidance Test Guidance Product types Applicable standards Other applicable notes

Where ICT with RTT functionality interoperates with other ICT with RTT functionality, they shall support at least one of the four RTT interoperability mechanisms described below:

  • ICT interoperating with other ICT directly connected to the Public Switched Telephone Network (PSTN) using Recommendation ITU-T V.18 [i.23] or any of its annexes for text telephony signals at the PSTN interface;
  • ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using RTT that conforms to IETF RFC 4103 [i.13]. For ICT interoperating with other ICT using the IP Multimedia Sub-System (IMS) to implement VOIP, the set of protocols specified in ETSI TS 126 114 [i.10], ETSI TS 122 173 [i.11], and ETSI TS 134 229 [i.12] describe how IETF RFC 4103 [i.13] would apply;
  • ICT interoperating with other ICT using technologies other than a or b, above, using a relevant and applicable common specification for RTT exchange that is published and available for the environments in which they will be operating. This common specification shall include a method for indicating loss or corruption of characters.
  • ICT interoperating with other ICT using a standard for RTT that has been introduced for use in any of the above environments, and is supported by all of the other active ICT that support voice and RTT in that environment.

NOTE 1: In practice, new standards are introduced as an alternative codec/protocol that is supported alongside the existing common standard and used when all end-to-end components support it while technology development, combined with other reasons including societal development and cost efficiency, may make others become obsolete.

NOTE 2: Where multiple technologies are used to provide voice communication, multiple interoperability mechanisms may be needed to ensure that all users are able to use RTT.

Design Guidance

Each of the interoperability mechanisms under the scope of this requirement are defined by the noted ITU standards or ETSI Technical Specifications (TS). In order for the ICT to support the operation of each mechanism, the following guidelines should be followed by the ICT designer.

  • Select at least one of the mechanisms to be incorporated in the ICT design and ensure that any inputs or outputs necessary to support the operation of that mechanism are included in the ICT design.
  • Review the standard and/or technical specification to ensure an understanding of how the mechanism is intended to operate. These are “reference” standards and technical documents that tell industry how to achieve compatibility between the ICT and the individual mechanism. Ensure that the ICT design architecture complies with the appropriate standard and technical specification for the mechanism selected.
  • Using the standards and technical specifications information include in the early design phase of the ICT a review of the ICT architecture so as to ensure the ICT will be in compliance with all the standards and technical specifications for the selected mechanism.
  • Although this requirement specifies that at least one of the mechanisms be supported, it is highly recommended that as many of the four mechanisms be supported as possible.
  • Ensure that all menu instructions or features are listed in the product operating manual for the mechanism that was selected.
  • In order to provide visibility to the user for any loss or corruption of characters, follow the guidance as found in RFC 4103: http://www.ietf.org/rfc/rfc4103.txt. The requirements as described in RFC 4103 must be included in the design of the ICT platform. RFC 4103 defines a payload type for carrying text conversation session contents in RTP packages. RFC 4103 also refers to ITU recommendation T140 found at: https://www.itu.int/rec/T-REC-T.140.
  • ITU recommendation T140 and its Amendment 1 describes how to alert the user of any corrupted or missing text character by placing a “Missing text marker”. ICT design architecture must have a display capable of displaying a white question mark in a black diamond. The protocol for the marker are shown below:
  • Purpose: To mark in the text the position of lost character(s).
  • Coding: 0xFFFD
  • Graphical representation: A white question mark in a black diamond (see ISO 10646-1).
  • Procedure: The Missing Text Marker “Replacement Character” should be inserted in the T.140 data stream by any protocol entity who has discovered a data loss affecting some T.140 data.

Test Guidance

Using the appropriate technical specification or standard, outline a test plan for the mechanism selected to be included in the ICT design architecture. The test plan will depend on each standard or technical specification. Setup the ICT for the mechanism selected and complete the testing plan. This requirement has been met if all the items in the test plan are compliant. General guidelines for testing plans are:

  • All aspects of the standard or test specifications must be included in the test plan.
  • Test plans should always include a system level or black box test plan that will ensure the mechanism operates as a whole.
  • All features of the mechanism selected in the ICT must be checked for proper operation.
  • Lower level individual test items that make up part of the black box or system are also to be included. Since these can be quite cumbersome the ICT designer can have discretion to select those items most appropriate.

Verify that the ICT has an indicator that is capable of displaying the Missing Text Marker - white question mark in a black diamond. Most likely, this is the same display that is used to display Realtime Text information. Provided the ICT follows the RFC 4103 and the ITU T140 guidance this part of the requirement has been met pertaining to lost or corrupt characters.

Product types

Applicable

  • Mobile phones, Phablets, voice communication devices (hardware, preinstall software and included accessories)

May apply

  • Closed Functionality Computing Products, Retail Point of Sale Kiosks (hardware, preinstall software. No expansion or add-on option)
  • Desktop, Notebook, Workstation PCs (hardware only)
  • Tablets and Slates (hardware, preinstall software and included accessories)
  • Thin Client devices (hardware, preinstall software and included accessories)
  • IoT Products
  • Wearables

Applicable standards

  • EN 301 549 - 6.2.3 Interoperability

Other applicable notes

Realtime Text Reference: http://trace.umd.edu/news/201204/real-time-text-update-access-board-and-fcc