Real-time text interworking between PSTN and IP networks

Real-time text is a component in IP multimedia telephony. Real-time text can be transported in IP networks using standard IP protocols and be used as a conversational service. IP devices such as multimedia telephones, voicemail systems, IP phones, IVR systems or other devices, may support the transmission of real-time text over IP networks. An IP User Agent that supports real-time text over IP is called a ToIP User Agent. A ToIP User Agent may also support text and voice. The control of IP real-time text calls is defined in SIP RFC3261 and SDP RFC4566. RFC 4103 specifies the carriage of real-time text in RTP packets between ToIP devices in IP networks. Draft-ietf-sipping-toip-08 describes the implementation aspects of ToIP using SIP. PSTN networks can support the transport of real-time text by representing the text as audio. PSTN textphones (or TTYs) use modem technology to carry the text encoded as tones. Some PSTN textphones can support the transport of both voice and real-time text, but usually not both at the same time. Some PSTN textphone protocols do not include signalling to indicate whether or not the device is in text or voice mode and therefore it is unclear if the audio signal is to be treated as text or as voice. Interworking between the different forms of real-time text transport and the different call control protocols requires a real-time text capable gateway (RTT gateway). It supports ToIP (and possibly VoIP) protocols on the IP side and textphone protocols on the PSTN side. PSTN textphones and multimedia IP User Agents usually support the transport of both voice and real-time text. For calls that support both voice and text media, the gateway needs to consider the lack of media simultaneity imposed by some PSTN textphone protocols and procedures included to support medium interworking. The case where not all PSTN/IP gateways that could be selected to convey the call support ToIP, and therefore specific routing actions are needed to give calls tentatively containing text proper support is also considered.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RTT real-time text ToIP text over IP PSTN public switched telephone network

TTY term used in some countries for PSTN textphone.

The procedures described in this specification are designed to meet the following functional requirements. The real-time text transport in the IP network shall use ToIP as specified by draft-ietf-sipping-toip . The text medium shall be able to be established at any time during the call for gateways that support text and voice. The voice medium shall be able to be established at any time during the call for gateways that support text and voice.

This specification describes the procedures for call routing, call control and media transport of real-time text calls between Text-over- IP (ToIP) User Agents and PSTN textphones (or TTYs) using real-time text capable (RTT) gateways. It specifies how to discover the RTT gateways from the PSTN and IP sides and how to invoke the text capability in them. It also specifies how to control media interaction between PSTN and IP for calls that involve both real-time text and voice.

Text capable gateways can be located at at least the following distinctively different locations: 1 - a residential text capable gateway with PSTN terminals directly connected to it 2 - a network text capable gateway that has PSTN technology on one side and IP technology on the other 3 - a network text capable gateway that is in the IP network that has text transported to it from the PSTN that is still in audio (modem tones) format but carried by IP transport (e.g. G.711 [6] A-law encoded audio) and with high QoS.

A call to a PSTN number will require the use of a gateway. If not all PSTN/IP gateways are text capable, then some means of routing to a RTT gateway is required. The methods resulting in one step calling should be preferred. The following mechanisms are possible: Option 1: Indications are used in the SIP header to indicate that text capability may be required. RFC 3840 [7] and RFC 3841 [8] provide a means of doing that. Option 2: ENUM RFC 3761 [11] procedures may be used to identify and route to RTT gateways. Option 3: Addressing is used consisting of the PSTN number as the user name and the RTT gateway as the SIP domain address on the form number@gateway_domain. Option 4: Dial a special RTT gateway address. The gateway answers in text mode. Then enter the destination number when requested by the RTT gateway using text.

If a PSTN textphone is not directly connected to a RTT gateway or if not all PSTN/IP gateways that are candidates for handling the call are text capable, then some means of routing to a RTT gateway is required. Most PSTN textphone calls appear as ordinary audio telephone calls and do not provide an indication that a call could involve text. A means of indicating the possible need to support real-time text to the PSTN routing procedures is required. Several options are available, the ones resulting in a one-step procedure should be preferred Option 1 - Use a prefix to destination number (e.g. 18001 + 'destination number') Option 2 - Dial a special RTT gateway address. The gateway answers in text mode. Then enter the destination number or address when requested by the RTT gateway using text. Option 3 - a PSTN line marking of 'text' that is carried by the signalling Option 4 - Number analysis resulting in routing calls to a real-time text user in the IP network to the gateway. Option 5 - The destination SIP subscriber has an indication that text support is required.

SIP User Agents and RTT gateways SHALL announce support for real-time text in the Contact field according to RFC 3840 by sending the following in an INVITE: Contact: <uri>;text A calling ToIP User Agent that does not want to give priority to text can indicate an interest to use text according to RFC 3841 [8] by sending the following in a Response to an INVITE: Accept-Contact: *;text A calling ToIP User Agent should indicate priority to establishing a text connection according to RFC 3841 [8] by sending the following in a Response to an INVITE: Accept-Contact: *;text;require PSTN textphones can support alternating text and audio during the call. If this capability is known, the RTT gateway can indicate it according to RFC 3840 [7] by sending an indication in the call setup. The exact coding of this indication was not defined when this specification was produced. This indication will allow ToIP User Agents to inform users of the need to communicate in a turn-taking manner.

The decision to include text when offering the call may be because: a. textphone tones have already been detected on the PSTN line. b. the gateway may be configured to be a dedicated RTT gateway. c. it is known by subscription or other external means that the PSTN user has preference for text d. it is simpler to offer text initially. Note - the examples below do not include all SIP and SDP fields. They concentrate on the fields needed for ToIP operation and VoIP operation (if required). The audio medium description in the examples assumes ITU-T G.711 A-law encoding.

When a RTT gateway has information that indicates that only a text medium is required, it SHALL include specifications in line with this example in an INVITE: Contact: <sip:gw-uri>;text ... m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The answering ToIP User Agent SHALL accept the text medium by including specifications according to this example in its Response: Contact: <sip:term-uri>;text ... m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98

If the RTT gateway has an indication that voice and text media are required in the call, it SHALL include a media line for audio and a media line for text in an INVITE in line with the following example: Accept-Contact: *;text;require Contact: <sip:gw-uri>;text ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The answering ToIP device can accept the audio and the text media by sending the following in the Response: Contact: <sip:term-uri>;text ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98

A RTT gateway that wishes to establish an audio medium and indicate support for text but does not wish to establish a text medium immediately e.g. in order to avoid spending resources for text transport on calls that do not carry text at all, SHOULD send an INVITE with contents in line with the following example: Contact: <sip:gw-uri>;text .... m=audio 7200 RTP/AVP 0 The answering ToIP device can indicate text support and accept the audio medium by including lines in line with the following example in the Response to the INVITE: Contact: <sip:term-uri>;text ..... m=audio 7200 RTP/AVP 0 Then the text medium can be added later in the call.

A calling ToIP User Agent can indicate that a text medium is required in the call by sending an INVITE based on the following example: Contact: <sip:term-uri>;text Accept-Contact: *;text;require ... m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The network will route the call to a RTT gateway if the destination address is in the PSTN and the Contact indicates 'text'. The RTT gateway should then commence call establishment procedures on the PSTN side. The RTT gateway can accept the text request by sending the following in the Response: Contact: <sip:gw-uri>;text .... m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98

A calling ToIP User Agent can request a text medium and a voice medium in a call by including a media line for audio and a media line for text in an INVITE as follows: Contact: <sip:term-uri>;text Accept-Contact: *;text;require ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The network will route the call to a RTT gateway if the destination address is in the PSTN. The answering RTT gateway can accept the text medium and the audio medium by sending the following in the Response: Contact: <sip:gw-uri>;text Accept-Contact: *;text;require ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98

If a calling ToIP device user is not depending on text, but wants to have it available for occasional use, the INVITE that is sent could include the following: Contact: <sip:term-uri>;text Accept-Contact: *;text ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The RTT gateway may decide to not establish the text channel initially, but should indicate its text capability in the Contact header of the Response as follows: Contact: <gwy-uri>;text Accept-Contact: *;text .... m=audio 7200 RTP/AVP 0 m=text 0 RTP/AVP 99 98 During a call, if either party starts text activity, a text channel can be added to the session by sending a re-Invite according to RFC 3261 [1]. This procedure can be executed even if no text capability was expressed from the ToIP User Agent initially. A re-INVITE from the gateway could include the following: Contact: <uri>;text ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 The receiving device should answer with a Response that includes the following: Contact: <uri>;text ... m=audio 7200 RTP/AVP 0 m=text 7202 RTP/AVP 99 98 a=rtpmap:98 t140/1000 a=fmtp:98 cps=20 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98

In the case where a User Agent implements both RFC 4103 and other codecs for text transport, the procedures in this specification can be complemented with the other transport establishment. When establishing a call, a ToIP device may advertise support for real-time text in accordance with other transport methods, and for real-time Text over IP according to the procedures described above. The capabilities of the other party in the call setup will lead to the establishment of text transport according to either RFC 4103 or the other transport method.

Many PSTN textphones can support both voice and text on the one analog 'voice' channel. The voice and the text make use of the channel in an alternating fashion. This direction dependence is however a usage convention, while the transmission can be made in either direction. In most cases, voice is used in one direction and text in the other direction, for example a hearing impaired user talks to an relay operator, who then replies in text. ITU-T V.18 [9] specifies a range of PSTN textphone protocols that could be supported. On the IP side, text and voice are carried in separate text and voice media. The RTT gateway must be able to: a) indicate to the ToIP User Agent if the PSTN textphone operates in an alternating text and voice mode so that the IP User can be informed and communicate appropriately, and b) indicate to the ToIP User Agent if turntaking of text in one direction and text in the other direction is required by the PSTN textphone. The RTT gateway shall decode the characters received and transmit them to the ToIP User Agent. Determining the type of PSTN textphone device in use is the responsibility of the RTT gateway. The ToIP User Agent need not concern itself with what kind of PSTN textphone device is connected to the RTT gateway. When the ToIP User Agent first has characters to send to the RTT gateway the ToIP device shall open the text channel if it was not opened before. The ToIP device shall then transmit the characters to the RTT gateway. The RTT gateway shall perform any required signaling on the PSTN termination if the type of PSTN textphone s needed to be known by the RTT gateway. While connecting, the RTT gateway shall buffer any characters received from the ToIP User Agent and transmit them when the RTT gateway has connected to the PSTN textphone. The size of the character buffer should be sufficient to hold the characters that may come from one side in a connection before a response is expected. If the RTT gateway does not support the modulation used by the PSTN textphone device, the RTT gateway may: a) transmit the received textphone signals via Voiceband Data (VBD) or the audio stream, depending on the capabilities of the ToIP User Agent. b) discard characters received from the ToIP User Agent. c) transmit the received characters to the PSTN textphone based on a pre-provisioned indication of the modulation.

Many PSTN textphones support alternating voice and real-time text. Some PSTN textphones can only handle text transmission in one direction at a time. Most ToIP User Agents can send text and voice simultaneously and in both directions at the same time. When bridging between these two environments, turn-taking schemes must be introduced both by the human users and by the RTT gateways. The following procedures should be applied:

For these PSTN textphones, audio is transmitted through the RTT gateway between the PSTN circuit and the audio stream of the ToIP User Agent. This is done as long as there is no text to transmit or receive on the PSTN side. Text transmission and reception has priority over audio transmission.

For these PSTN textphones, the recommended procedure is: As long as carrier is maintained from the PSTN textphone, it is maintained from the RTT gateway, and text transmission can occur. If carrier is dropped from the PSTN textphone, the RTT gateway shall transmit any remaining characters to the PSTN textphone and then drop the carrier and transmit audio. When carrier is received again from the PSTN textphone and if text is to be transmitted to the PSTN textphone, carrier transmission will be resumed from the gateway and text may be transmitted. If, during a period of audio transmission, text is received from the ToIP device, then audio transmission will be interrupted, carrier re- established and the text transmitted. If, during a period of carrier or text transmission, the Interrupt command (INT) is received in the T.140 stream from the ToIP User Agent, the carrier should be dropped and transmission of audio through the gateway established. In most cases the control of the carrier can be left to the PSTN textphone user.

TBD.

TBD