Internet Engineering Task Force AVT WG Internet Draft Gunnar Hellstr÷m draft-ietf-avt-rtp-text-01.txt Ericsson October 6, 1999 Expires: April 6, 2000 RTP Payload for Text Conversation STATUS OF THIS MEMO This document is an Internet-Draft and it is in full conformance with all provisions of section 10 of RFC2026. 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/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. ABSTRACT This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. Hellstrom [Page 1]
Internet Draft 1 Introduction This memo defines a payload type for carrying text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. Text in text conversation sessions is sent as soon as it is available, or with a small delay of up to 0.5 seconds for buffering. The text is supposed 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. Therefore, the expected number of characters to transmit is low. Only one or a few new characters are expected to be transmitted with each packet. T.140 specifies that text and other T.140 elements SHALL be transmitted in ISO 10 646-1 code with UTF-8 transformation. That makes it easy to implement internationally useful applications, and to handle the text in modern information technology environments. The most common T140 PDU is a character of ISO 10646 text, UTF-8 coded, submitted from T.140 without any extra framing. 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. If lost information can be replaced with a special marker, the willingness to accept loss is expected to be higher. Therefore a mechanism based on RTP is specified here. It gives text arrival in correct order, without duplications, with an optional possibility to repeat data for redundancy to lower the risk of loss, and a mechanism that reveals loss and therefore can insert a marker for lost text in the received stream. Since packet overhead is usually much larger than the T.140 contents, the increase in channel load by the redundancy scheme is minimal. 1.1 Terminology 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] 2. Usage of RTP When an unreliable transport of T.140 text session data in a packet network is selected, RTP with payload as described in this specification should be used. T.140 data is submitted for transmission in a number of complete protocol data units (T140 PDU). A T140block contains one or more T140 PDU:s. Hellstr÷m [Page 2]
Internet Draft A text conversation RTP packet contains an RTP header, a Payload Header, OPTIONAL redundant data fields, and the new (primary) T.140 data field. 2.1 RTP packet header Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for T.140 text streams: Payload Type (PT): Payload type allocation is dynamic. If redundancy is used, the Payload Type SHALL indicate redundancy ("RED") according to RFC 2198 [3]. If no redundancy is used, the Payload Type SHALL specify the primary T.140 data "T140" payload format. Sequence number: The Sequence Number SHALL be increased with one for each new transmitted packet. It is used for detection of packet loss and packets out of order, and can be used in the process of retrieval of redundant text, reordering of text and marking missing text. Timestamp: The RTP Timestamp encodes the approximate sampling instance of the primary text in the packet. A clock frequency of 1000 Hz SHALL be used. No sequential packets SHOULD use the same timestamp. 2.2 Additional headers When redundant data is used, additional headers specify the redundant text fields. They are specified according to RFC 2198 and use dynamic payload type "T140". 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra framing. When using the format with redundant data, the transmitter MAY select a number of T.140 block generations to retransmit in each packet. A higher number introduces better protection against loss of text. It is RECOMMENDED to use no more than 6 generations. The redundant data is placed in age order with most recent redundant text last in the redundance area. 3. Recommended procedures This section contains RECOMMENDED procedures for usage of the payload format. Based on the information in the received packets, the receiver can: - reorder received text out of order. - mark where text is missing because of packet loss. - compensate for lost packets by using redundant data. Hellstr÷m [Page 3]
Internet Draft 3.1 Recommended basic procedure On reception, the RTP sequence number is compared with the sequence number of the last correctly received packet. If they are consecutive, only the most recent t140block is retrieved from the received packet. 3.2 Recommended procedure for compensation for lost packets. For reduction of data loss in case of packet loss, redundant data MAY be included in the packets. If network conditions are not known, it is RECOMMENDED to use two generations of T.140 blocks in the packets. If there is a gap in the RTP sequence numbers, and redundancy coded T.140blocks are available in the packet, older t140blocks are retrieved from the packet up to the point where the sequence number is consecutive to the last correctly received packet or no more t140block are available in the received packet. Both for the case when redundancy is used and not used, missing data SHALL be marked. If there is still a gap in the sequence, one T.140 missing data marker ( Unicode character 2607 "Lightning") SHALL be inserted, UTF-8 coded, replacing each missing t140block. 3.3 Recommended procedure for compensation for packets out of order. For protection against packets arriving out of order, the following procedure MAY be implemented in the receiver. If analysis of a received packet reveals gaps in the sequence, the received packet can be kept in a buffer before being used as valid T.140 data. If a packet arrives with a t140block belonging to the gap, the gap is filled with the contents of this block. If all gaps are filled or the packet is kept in the buffer for 0.5 seconds, valid T140blocks in the buffered packet are retrieved and used as valid T.140 data. For each t140block still missing, a T.140 missing data marker (Unicode character 2607 "Lightning") is inserted. 3.4 Transmission during "silent periods" when redundancy is used. When using the redundancy transmission scheme, and there is nothing more to transmit from T.140, the latest t140block has a risk of getting old before it is transmitted as redundant data. The result is less useful protection against packet loss at the end of a text input sequence. For cases where this should be avoided, the ISO 10 646 synchronization character FEFF MAY be transmitted (UTF-8 coded) after some time of inactivity. Hellstr÷m [Page 4]
Internet Draft 4. Examples This is an example of a T140 RTP packet without redundancy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| T140 dyn PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (1000Hz) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + T140 encoded data (PT=dynamic) + | | + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is an example of an RTP packet with two t140 blocks using redundancy coding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| "RED" PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding "P" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| T140 dyn. PT| timestamp offset of "R" | "R" block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| T140 dyn. PT| | +-+-+-+-+-+-+-+-+ + | | + "R" T140 encoded redundant data (PT=dynamic T140) + | | + +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | "P" T140 encoded primary data (PT=dynamic T140) | + + + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure: Examples of RTP text packets. Hellstr÷m [Page 5]
Internet Draft 5. Security Considerations. Since the intention of the described payload format is to carry text in a text conversation, security measures in the form of encryption is of importance. The amount of data in a text conversation session is low and therefore any encryption method MAY be selected and applied to T.140 session contents or to the whole RTP packets. When redundant data is included, the same security considerations as for RFC 2198 apply. 6 MIME Media Type Registrations This document defines a new RTP payload name and associated MIME type, T140 (text/t140). The registration form for this MIME type has been submitted to IANA. 6.1 Registration of MIME media type text/t140 MIME media type name: text MIME subtype name: t140 Required parameters: None Optional parameters: None Encoding considerations: T140 text can be transmitted with RTP as specified in "draft-ietf-avt-rtp-text-01". Security considerations: None Interoperability considerations: None Published specification: ITU-T T.140 Recommendation. draft-ietf-avt-rtp-text-01. Applications which use this media type: Text communication terminals and text conferencing tools. Additional information: None Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Intended usage: COMMON Author/Change controller: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Hellstr÷m [Page 6]
Internet Draft Expires: April 6, 2000 7. Author's Address Gunnar Hellstrom Ericsson Mobile Communication AB Home Communications SE-164 80 Stockholm Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 8 References [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1999. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "Real Time Transport Protocol", RFC 1889. [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, "RTP payload for redundant audio data," RFC 2198, Internet Engineering Task Force, Sept. 1997. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 9 Revision history. Oct 6 1999. draft-01. Explanations in recommended procedures improved. Hellstr÷m [Page 7]
