Network Working Group A. van Wijk, Ed. Request for Comments: 5194 G. Gybels, Ed. Category: Informational June 2008 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks.
1. Introduction ....................................................3 2. Scope ...........................................................4 3. Terminology .....................................................4 4. Definitions .....................................................4 5. Requirements ....................................................6 5.1. General Requirements for ToIP ..............................6 5.2. Detailed Requirements for ToIP .............................8 5.2.1. Session Setup and Control Requirements ..............9 5.2.2. Transport Requirements .............................10 5.2.3. Transcoding Service Requirements ...................10 5.2.4. Presentation and User Control Requirements .........11 5.2.5. Interworking Requirements ..........................13 188.8.131.52. PSTN Interworking Requirements ............13 184.108.40.206. Cellular Interworking Requirements ........14 220.127.116.11. Instant Messaging Interworking Requirements ..............................14 6. Implementation Framework .......................................15 6.1. General Implementation Framework ..........................15 6.2. Detailed Implementation Framework .........................15 6.2.1. Session Control and Setup ..........................15 18.104.22.168. Pre-Session Setup .........................15 22.214.171.124. Session Negotiations ......................16 6.2.2. Transport ..........................................17 6.2.3. Transcoding Services ...............................18 6.2.4. Presentation and User Control Functions ............18 126.96.36.199. Progress and Status Information ...........18 188.8.131.52. Alerting ..................................18 184.108.40.206. Text Presentation .........................19 220.127.116.11. File Storage ..............................19 6.2.5. Interworking Functions .............................19 18.104.22.168. PSTN Interworking .........................20 22.214.171.124. Mobile Interworking .......................22 126.96.36.199.1. Cellular "No-gain" .............22 188.8.131.52.2. Cellular Text Telephone Modem (CTM) ....................22 184.108.40.206.3. Cellular "Baudot mode" .........22 220.127.116.11.4. Mobile Data Channel Mode .......23 18.104.22.168.5. Mobile ToIP ....................23 22.214.171.124. Instant Messaging Interworking ............23 126.96.36.199. Multi-Functional Combination Gateways .....24 188.8.131.52. Character Set Transcoding .................25 7. Further Recommendations for Implementers and Service Providers ......................................................25 7.1. Access to Emergency Services ..............................25 7.2. Home Gateways or Analog Terminal Adapters .................25 7.3. User Mobility .............................................26
7.4. Firewalls and NATs ........................................26 7.5. Quality of Service ........................................26 8. Security Considerations ........................................26 9. Contributors ...................................................27 10. References ....................................................27 10.1. Normative References .....................................27 10.2. Informative References ...................................29 RFC3351 . It also meets real-time text requirements of mainstream users. ToIP also offers an IP equivalent of analog text telephony services as used by deaf, hard-of-hearing, speech-impaired, and mainstream users. The Session Initiation Protocol (SIP)  is the protocol of choice for control of Multimedia communications and Voice-over-IP (VoIP) in particular. It offers all the necessary control and signalling required for the ToIP framework.
The Real-Time Transport Protocol (RTP)  is the protocol of choice for real-time data transmission, and its use for real-time text payloads is described in RFC 4103 . This document defines a framework for ToIP to be used either by itself or as part of integrated, multi-media services, including Total Conversation . 5]. It provides the: a. requirements for real-time text; b. requirements for ToIP interworking; c. description of ToIP implementation using SIP and RTP; d. description of ToIP interworking with other text services. RFC 2119  and indicate requirement levels for compliant implementations. RFC 3550 . Cellular: a telecommunication network that has wireless access and can support voice and data services over very large geographical areas. Also called Mobile. Full duplex: media is sent independently in both directions. Half duplex: media can only be sent in one direction at a time, or if an attempt to send information in both directions is made, errors may be introduced into the presented media.
Interactive text: another term for real-time text, as defined below. Real-time text: a term for real-time transmission of text in a character-by-character fashion for use in conversational services, often as a text equivalent to voice-based conversational services. Conversational text is defined in the ITU-T Framework for multimedia services, Recommendation F.700 . Text gateway: a function that transcodes between different forms of text transport methods, e.g., between ToIP in IP networks and Baudot or ITU-T V.21 text telephony in the PSTN. Textphone: also "text telephone". A terminal device that allows end-to-end real-time text communication using analog transmission. A variety of PSTN textphone protocols exists world-wide. A textphone can often be combined with a voice telephone, or include voice communication functions for simultaneous or alternating use of text and voice in a call. Text bridging: a function of the text media bridge server, gateway (including transcoding gateways), or relay service analogous to that of audio bridging as defined above, except that text is the medium of conversation. Text relay service: a third-party or intermediary that enables communications between deaf, hard-of-hearing, and speech-impaired people and voice telephone users by translating between voice and real-time text in a call. Text telephony: analog textphone service. Total Conversation: a multimedia service offering real-time conversation in video, real-time text and voice according to interoperable standards. All media streams flow in real time. (See ITU-T F.703, "Multimedia conversational services" .) Transcoding service: a service provided by a third-party User Agent that transcodes one stream into another. Transcoding can be done by human operators, in an automated manner, or by a combination of both methods. Within this document, the term particularly applies to conversion between different types of media. A text relay service is an example of a transcoding service that converts between real-time text and audio. TTY: originally, an abbreviation for "teletype". Often used in North America as an alternative designation for a text telephone or textphone. Also called TDD, Telecommunication Device for the Deaf.
Video relay service: a service that enables communications between deaf and hard-of-hearing people and hearing persons with voice telephones by translating between sign language and spoken language in a call. Acronyms: 2G Second generation cellular (mobile) 2.5G Enhanced second generation cellular (mobile) 3G Third generation cellular (mobile) ATA Analog Telephone Adaptor CDMA Code Division Multiple Access CLI Calling Line Identification CTM Cellular Text Telephone Modem ENUM E.164 number storage in DNS (see RFC3761) GSM Global System for Mobile Communications ISDN Integrated Services Digital Network ITU-T International Telecommunications Union-Telecommunications Standardisation Sector NAT Network Address Translation PSTN Public Switched Telephone Network RTP Real-Time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure Real Time Transport Protocol TDD Telecommunication Device for the Deaf TDMA Time Division Multiple Access TTY Analog textphone (Teletypewriter) ToIP Real-time Text over Internet Protocol URI Uniform Resource Identifier UTF-8 UCS/Unicode Transformation Format-8 VCO/HCO Voice Carry Over/Hearing Carry Over VoIP Voice over Internet Protocol Section 6 defines a real-time text-based conversational service that is the text equivalent of voice-based telephony. This section describes the requirements that the framework is designed to meet and the functionality it should offer. RFC 3351 . A basic requirement is that it must provide a standardized way for offering real-time text-based conversational services that can be used as an equivalent to voice telephony by deaf, hard-of-hearing, speech-impaired, and mainstream users.
It is important to understand that real-time text conversations are significantly different from other text-based communications like email or Instant Messaging. Real-time text conversations deliver an equivalent mode to voice conversations by providing transmission of text character by character as it is entered, so that the conversation can be followed closely and that immediate interaction takes place. Store-and-forward systems like email or messaging on mobile networks, or non-streaming systems like instant messaging, are unable to provide that functionality. In particular, they do not allow for smooth communication through a Text Relay Service. In order to make ToIP the text equivalent of voice services, ToIP needs to offer equivalent features in terms of conversationality to those provided by voice. To achieve that, ToIP needs to: a. offer real-time transport and presentation of the conversation; b. provide simultaneous transmission in both directions; c. support both point-to-point and multipoint communication; d. allow other media, like audio and video, to be used in conjunction with ToIP; e. ensure that the real-time text service is always available. Real-time text is a useful subset of Total Conversation as defined in ITU-T F.703 . Total Conversation allows participants to use multiple modes of communication during the conversation, either at the same time or by switching between modes, e.g., between real-time text and audio. Deaf, hard-of-hearing, and mainstream users may invoke ToIP services for many different reasons: - because they are in a noisy environment, e.g., in a machine room of a factory where listening is difficult; - because they are busy with another call and want to participate in two calls at the same time; - for implementing text and/or speech recording services (e.g., text documentation/audio recording) for legal purposes, for clarity, or for flexibility;
- to overcome language barriers through speech translation and/or transcoding services; - because of hearing loss, deafness, or tinnitus as a result of the aging process or for any other reason, creating a need to replace or complement voice with real-time text in conversational sessions. In many of the above examples, real-time text may accompany speech. The text could be displayed side by side, or in a manner similar to subtitling in broadcasting environments, or in any other suitable manner. This could occur with users who are hard of hearing and also for mixed media calls with both hearing and deaf people participating in the call. A ToIP user may wish to call another ToIP user, join a conference session involving several users, or initiate or join a multimedia session, such as a Total Conversation session. A common scenario for multipoint real-time text is conference calling with many participants. Implementers could, for example, use different colours to render different participants' text, or could create separate windows or rendering areas for each participant. Section 6 (Implementation Framework) describes how to implement ToIP based on these requirements by using existing protocols and techniques. The requirements are organized under the following headings: - session setup and session control; - transport; - use of transcoding services; - presentation and user control; - interworking.
24], allowing real-time text users to communicate with voice users. With relay services, as well as in direct user-to-user conversation, it is crucial that text characters are sent as soon as possible after they are entered. While buffering may be done to improve efficiency, the delays SHOULD be kept minimal. In particular, buffering of whole lines of text will not meet character delay requirements. R10: Characters must be transmitted soon after entry of each character so that the maximum delay requirement can be met. An end- to-end delay time of one second is regarded as good, while users note and appreciate shorter delays, down to 300ms. A delay of up to two seconds is possible to use. R11: Real-time text transmission from a terminal SHALL be performed character by character as entered, or in small groups of characters, so that no character is delayed from entry to transmission by more than 300 milliseconds. R12: It MUST be possible to transmit characters at a rate sufficient to support fast human typing as well as speech-to-text methods of generating real-time text. A rate of 30 characters per second is regarded as sufficient. R13: A ToIP service MUST be able to deal with international character sets. R14: Where it is possible, loss or corruption of real-time text during transport SHOULD be detected and the user should be informed. R15: Transport of real-time text SHOULD be as robust as possible, so as to minimize loss of characters. R16: It SHOULD be possible to send and receive real-time text simultaneously. RFC 4103 , and the other one only supporting audio, the user might want to invoke a transcoding service. Some users may indicate their preferred modality to be audio while others may indicate real-time text. In this case, transcoding
services might be needed for text-to-speech (TTS) and speech-to-text (STT). Other examples of possible scenarios for including a relay service in the conversation are: text bridging after conversion from speech, audio bridging after conversion from real-time text, etc. A number of requirements, motivations, and implementation guidelines for relay service invocation can be found in RFC 3351 . R17: It MUST be possible for users to invoke a transcoding service where such service is available. R18: It MUST be possible for users to indicate their preferred modality (e.g., ToIP). R19: It MUST be possible to negotiate the requirements for transcoding services in real time in the process of setting up a call. R20: It MUST be possible to negotiate the requirements for transcoding services in mid-call, for the immediate addition of those services to the call. R21: Communication between the end participants SHOULD continue after the addition or removal of a text relay service, and the effect of the change should be limited in the users' perception to the direct effect of having or not having the transcoding service in the connection. R22: When setting up a session, it MUST be possible for a user to specify the type of relay service requested (e.g., speech to text or text to speech). The specification of a type of relay SHOULD include a language specifier. R23: It SHOULD be possible to route the session to a preferred relay service even if the user invokes the session from another region or network than that usually used. R24: It is RECOMMENDED that ToIP implementations make the invocation and use of relay services as easy as possible.
R25: User Agents for ToIP services MUST have alerting methods (e.g., for incoming sessions) that can be used by deaf and hard-of-hearing people or provide a range of alternative, but equivalent, alerting methods that can be selected by all users, regardless of their abilities. R26: Where real-time text is used in conjunction with other media, exposure of user control functions through the User Interface needs to be done in an equivalent manner for all supported media. For example, it must be possible for the user to select between audio, visual, or tactile prompts, or all must be supplied. R27: If available, identification of the originating party (e.g., in the form of a URI or a Calling Line Identification (CLI)) MUST be clearly presented to the user in a form suitable for the user BEFORE the session invitation is answered. R28: When a session invitation involving ToIP originates from a Public Switched Telephone Network (PSTN) text telephone (e.g., transcoded via a text gateway), this SHOULD be indicated to the user. The ToIP client MAY adjust the presentation of the real-time text to the user as a consequence. R29: An indication SHOULD be given to the user when real-time text is available during the call, even if it is not invoked at call setup (e.g., when only voice and/or video is used initially). R30: The user MUST be informed of any change in modalities. R31: Users MUST be presented with appropriate session progress information at all times. R32: Systems for ToIP SHOULD support an answering machine function, equivalent to answering machines on telephony networks. R33: If an answering machine function is supported, it MUST support at least 160 characters for the greeting message. It MUST support incoming text message storage of a minimum of 4096 characters, although systems MAY support much larger storage. It is RECOMMENDED that systems support storage of at least 20 incoming messages of up to 16000 characters per message. R34: When the answering machine is activated, user alerting SHOULD still take place. The user SHOULD be allowed to monitor the auto- answer progress, and where this is provided, the user SHOULD be allowed to intervene during any stage of the answering machine procedure and take control of the session.
R35: It SHOULD be possible to save the text portion of a conversation. R36: The presentation of the conversation SHOULD be done in such a way that users can easily identify which party generated any given portion of text. R37: ToIP SHOULD handle characters such as new line, erasure, and alerting during a session as specified in ITU-T T.140 .
R43: When interworking with PSTN legacy text telephony services, alternating text and voice function MAY be supported. (Called "voice carry over (VCO) and hearing carry over (HCO)"). 7], both collectively called "Baudot mode" solution in the USA. The GSM and 3G standards from 3GPP make use of the CTM modem in the voice channel for text telephony. However, implementations also exist that use the data channel to provide such functionality. Interworking with these solutions should be done using text gateways that set up the data channel connection at the GSM side and provide ToIP at the other side. R44: a ToIP service SHOULD provide interworking with mobile text conversation services. RFC 3351 . It is less suitable for communications through a relay service . The streaming nature of ToIP provides a more direct conversational user experience and, when given the choice, users may prefer ToIP. R45: a ToIP service MAY provide interworking with Instant Messaging services.
Section 5. The framework presented here uses existing standards that are already commonly used for voice-based conversational services on IP networks. 2] to set up, control, and tear down the connections between ToIP users whilst the media is transported using the Real-Time Transport Protocol (RTP)  as described in RFC 4103 . RFC 4504 describes how to implement support for real-time text in SIP telephony devices . 2] for setting up, controlling, and terminating sessions for real-time text conversation with one or more participants and possibly including other media like video or audio. The Session Description Protocol (SDP) used in SIP to describe the session is used to express the attributes of the session and to negotiate a set of compatible media types. SIP  allows participants to negotiate all media, including real- time text conversation . ToIP services can provide the ability to set up conversation sessions from any location as well as provision for privacy and security through the application of standard SIP techniques.
a. User Preferences: It MUST be possible for a user to indicate a preference for real-time text by registering that preference with a SIP server that is part of the ToIP service. b. Server Support of User Preferences: SIP servers that support ToIP services MUST have the capability to act on calling user preferences for real-time text in order to accept or reject the session. The actions taken can be based on the called users preferences defined as part of the pre-session setup registration. For example, if the user is called by another party, and it is determined that a transcoding server is needed, the session should be re-directed or otherwise handled accordingly. The ability to include a transcoding service MUST NOT require user registration in any specific SIP registrar, but MAY require authorisation of the SIP registrar to invoke the service. A point-to-point session takes place between two parties. For ToIP, one or both of the communicating parties will indicate real-time text as a possible or preferred medium for conversation using SIP in the session setup. The following features MAY be implemented to facilitate the session establishment using ToIP: a. Caller Preferences: SIP headers (e.g., Contact)  can be used to show that real-time text is the medium of choice for communications. b. Called Party Preferences : The called party being passive can formulate a clear rule indicating how a session should be handled, either using real-time text as a preferred medium or not, and whether this session needs to be handled by a designated SIP proxy or the SIP User Agent. c. SIP Server Support for User Preferences: It is RECOMMENDED that SIP servers also handle the incoming sessions in accordance with preferences expressed for real-time text. The SIP server can also enforce ToIP policy rules for communications (e.g., use of the transcoding server for ToIP). 2] provides the capabilities to indicate real-time text as a medium in the session setup. RFC 4103  uses the RTP payload types "text/red" and "text/t140" for support of ToIP, which can be indicated in the SDP as a part of the SIP INVITE, OK, and SIP/200/ACK media negotiations. In
addition, SIP's offer/answer model  can also be used in conjunction with other capabilities, including the use of a transcoding server for enhanced session negotiations [28,29,13]. 3] according to the specification of RFC 4103  for the transport of real-time text between participants. RFC 4103 describes the transmission of T.140  real-time text on IP networks. In order to enable the use of international character sets, the transmission format for real-time text conversation SHALL be UTF-8 , in accordance with ITU-T T.140. If real-time text is detected to be missing after transmission, there SHOULD be a "text loss" indication in the real-time text as specified in T.140 Addendum 1 . The redundancy method of RFC 4103  SHOULD be used to significantly increase the reliability of the real-time text transmission. A redundancy level using 2 generations gives very reliable results and is therefore strongly RECOMMENDED. In order to avoid exceeding the capabilities of the sender, receiver, or network (congestion), the transmission rate SHOULD be kept at or below 30 characters per second, which is the default maximum rate specified in RFC 4103 . Lower rates MAY be negotiated when needed through the "cps" parameter as specified in RFC 4103 . Real-time text capability is announced in SDP by a declaration similar to this example: m=text 11000 RTP/AVP 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 By having this single coding and transmission scheme for real-time text defined in the SIP session control environment, the opportunity for interoperability is optimized. However, if good reasons exist, other transport mechanisms MAY be offered and used for the T.140- coded text, provided that proper negotiation is introduced, but the RFC 4103  transport MUST be used as both the default and the fallback transport.
28] describes invoking relay services, where the relay acts as a conference bridge or uses the third-party control mechanism. ToIP implementations SHOULD support this transcoding framework.
15], including timestamps, party names (or addresses), and the conversation text.
Session setup through gateways to other networks may require the use of specially formatted addresses or other mechanisms for invoking those gateways. ToIP interworking requires a method to invoke a text gateway. These text gateways act as User Agents at the IP side. The capabilities of the gateway during the call will be determined by the call capabilities of the terminal that is using the gateway. For example, a PSTN textphone is generally only able to receive voice and real- time text, so the gateway will only allow ToIP and audio. Examples of possible scenarios for invocation of the text gateway are: a. PSTN textphone users dial a prefix number before dialing out. b. Separate real-time text subscriptions, linked to the phone number or terminal identifier/ IP address. c. Real-time text capability indicators. d. Real-time text preference indicators. e. Listen for V.18 modem modulation text activity in all PSTN calls and routing of the call to an appropriate gateway. f. Call transfer request by the called user. g. Placing a call via the Web, and using one of the methods described here h. A text gateway with its own telephone number and/or SIP address (this requires user interaction with the gateway to place a call). i. ENUM address analysis and number plan. j. Number or address analysis leads to a gateway for all PSTN calls. 16], which also defines the modem detection sequences for the different text protocols. In rare cases, the modem type identification may take considerable time, depending on user actions.
To resolve analog textphone incompatibilities, text telephone gateways are needed to transcode incoming analog signals into T.140 and vice versa. The modem capability exchange time can be reduced by the text telephone gateways initially assuming the analog text telephone protocol used in the region where the gateway is located. For example, in the USA, Baudot  might be tried as the initial protocol. If negotiation for Baudot fails, the full V.18 modem capability exchange will take place. In the UK, ITU-T V.21  might be the first choice. In particular, transmission of real-time text on PSTN networks takes place using a variety of codings and modulations, including ITU-T V.21 , Baudot , dual-tone multi-frequency (DTMF), V.23 , and others. Many difficulties have arisen as a result of this variety in text telephony protocols and the ITU-T V.18  standard was developed to address some of these issues. ITU-T V.18  offers a native text telephony method, plus it defines interworking with current protocols. In the interworking mode, it will recognise one of the older protocols and fall back to that transmission method when required. Text gateways MUST use the ITU-T V.18  standard at the PSTN side. A text gateway MUST act as a SIP User Agent on the IP side and support RFC 4103 real-time text transport. While ToIP allows receiving and sending real-time text simultaneously and is displayed on a split screen, many analog text telephones require users to take turns typing. This is because many text telephones operate strictly half duplex. Only one can transmit text at a time. The users apply strict turn-taking rules. There are several text telephones which communicate in full duplex, but merge transmitted text and received text in the same line in the same display window. Here too the users apply strict turn taking rules. Native V.18 text telephones support full duplex and separate display from reception and transmission so that the full duplex capability can be used fully. Such devices could use the ToIP split screen as well, but almost all text telephones use a restricted character set and many use low text transmission speeds (4 to 7 characters per second). That is why it is important for the ToIP user to know that he or she is connected with an analog text telephone. The session description  SHOULD contain an indication that the other endpoint for the call
is a PSTN textphone (e.g., connected via an ATA or through a text gateway). This means that the textphone user may be used to formal turn taking during the call. 17] and Enhanced Variable Rate (EVR)  speech vocoders in mobile terminals used to provide a text telephony call. It provides full duplex operation and supports alternating between voice and text ("VCO/HCO"). It is dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e., 45 bit/s) type of text telephones. 7] is a technology-independent modem technology that provides the transport of text telephone characters at up to 10 characters/sec using modem signals that can be carried by many voice codecs and uses a highly redundant encoding technique to overcome the fading and cell changing losses.
conversation. Text gateways between such Instant Messaging protocols and ToIP MUST provide this signalling to the Instant Messaging side when characters start being received, or at the beginning of the conversation. At the ToIP side, an indicator of writing the Instant Message MUST be present where the Instant Messaging protocol provides one. For example, the real-time text user MAY see ". . . waiting for replying IM. . . " and when 5 seconds have passed another . (dot) can be shown. Those solutions will reduce the difficulties between streaming and blocked text services. Even though the text gateway can connect Instant Messaging and ToIP, the best solution is to take advantage of the fact that the user interfaces and the user communities for instant messaging and ToIP telephony are very similar. After all, the character input, character display, Internet connectivity, and SIP stack can be the same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may simply use different applications for ToIP and text messaging in the same terminal. Devices that implement Instant Messaging SHOULD implement ToIP as described in this document so that a more complete text communication service can be provided.
These adapters SHOULD contain V.18 modem functionality, voice handling functionality, and conversion functions to/from SIP-based ToIP with T.140 transported according to RFC 4103 , in a similar way as it provides interoperability for voice sessions. If a session is set up and text/t140 capability is not declared by the destination endpoint (by the endpoint terminal or the text gateway in the network at the endpoint), a method for invoking a transcoding server SHALL be used. If no such server is available, the signals from the textphone MAY be transmitted in the voice channel as audio with a high quality of service. NOTE: It is preferred that such analog terminal adaptors do use RFC 4103  on board and thus act as a text gateway. Sending textphone signals over the voice channel is undesirable due to possible filtering and compression and packet loss between the endpoints. This can result in character loss in the textphone conversation or even not allowing the textphones to connect to each other. 2]. For example, nothing should reveal in an obvious way the fact that the ToIP user might be a person with a hearing or speech impairment. It is up to the ToIP user to make his or her hearing or speech impairment public. If a transcoding server is being used,
this SHOULD be as transparent as possible. However, it might still be possible to discern that a user might be hearing or speech impaired based on the attributes present in SDP, although the intention is that mainstream users might also choose to use ToIP. Encryption SHOULD be used on an end-to-end or hop-by-hop basis as described in SIP  and SRTP . Authentication MUST be provided for users in addition to message integrity and access control. Protection against Denial-of-Service (DoS) attacks needs to be provided, considering the case that the ToIP users might need transcoding servers.  Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.  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.  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.  Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.  ITU-T Recommendation F.703,"Multimedia Conversational Services", November 2000.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
 3GPP TS 26.226, "Cellular Text Telephone Modem Description" (CTM).  ITU-T Recommendation T.140, "Protocol for Multimedia Application Text Conversation" (February 1998) and Addendum 1 (February 2000).  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.  Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.  "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, Available at http://www.w3.org/TR/xhtml1.  ITU-T Recommendation V.18, "Operational and Interworking Requirements for DCEs operating in Text Telephone Mode", November 2000.  TIA/EIA/IS-823-A, "TTY/TDD Extension to TIA/EIA-136-410 Enhanced Full Rate Speech Codec (must used in conjunction with TIA/EIA/IS-840)"  TIA/EIA/IS-127-2, "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems, Addendum 2."  "IP Multimedia default codecs", 3GPP TS 26.235
 Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.  ITU-T Recommendation F.700, "Framework Recommendation for Multimedia Services", November 2000.  Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.  Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.  European Telecommunications Standards Institute (ETSI), "Human Factors (HF); Guidelines for Telecommunication Relay Services for Text Telephones". TR 101 806, June 2000.  TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network." (The specification for 45.45 and 50 bit/s TTY modems.)  International Telecommunication Union (ITU), "300 bits per second duplex modem standardized for use in the general switched telephone network". ITU-T Recommendation V.21, November 1988.  International Telecommunication Union (ITU), "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988.  Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol", Work in Progress, May 2006.  Camarillo, G., "The SIP Conference Bridge Transcoding Model", Work in Progress, January 2006.
http://www.ictrnid.org.uk Arnoud A. T. van Wijk Real-Time Text Taskforce (R3TF) EMail: email@example.com http://www.realtimetext.org
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.