summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2793.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2793.txt')
-rw-r--r--doc/rfc/rfc2793.txt563
1 files changed, 563 insertions, 0 deletions
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]
+