Network Working Group G. Hellstrom Request for Comments: 4103 Omnitor AB Obsoletes: 2793 P. Jones Category: Standards Track Cisco Systems, Inc. June 2005 RTP Payload for Text Conversation Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. Hellstrom & Jones Standards Track [Page 1]
RFC 4103 RTP Payload for Text Conversation June 2005 Table of Contents 1. Introduction ...................................................3 2. Conventions Used in This Document ..............................4 3. Usage of RTP ...................................................4 3.1. Motivations and Rationale .................................4 3.2. Payload Format for Transmission of text/t140 Data .........4 3.3. The "T140block" ...........................................5 3.4. Synchronization of Text with Other Media ..................5 3.5. RTP Packet Header .........................................5 4. Protection against Loss of Data ................................6 4.1. Payload Format When Using Redundancy ......................6 4.2. Using Redundancy with the text/t140 Format ................7 5. Recommended Procedure ..........................................8 5.1. Recommended Basic Procedure ...............................8 5.2. Transmission before and after "Idle Periods" ..............8 5.3. Detection of Lost Text Packets ............................9 5.4. Compensation for Packets Out of Order ....................10 6. Parameter for Character Transmission Rate .....................10 7. Examples ......................................................11 7.1. RTP Packetization Examples for the text/t140 Format ......11 7.2. SDP Examples .............................................13 8. Security Considerations .......................................14 8.1. Confidentiality ..........................................14 8.2. Integrity ................................................14 8.3. Source Authentication ....................................14 9. Congestion Considerations .....................................14 10. IANA Considerations ...........................................16 10.1. Registration of MIME Media Type text/t140 ...............16 10.2. SDP Mapping of MIME Parameters ..........................17 10.3. Offer/Answer Consideration ..............................17 11. Acknowledgements ..............................................18 12. Normative References ..........................................18 13. Informative References ........................................19 Hellstrom & Jones Standards Track [Page 2]
RFC 4103 RTP Payload for Text Conversation June 2005 1. Introduction This document defines a payload type for carrying text conversation session contents in RTP [2] packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection with other conversational facilities, such as video and voice, to form multimedia conversation services. Text in multimedia conversation sessions is sent character-by-character as soon as it is available, or with a small delay for buffering. The text is intended to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per second or less. In general, only one or a few new characters are expected to be transmitted with each packet. Small blocks of text may be prepared by the user and pasted into the user interface for transmission during the conversation, occasionally causing packets to carry more payload. T.140 specifies that text and other T.140 elements must be transmitted in ISO 10646-1 [5] code with UTF-8 [6] transformation. This makes it easy to implement internationally useful applications and to handle the text in modern information technology environments. The payload of an RTP packet that follows this specification consists of text encoded according to T.140, without any additional framing. A common case will be a single ISO 10646 character, UTF-8 encoded. T.140 requires the transport channel to provide characters without duplication and in original order. Text conversation users expect that text will be delivered with no, or a low level, of lost information. Therefore, a mechanism based on RTP is specified here. It gives text arrival in correct order, without duplication, and with detection and indication of loss. It also includes an optional possibility to repeat data for redundancy in order to lower the risk of loss. Because packet overhead is usually much larger than the T.140 contents, the increase in bandwidth, with the use of redundancy, is minimal. By using RTP for text transmission in a multimedia conversation application, uniform handling of text and other media can be achieved in, for example, conferencing systems, firewalls, and network translation devices. This, in turn, eases the design and increases the possibility for prompt and proper media delivery. Hellstrom & Jones Standards Track [Page 3]
RFC 4103 RTP Payload for Text Conversation June 2005 This document obsoletes RFC 2793 [16]. The text clarifies ambiguities in RFC 2793, improves on the specific implementation requirements learned through development experience and gives explicit usage examples. 2. Conventions Used in This Document 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 [4]. 3. Usage of RTP The payload format for real-time text transmission with RTP [2] described in this memo is intended for general text conversation use and is called text/t140 after its MIME registration. 3.1. Motivations and Rationale The text/t140 format is intended to be used for text transmitted on a separate RTP session, dedicated for the transmission of text, and not shared with other media. The text/t140 format MAY be used for any non-gateway application, as well as in gateways. It MAY be used simultaneously with other media streams, transmitted as a separate RTP session, as required in real time multimedia applications. The text/t140 format specified in this memo is compatible with its earlier definition in RFC 2793. It has been refined, with the main intention to minimize interoperability problems and encourage good reliability and functionality. By specifying text transmission as a text medium, many good effects are gained. Routing, device selection, invocation of transcoding, selection of quality of service parameters, and other high and low level functions depend on each medium being explicitly specified. 3.2. Payload Format for Transmission of text/t140 Data A text/t140 conversation RTP payload format consists of one, and only one, block of T.140 data, referred to as a "T140block" (see Section 3.3). There are no additional headers specific to this payload format. The fields in the RTP header are set as defined in Section 3.5, carried in network byte order (see RFC 791 [12]). Hellstrom & Jones Standards Track [Page 4]
RFC 4103 RTP Payload for Text Conversation June 2005 3.3. The "T140block" T.140 text is UTF-8 coded, as specified in T.140, with no extra framing. The T140block contains one or more T.140 code elements as specified in [1]. Most T.140 code elements are single ISO 10646 [5] characters, but some are multiple character sequences. Each character is UTF-8 encoded [6] into one or more octets. Each block MUST contain an integral number of UTF-8 encoded characters regardless of the number of octets per character. Any composite character sequence (CCS) SHOULD be placed within one block. 3.4. Synchronization of Text with Other Media Usually, each medium in a session utilizes a separate RTP stream. As such, if synchronization of the text and other media packets is important, the streams MUST be associated when the sessions are established and the streams MUST share the same reference clock (refer to the description of the timestamp field as it relates to synchronization in Section 5.1 of RFC 3550 [2]). Association of RTP streams can be done through the CNAME field of RTCP SDES function. It is dependent on the particular application and is outside the scope of this document. 3.5. RTP Packet Header Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are specified for T.140 text streams: Payload Type (PT): The assignment of an RTP payload type is specific to the RTP profile under which the payload format is used. For profiles that use dynamic payload type number assignment, this payload format can be identified by the MIME type "text/t140" (see