summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4103.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4103.txt')
-rw-r--r--doc/rfc/rfc4103.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4103.txt b/doc/rfc/rfc4103.txt
new file mode 100644
index 0000000..f5def43
--- /dev/null
+++ b/doc/rfc/rfc4103.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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
+ Section 10). If redundancy is used per RFC 2198,
+ another payload type number needs to be provided
+ for the redundancy format. The MIME type for
+ identifying RFC 2198 is available in RFC 4102 [9].
+
+ Sequence number: The definition of sequence numbers is available in
+ RFC 3550 [2]. When transmitting text using the
+ payload format for text/t140, it is used for
+ detection of packet loss and out-of-order packets,
+ and can be used in the process of retrieval of
+ redundant text, reordering of text and marking
+ missing text.
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 5]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ 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. Because packets do not represent any
+ constant duration, the timestamp cannot be used to
+ directly infer packet loss.
+
+ M-bit: The M-bit MUST be included. The first packet in a
+ session, and the first packet after an idle
+ period, SHOULD be distinguished by setting the
+ marker bit in the RTP data header to one. The
+ marker bit in all other packets MUST be set to
+ zero. The reception of the marker bit MAY be used
+ for refined methods for detection of loss.
+
+4. Protection against Loss of Data
+
+ Consideration must be devoted to keeping loss of text due to packet
+ loss within acceptable limits. (See ITU-T F.703 [17])
+
+ The default method that MUST be used, when no other method is
+ explicitly selected, is redundancy in accordance with RFC 2198 [3].
+ When this method is used, the original text and two redundant
+ generations SHOULD be transmitted if the application or end-to-end
+ conditions do not call for other levels of redundancy to be used.
+
+ Forward Error Correction mechanisms, as per RFC 2733 [8], or any
+ other mechanism with the purpose of increasing the reliability of
+ text transmission, MAY be used as an alternative or complement to
+ redundancy. Text data MAY be sent without additional protection if
+ end-to-end network conditions allow the text quality requirements,
+ specified in ITU-T F.703 [17], to be met in all anticipated load
+ conditions.
+
+4.1. Payload Format When Using Redundancy
+
+ When using the payload 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 marginally increases the data rate.
+
+ 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, in addition to a payload type number
+ (indicating the payload format text/t140).
+
+
+
+
+Hellstrom & Jones Standards Track [Page 6]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ The redundant data block headers are followed by the redundant data
+ fields carrying T140blocks from previous packets. Finally, the new
+ (primary) T140block for this packet follows.
+
+ Redundant data that would need a timestamp offset higher than 16383
+ (due to its age at transmission) MUST NOT be included in transmitted
+ packets.
+
+4.2. Using Redundancy with the text/t140 Format
+
+ Because text is transmitted only when there is text to transmit, the
+ timestamp is not used to identify a lost packet. Rather, missing
+ sequence numbers are used to detect lost text packets at reception.
+ Also, because sequence numbers are not provided in the redundant
+ header, some additional rules must be followed to allow redundant
+ data that corresponds to missing primary data to be properly merged
+ into the stream of primary data T140blocks. They are:
+
+ - Each redundant data block MUST contain the same data as a T140block
+ previously transmitted as primary data.
+
+ - The redundant data MUST be placed in age order, with the 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.
+
+ If there is a gap in the received 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.
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 7]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+5. Recommended Procedure
+
+ 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.
+
+5.1. Recommended Basic Procedure
+
+ Packets are transmitted when there is valid T.140 data to transmit.
+
+ T.140 specifies that T.140 data MAY be buffered for transmission with
+ a maximum buffering time of 500 ms. A buffering time of 300 ms is
+ RECOMMENDED when the application or end-to-end network conditions are
+ not known to require another value.
+
+ If no new data is available for a longer period than the buffering
+ time, the transmission process is in an idle period.
+
+ When new text is available for transmission after an idle period, it
+ is RECOMMENDED to send it as soon as possible. After this
+ transmission, it is RECOMMENDED to buffer T.140 data in buffering
+ time intervals, until the next idle period. This is done in order to
+ keep the maximum bit rate usage for text at a reasonable level. The
+ buffering time MUST be selected so that text users will perceive a
+ real-time text flow.
+
+5.2. Transmission before and after "Idle Periods"
+
+ When valid T.140 data has been sent and no new T.140 data is
+ available for transmission after the selected buffering time, an
+ empty T140block SHOULD be transmitted. This situation is regarded as
+ the beginning of an idle period. The procedure is recommended in
+ order to more rapidly detect potentially missing text before an idle
+ period.
+
+ An empty T140block contains no data.
+
+ When redundancy is used, transmission continues with a packet at
+ every transmission timer expiration and insertion of an empty
+ T.140block as primary, until the last non-empty T140block has been
+ transmitted, as primary and as redundant data, with all intended
+ generations of redundancy. The last packet before an idle period
+ will contain only one non-empty T140block as redundant data, while
+ the remainder of the redundancy packet will contain empty T140blocks.
+
+
+
+Hellstrom & Jones Standards Track [Page 8]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ Any empty T140block sent as primary data MUST be included as
+ redundant T140blocks in subsequent packets, just as normal text
+ T140blocks would be, unless the empty T140block is too old to be
+ transmitted. This is done so that sequence number inference for the
+ redundant T140blocks will be correct, as explained in Section 4.2.
+
+ After an idle period, the transmitter SHOULD set the M-bit to one in
+ the first packet with new text.
+
+5.3. Detection of Lost Text Packets
+
+ Packet loss for text/t140 packets MAY be detected by observing gaps
+ in the sequence numbers of RTP packets received by the receiver.
+
+ With text/t140, the loss of packets is usually detected by comparison
+ of the sequence of RTP packets as they arrive. Any discrepancy MAY
+ be used to indicate loss. The highest RTP sequence number received
+ may also be compared with that in RTCP reports, as an additional
+ check for loss of the last packet before an idle period.
+
+ 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].
+
+ Because empty T140blocks are transmitted in the beginning of an idle
+ period, there is a slight risk of falsely marking loss of text, when
+ only an empty T140block was lost. Procedures based on detection of
+ the packet with the M-bit set to one MAY be used to reduce the risk
+ of introducing false markers of loss.
+
+ If redundancy is used with the text/t140 format, and a packet is
+ received with fewer redundancy levels than normally in the session,
+ it SHOULD be treated as if one empty T140block has been received for
+ each excluded level in the received packet. This is because the only
+ occasion when a T140block is excluded from transmission is when it is
+ an empty T140block that has become too old to be transmitted.
+
+ If two successive packets have the same number of redundant
+ generations, it SHOULD be treated as the general redundancy level for
+ the session. Change of the general redundancy level SHOULD only be
+ done after an idle period.
+
+ The text/t140 format relies on use of the sequence number in the RTP
+ packet header for detection of loss and, therefore, is not suitable
+ for applications where it needs to be alternating with other payloads
+ in the same RTP stream. It would be complicated and unreliable to
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 9]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ try to detect loss of data at the edges of the shifts between t140
+ text and other stream contents. Therefore, text/t140 is RECOMMENDED
+ to be the only payload type in the RTP stream.
+
+5.4. 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 SHOULD be kept in
+ a buffer to allow time for the missing packet(s) to arrive. It is
+ RECOMMENDED that the waiting time be limited to 1 second.
+
+ 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 that does not arrive before the time limit
+ expires should be treated as lost and a missing text marker should be
+ inserted (see Section 5.3).
+
+6. Parameter for Character Transmission Rate
+
+ In some cases, it is necessary to limit the rate at which characters
+ are transmitted. For example, when a Public Switched Telephone
+ Network (PSTN) gateway is interworking between an IP device and a
+ PSTN textphone, it may be necessary to limit the character rate from
+ the IP device in order to avoid throwing away characters (in case of
+ buffer overflow at the PSTN gateway).
+
+ To control the character transmission rate, the MIME parameter "cps"
+ in the "fmtp" attribute [7] is defined (see Section 10 ). It is used
+ in SDP with the following syntax:
+
+ a=fmtp:<format> cps=<integer>
+
+ The <format> field is populated with the payload type that is used
+ for text. The <integer> field contains an integer representing the
+ maximum number of characters that may be received per second. The
+ value shall be used as a mean value over any 10-second interval. The
+ default value is 30.
+
+ Examples of use in SDP are found in Section 7.2.
+
+ In receipt of this parameter, devices MUST adhere to the request by
+ transmitting characters at a rate at or below the specified <integer>
+ value. Note that this parameter was not defined in RFC 2793 [16].
+ Therefore implementations of the text/t140 format may be in use that
+ do not recognize and act according to this parameter. Therefore,
+
+
+
+Hellstrom & Jones Standards Track [Page 10]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ receivers of text/t140 MUST be designed so they can handle temporary
+ reception of characters at a higher rate than this parameter
+ specifies. As a result malfunction due to buffer overflow is avoided
+ for text conversation with human input.
+
+7. Examples
+
+7.1. RTP Packetization Examples for the text/t140 Format
+
+ Below is an example of a text/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 |
+ + +---------------+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Below is an example of a text/t140 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 11]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ Below is an example of an RTP packet with one redundant T140block
+ using text/t140 payload format. The primary data block is empty,
+ which is the case when transmitting a packet for the sole purpose of
+ forcing the redundant data to be transmitted in the absence of any
+ new data.
+
+ 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 |
+ +-+-+-+-+-+-+-+-+ +---------------+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ As a follow-on to the previous example, the example below shows the
+ next RTP packet in the sequence, which does contain a real T140block
+ when using the text/t140 payload format. Note that the empty block
+ is present in the redundant transmissions of the text/t140 payload
+ format. This example shows two levels of redundancy and one primary
+ data block. The value of the "R2 block length" would be set to zero
+ in order to represent the empty T140block.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 12]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ 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 "R2" | "R2" block length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| T140 PT | timestamp offset of "R1" | "R1" block length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| T140 PT | "R1" T.140 encoded redundant data |
+ +-+-+-+-+-+-+-+-+ +---------------+
+ | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
+ | "P" T.140 encoded primary data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+7.2. SDP Examples
+
+ Below is an example of SDP, which describes RTP text transport on
+ port 11000:
+
+ m=text 11000 RTP/AVP 98
+ a=rtpmap:98 t140/1000
+
+ Below is an example of SDP that is similar to the above example, but
+ also utilizes RFC 2198 to provide the recommended two levels of
+ redundancy for the text packets:
+
+ m=text 11000 RTP/AVP 98 100
+ a=rtpmap:98 t140/1000
+ a=rtpmap:100 red/1000
+ a=fmtp:100 98/98/98
+
+ Note: Although these examples utilize the RTP/AVP profile, it is not
+ intended to limit the scope of this memo. Any appropriate profile
+ may be used in conjunction with this memo.
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 13]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+8. Security Considerations
+
+ All of the security considerations from Section 14 of RFC 3550 [2]
+ apply.
+
+8.1. Confidentiality
+
+ Because 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. Therefore, any encryption method MAY be
+ selected and applied to T.140 session contents or to whole RTP
+ packets. Secure Real-time Transport Protocol (SRTP) [14] provides a
+ suitable method for ensuring confidentiality.
+
+8.2. Integrity
+
+ It may be desirable to protect the text contents of an RTP stream
+ against manipulation. SRTP [14] provides methods for providing
+ integrity that MAY be applied.
+
+8.3. Source Authentication
+
+ There are several methods of making sure the source of the text is
+ the intended one.
+
+ Text streams are usually used in a multimedia control environment.
+ Security measures for authentication are available and SHOULD be
+ applied in the registration and session establishment procedures, so
+ that the identity of the sender of the text stream is reliably
+ associated with the person or device setting up the session. Once
+ established, SRTP [14] mechanisms MAY be applied to ascertain that
+ the source is maintained the same during the session.
+
+9. Congestion Considerations
+
+ The congestion considerations from Section 10 of RFC 3550 [2],
+ Section 6 of RFC 2198 [3], and any used profile (e.g., the section
+ about congestion in chapter 2 of RFC 3551 [11]) apply with the
+ following application-specific considerations.
+
+ Automated systems MUST NOT use this format to send large amounts of
+ text at rates significantly above those a human user could enter.
+
+ Even if the network load from users of text conversation is usually
+ very low, for best-effort networks an application MUST monitor the
+ packet loss rate and take appropriate actions to reduce its sending
+ rate (if this application sends at higher rate than what TCP would
+
+
+
+Hellstrom & Jones Standards Track [Page 14]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ achieve over the same path). The reason for this is that this
+ application, due to its recommended usage of two or more redundancy
+ levels, is very robust against packet loss. At the same time, due to
+ the low bit-rate of text conversations, if one considers the
+ discussion in RFC 3714 [13], this application will experience very
+ high packet loss rates before it needs to perform any reduction in
+ the sending rate.
+
+ If the application needs to reduce its sending rate, it SHOULD NOT
+ reduce the number of redundancy levels below the default amount
+ specified in Section 4. Instead, the following actions are
+ RECOMMENDED in order of priority:
+
+ - Increase the shortest time between transmissions (described in
+ Section 5.1) from the recommended 300 ms to 500 ms, which is the
+ highest value allowed according to T.140.
+
+ - Limit the maximum rate of characters transmitted.
+
+ - Increase the shortest time between transmissions to a higher value,
+ not higher than 5 seconds. This will cause unpleasant delays in
+ transmission, beyond what is allowed according to T.140, but text
+ will still be conveyed in the session with some usability.
+
+ - Exclude participants from the session.
+
+ Please note that if the reduction in bit-rate achieved through the
+ above measures is not sufficient, the only remaining action is to
+ terminate the session.
+
+ As guidance, some load figures are provided here as examples based on
+ use of IPv4, including the load from IP, UDP, and RTP headers without
+ compression .
+
+ - Experience tells that a common mean character transmission rate,
+ during a complete PSTN text telephony session, is around two
+ characters per second.
+
+ - A maximum performance of 20 characters per second is enough even
+ for voice-to-text applications.
+
+ - With the (unusually high) load of 20 characters per second, in a
+ language that makes use of three octets per UTF-8 character, two
+ redundant levels, and 300 ms between transmissions, the maximum
+ load of this application is 3300 bits/s.
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 15]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ - When the restrictions mentioned above are applied, limiting
+ transmission to 10 characters per second, using 5 s between
+ transmissions, the maximum load of this application, in a language
+ that uses one octet per UTF-8 character, is 300 bits/s.
+
+ Note that this payload can be used in a congested situation as a last
+ resort to maintain some contact when audio and video media need to be
+ stopped. The availability of one low bit-rate stream for text in
+ such adverse situations may be crucial for maintaining some
+ communication in a critical situation.
+
+10. IANA Considerations
+
+ This document updates the RTP payload format named "t140" and the
+ associated MIME type "text/t140", in the IANA RTP and Media Type
+ registries.
+
+10.1. Registration of MIME Media Type text/t140
+
+ MIME media type name: text
+
+ MIME subtype name: t140
+
+ Required parameters: rate: The RTP timestamp clock rate, which is
+ equal to the sampling rate. The only valid value is 1000.
+
+ Optional parameters: cps: The maximum number of characters that may
+ be received per second. The default value is 30.
+
+ Encoding considerations: T.140 text can be transmitted with RTP as
+ specified in RFC 4103.
+
+ Security considerations: See Section 8 of RFC 4103.
+
+ Interoperability considerations: This format is the same as specified
+ in RFC2793. For RFC2793 the "cps=" parameter was not defined.
+ Therefore, there may be implementations that do not consider this
+ parameter. Receivers need to take that into account.
+
+ Published specification: ITU-T T.140 Recommendation. RFC 4103.
+
+ Applications which use this media type: Text communication terminals
+ and text conferencing tools.
+
+ Additional information: This type is only defined for transfer via
+ RTP.
+
+ Magic number(s): None
+
+
+
+Hellstrom & Jones Standards Track [Page 16]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+ 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 | IETF avt WG
+ gunnar.hellstrom@omnitor.se |
+
+10.2. SDP Mapping of MIME Parameters
+
+ The information carried in the MIME media type specification has a
+ specific mapping to fields in the Session Description Protocol (SDP)
+ [7], which is commonly used to describe RTP sessions. When SDP is
+ used to specify sessions employing the text/t140 format, the mapping
+ is as follows:
+
+ - The MIME type ("text") goes in SDP "m=" as the media name.
+
+ - The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
+ the encoding name. The RTP clock rate in "a=rtpmap" MUST be 1000
+ for text/t140.
+
+ - The parameter "cps" goes in SDP "a=fmtp" attribute.
+
+ - When the payload type is used with redundancy according to RFC
+ 2198, the level of redundancy is shown by the number of elements in
+ the slash-separated payload type list in the "fmtp" parameter of
+ the redundancy declaration as defined in RFC 4102 [9] and RFC 2198
+ [3].
+
+10.3. Offer/Answer Consideration
+
+ In order to achieve interoperability within the framework of the
+ offer/answer model [10], the following consideration should be made:
+
+ - The "cps" parameter is declarative. Both sides may provide a
+ value, which is independent of the other side.
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 17]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+11. Acknowledgements
+
+ The authors want to thank Stephen Casner, Magnus Westerlund, 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, Michele
+ Mizarro for verification of the usability of the payload format for
+ its intended purpose, and Andreas Piirimets for editing support and
+ validation.
+
+12. Normative 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
+ 3550, July 2003.
+
+ [3] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
+ Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "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", STD
+ 63, RFC 3629, November 2003.
+
+ [7] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
+ Generic Forward Error Correction", RFC 2733, December 1999.
+
+ [9] Jones, P., "Registration of the text/red MIME Sub-Type", RFC
+ 4102, June 2005.
+
+ [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ the Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conference with Minimal Control", STD 65, RFC 3551, July 2003.
+
+ [12] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+
+
+Hellstrom & Jones Standards Track [Page 18]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+13. Informative References
+
+ [13] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
+ Control for Voice Traffic in the Internet", RFC 3714, March
+ 2004.
+
+ [14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+ 3711, March 2004.
+
+ [15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
+ Telephony Tones and Telephony Signals", RFC 2833, May 2000.
+
+ [16] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793,
+ May 2000.
+
+ [17] ITU-T Recommendation F.703, Multimedia Conversational Services,
+ November 2000.
+
+Authors' Addresses
+
+ Gunnar Hellstrom
+ Omnitor AB
+ Renathvagen 2
+ SE-121 37 Johanneshov
+ Sweden
+
+ Phone: +46 708 204 288 / +46 8 556 002 03
+ Fax: +46 8 556 002 06
+ EMail: gunnar.hellstrom@omnitor.se
+
+
+ Paul E. Jones
+ Cisco Systems, Inc.
+ 7025 Kit Creek Rd.
+ Research Triangle Park, NC 27709
+ USA
+
+ Phone: +1 919 392 6948
+ EMail: paulej@packetizer.com
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 19]
+
+RFC 4103 RTP Payload for Text Conversation June 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Hellstrom & Jones Standards Track [Page 20]
+