Internet Engineering Task Force AVT WG Internet Draft Gunnar Hellström draft-hellstrom-avt-rtp-text-00.txt L M Ericsson June 25, 1999 Expires: Dec 25, 1999 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. 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 Hellström [Page 1] Internet Draft 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. 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. 2. Usage of RTP When an unreliable transport of T.140 text session data in the Internet is selected, RTP with payload as described in this specification should be used. T.140 data is submitted for transmission in a numer of complete protocol data units (a T140block consisting of one or more T140 PDU:s). The most common T140 PDU is a character of ISO 10646 text, UTF-8 coded, submitted from T.140 without any extra framing. 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): If redundancy is used, the Payload Type shall indicate redundancy according to RFC 2198. If no redundnacy is used, the Payload Type shall specify the primary T.140 text 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. Hellström [Page 2] Internet Draft Timestamp: The RTP Timestamp encodes the approximate sampling instance of the primary text in the packet. No 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 payload type "redundant T.140 data". 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra framing. The primary T.140 data is identified with the payload type "primary T.140 data". The transmitting station may select a number of T.140 block generations to retransmit in each packet. A higher number introduces better protection against loss of text. If network conditions are not known, it is recommended to use two generations. A maximum of 6 generations may be specified. 3. Procedures 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. ---note-procedure description for insertion in a protocol spec-------- 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 submitted from the packet to T.140. Compensation for lost packets. If there is a gap in the RTP sequence numbers, 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 is available in the received packet. If there is still a gap in the sequence, one T.140 missing data marker ( Unicode character 2607 "Lightning") is inserted, UTF-8 coded, replacing each missing t140block. All t140blocks retrieved in this way are submitted to the receiving T.140 instance. Hellström [Page 3] Internet Draft Expires 25 Dec 1999 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 submission to the T.140 layer. 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 submitted to the T.140 layer. For each t140block still missing, a T.140 missing data marker (Unicode character 2607 "Lightning") is inserted. --------- end of note ------------------------------------------------ 4. Security Considerations The same security considerations as for RFC 2198 apply. 5 Authors Address Gunnar Hellström L M Ericsson Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 6 Bibliography [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application. Hellström [Page 4]