From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2793.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc2793.txt (limited to 'doc/rfc/rfc2793.txt') diff --git a/doc/rfc/rfc2793.txt b/doc/rfc/rfc2793.txt new file mode 100644 index 0000000..7f83655 --- /dev/null +++ b/doc/rfc/rfc2793.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group G. Hellstrom +Request for Comments: 2793 Omnitor AB +Category: Standards Track May 2000 + + + 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 (2000). All Rights Reserved. + +Abstract + + This memo describes how to carry 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. + + 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 sent as soon as it is available, or + with a small delay for buffering. + + + + + + + + +Hellstrom Standards Track [Page 1] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + + 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 MUST 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 payload of an RTP packet following 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. If lost information can be indicated, 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, and with detection + and indication of losses. It also includes an optional possibility + to repeat data for redundancy to lower the risk of loss. 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 transport of T.140 text session data in RTP is desired, the + payload as described in this specification SHOULD be used. + + A text conversation RTP packet as specified by this payload format + consists of an RTP header as defined in RFC 1889 [2] followed + immediately by a block of T.140 data, defined here to be a + "T140block". There is no additional header specific to this payload + format. 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. This implies + that each block MUST contain an integral number of UTF-8 encoded + + + +Hellstrom Standards Track [Page 2] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + + characters regardless of the number of octets per character. It also + implies that any composite character sequence (CCS) SHOULD be placed + within one block. + + The T140blocks MAY be transmitted redundantly according to the + payload format defined in RFC 2198 [3]. In that case, the RTP header + is followed by one or more redundant data block headers, the same + number of redundant data fields carrying T140blocks from previous + packets, and finally the new (primary) T140block for this packet. + +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): The assignment of an RTP payload type is specific + to the RTP profile under which this payload format is used. For + profiles which use dynamic payload type number assignment, this + payload format is identified by the name "T140" (see section 6). + If redundancy is used per RFC 2198, the Payload Type MUST indicate + that payload format ("RED"). + + Sequence number: The Sequence Number MUST be increased by 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 instance of + entry of the primary text in the packet. A clock frequency of 1000 + Hz MUST be used. Sequential packets MUST NOT use the same + timestamp. Since packets do not represent any constant duration, + the timestamp cannot be used to directly infer packet losses. + +2.2 Additional headers + + There are no additional headers defined specific to this payload + format. + + When redundant transmission of the data according to RFC 2198 is + desired, the RTP header is followed by one or more redundant data + block headers, one for each redundant data block to be included. + Each of these headers provides the timestamp offset and length of the + corresponding data block plus a payload type number indicating this + payload format ("T140"). + + + + + + +Hellstrom Standards Track [Page 3] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +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 T140block generations to retransmit in each + packet. A higher number introduces better protection against loss of + text but increases the data rate. + + Since packets are not generated at regular intervals, the timestamp + is not sufficient to identify a packet in the presence of loss unless + extra information is provided. Since sequence numbers are not + provided in the redundant header, some additional rules must be + followed to allow the redundant data corresponding to missing primary + data to be merged properly into the stream of primary data + T140blocks: + + - Each redundant data block MUST contain the same data as a + T140block previously transmitted as primary data, and be + identified with a timestamp offset equating to the original + timestamp for that T140block. + - The redundant data MUST be placed in age order with most + recent redundant T140block last in the redundancy area. + - All T140blocks from the oldest desired generation up through + the generation immediately preceding the new (primary) + T140block MUST be included. + + These rules allow the sequence numbers for the redundant T140blocks + to be inferred by counting backwards from the sequence number in the + RTP header. The result will be that all the text in the payload will + be contiguous and in order. + +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 text received out of order. + - mark where text is missing because of packet loss. + - compensate for lost packets by using redundant data. + + + + + + + + + + + +Hellstrom Standards Track [Page 4] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +3.1 Recommended basic procedure + + Packets are transmitted only when there is valid T.140 data to + transmit. The sequence number is used for sequencing of T.140 data. + + On reception, the RTP sequence number is compared with the sequence + number of the last correctly received packet. If they are + consecutive, the (only or primary) T140block is retrieved from the + 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 following to the procedures in RFC 2198. + If network conditions are not known, it is RECOMMENDED to use one + redundant T140block in each packet. If there is a gap in the RTP + sequence numbers, and redundant T140blocks are available in a + subsequent packet, the sequence numbers for the redundant T140blocks + should be inferred by counting backwards from the sequence number in + the RTP header for that packet. If there are redundant T140blocks + with sequence numbers matching those that are missing, the redundant + T140blocks may be substituted for the missing T140blocks. + + Both for the case when redundancy is used and not used, missing data + SHOULD be marked by insertion of a missing text marker in the + received stream for each missing T140block, as specified in ITU-T + T.140. Addendum 1 [1]. + +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 a gap in the sequence and no redundant data + is available to fill that gap, the received packet can be kept in a + buffer to allow time for the missing packet(s) to arrive. It is + suggested that the waiting time be limited to 0.5 seconds. For the + case when redundancy is used the waiting time SHOULD be extended to + the number of redundancy generations times the T.140 buffering timer + if this product is known to be greater than 0.5 seconds. + + If a packet with a T140block belonging to the gap arrives before the + waiting time expires, this T140block is inserted into the gap and + then consecutive T140blocks from the leading edge of the gap may be + consumed. Any T140block which does not arrive before the time limit + expires should be treated as lost. + + + + + + +Hellstrom Standards Track [Page 5] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +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, a zero-length + primary T140block MAY be transmitted with the redundant data. + + Any zero-length T140blocks that are sent as primary data MUST be + included as redundant T140blocks on subsequent packets just as normal + text T140blocks would be so that sequence number inference for the + redundant T140blocks will be correct, as explained in section 2.3. + + Redundancy for the last T140block SHOULD NOT be implemented by + repeatedly transmitting the same packet (with the same sequence + number) because this will cause the packet loss count, as reported in + RTCP, to decrement. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hellstrom Standards Track [Page 6] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +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 PT | sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | timestamp (1000Hz) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + T.140 encoded data + + | | + + +---------------+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This is an example of an RTP packet with one redundant T140block. + 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 PT | timestamp offset of "R" | "R" block length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0| T140 PT | | + +-+-+-+-+-+-+-+-+ + + | | + + "R" T.140 encoded redundant data + + | | + + +---------------+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | "P" T.140 encoded primary data | + + + + + +---------------+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure: Examples of RTP text packets. + + + + + + +Hellstrom Standards Track [Page 7] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +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 + are 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). + +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 RFC 2793. + + Security considerations: None + + Interoperability considerations: None + + Published specification: ITU-T T.140 Recommendation. + RFC 2793. + + 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 + + + + +Hellstrom Standards Track [Page 8] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + + Intended usage: COMMON + Author / Change controller: + Gunnar Hellstrom | IETF avt WG + gunnar.hellstrom@omnitor.se | c/o Steve Casner casner@cisco.com + +7. Author's Address + + Gunnar Hellstrom + Omnitor AB + Alsnogatan 7, 4 tr + SE-116 41 Stockholm + Sweden + + Phone: +46 708 204 288 / +46 8 556 002 03 + Fax: +46 8 556 002 06 + EMail: gunnar.hellstrom@omnitor.se + +8. Acknowledgements + + The author wants to thank Stephen Casner and Colin Perkins for + valuable support with reviews and advice on creation of this + document, to Mickey Nasiri at Ericsson Mobile Communication for + providing the development environment, and Michele Mizarro for + verification of the usability of the payload format for its intended + purpose. + +9. References + + [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol + for multimedia application, with amendment 1, (2000). + + [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 1889, January 1996. + + [3] Perkins, C., Kouvelas, I., Hardman, V., Handley, M. and J. + Bolot, "RTP Payload for Redundant Audio Data", RFC 2198, + September 1997. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded + Character Set. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + + + +Hellstrom Standards Track [Page 9] + +RFC 2793 RTP Payload for Text Conversation May 2000 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hellstrom Standards Track [Page 10] + -- cgit v1.2.3