| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice.
This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios.
Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN textphones that do not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described.
1.
Introduction
2.
Terminology
2.1.
Abbreviations
2.2.
Definitions
3.
Functional goals of the procedures
4.
Scope
5.
Locating RTT gateways
5.1.
Types of RTT gateways
5.2.
Locating a gateway
5.2.1.
From the IP side
5.2.2.
From the PSTN side
6.
SIP Call control
6.1.
SIP and SDP text indicators
6.2.
SIP/SDP Call procedures
6.2.1.
Calls from the PSTN
6.2.2.
Call from a ToIP User Agent
6.3.
Procedure for RFC 4103 and other real-time text transports
7.
Text medium interworking
7.1.
Handling of alternating text and audio
7.1.1.
Non-continuous carrier PSTN textphones
7.1.2.
Continuous-carrier PSTN textphones
8.
IANA Considerations
9.
Security Considerations
10.
Normative References
§
Authors' Addresses
| TOC |
Real-time text can be a component in IP multimedia telephony and total conversation. Real-time text can be transported in IP networks using standard IP protocols and be used as a medium in 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 RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and SDP RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566]. RFC 4103 (Hellstrom, G. and P. Jones, “RTP Payload for Text Conversation,” June 2005.) [RFC4103] specifies the carriage of real-time text in RTP packets between ToIP devices in IP networks. RFC 5194 [RFC5194] (van Wijk, A. and G. Gybels, “Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP),” June 2008.) 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 include procedures to support medium interworking.
The case where ToIP support is not provided at all PSTN/IP gateways that could be selected to convey the call is also considered. It requires specific routing actions for calls that may contain text.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
RTT real-time text
ToIP text over IP
PSTN public switched telephone network
| TOC |
TTY: term used in some countries for PSTN textphone.
| TOC |
The procedures described in this specification are designed to meet the following functional requirements.
| TOC |
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.
| TOC |
| TOC |
Text capable gateways can be located in at least the following distinctively different locations:
| TOC |
| TOC |
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 [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) and RFC 3841 [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) provide a means of doing that.
Option 2: ENUM RFC 3761 [RFC3761] (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) 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.
| TOC |
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 - The call routing made after number analysis that results in that a call to a real-time text user is routed through the text gateway located in the IP network.
Option 5 - The destination SIP subscriber has an indication on SIP registration level or call control level that text support is required.
| TOC |
| TOC |
SIP User Agents and RTT gateways SHALL announce support for real-time text in the Contact field according to RFC 3840 [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) 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 [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) 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 [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) 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 [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) by sending an indication in the call setup as specified in draft-hellstrom-text-turntaking [I‑D.hellstrom‑text‑turntaking] (Hellstrom, G. and A. Wijk, “Registration of the Real-time-text Media Feature Tag,” March 2010.).
This indication will allow ToIP User Agents to inform users of the need to communicate in a turn-taking manner.
| TOC |
The decision to include text when offering the call may be because:
a. textphone tones have already been detected by the gateway 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.
| TOC |
| TOC |
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
| TOC |
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
| TOC |
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.
| TOC |
| TOC |
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
| TOC |
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
| TOC |
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 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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
| TOC |
In the case where a User Agent implements both RFC 4103 (Hellstrom, G. and P. Jones, “RTP Payload for Text Conversation,” June 2005.) [RFC4103] 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 (Hellstrom, G. and P. Jones, “RTP Payload for Text Conversation,” June 2005.) [RFC4103] or the other transport method, or both.
| TOC |
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 V.18 (ITU-T, “Operational and interworking requirements for DCEs operating in the text telephone mode,” November 2000.) [V.18] 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.
| TOC |
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:
| TOC |
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.
| TOC |
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 (ITU-T, “Recommendation T.140, Protocol for Multimedia Application Text Conversation and Addendum 1,” February 2000.) [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.
| TOC |
TBD.
| TOC |
TBD
| TOC |
| [T.140] | ITU-T, “Recommendation T.140, Protocol for Multimedia Application Text Conversation and Addendum 1,” February 2000. |
| [V.18] | ITU-T, “Operational and interworking requirements for DCEs operating in the text telephone mode,” November 2000. |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT). |
| [RFC3551] | Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” STD 65, RFC 3551, July 2003 (TXT, PS, PDF). |
| [RFC3761] | Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” RFC 3761, April 2004 (TXT). |
| [RFC3840] | Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” RFC 3840, August 2004 (TXT). |
| [RFC3841] | Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” RFC 3841, August 2004 (TXT). |
| [RFC4103] | Hellstrom, G. and P. Jones, “RTP Payload for Text Conversation,” RFC 4103, June 2005 (TXT). |
| [RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
| [RFC4975] | Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT). |
| [RFC5194] | van Wijk, A. and G. Gybels, “Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP),” RFC 5194, June 2008 (TXT). |
| [I-D.hellstrom-text-turntaking] | Hellstrom, G. and A. Wijk, “Registration of the Real-time-text Media Feature Tag,” draft-hellstrom-text-turntaking-03 (work in progress), March 2010 (TXT). |
| TOC |
| Gunnar Hellstrom | |
| Omnitor | |
| Box 92054 | |
| Stockholm, 120 06 | |
| SE | |
| Phone: | +46-8-58900056 |
| Email: | gunnar.hellstrom@omnitor.se |
| Barry Dingle | |
| 3 Cosmo Court | |
| Kilsyth, 3137 | |
| AU | |
| Phone: | +61-3-9725-3937 |
| Email: | btdingle@gmail.com |
| Arnoud van Wijk | |
| Real-Time Text Taskforce (R3TF) | |
| NL | |
| Phone: | |
| Email: | arnoud@realtimetext.org |
| Guido Gybels | |
| RNID, Department of New Technologies | |
| 19-23 Featherstone Street | |
| London, EC1Y 8SL | |
| UK | |
| Phone: | +44-20-7294 3713 |
| Email: | guido.gybels@rnid.org |