doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc4351.txt b/doc/rfc/rfc4351.txt
new file mode 100644
index 0000000..64c35fb
--- /dev/null
+++ b/doc/rfc/rfc4351.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                       G. Hellstrom
+Request for Comments: 4351                                    Omnitor AB
+Category: Historic                                              P. Jones
+                                                     Cisco Systems, Inc.
+                                                            January 2006
+
+
+             Real-Time Transport Protocol (RTP) Payload for
+           Text Conversation Interleaved in an Audio Stream
+
+Status of This Memo
+
+   This memo defines a Historic Document for the Internet community.  It
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo 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 audio and text data
+   within a single RTP session.
+
+   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               Historic                        [Page 1]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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 audio/t140c Data ........4
+      3.3. The "T140block" ............................................5
+      3.4. Synchronization of Text with Other Media ...................5
+      3.5. Synchronization Considerations for the audio/t140c Format ..5
+      3.6. RTP Packet Header ..........................................6
+   4. Protection against Loss of Data .................................7
+      4.1. Payload Format When Using Redundancy .......................7
+      4.2. Using Redundancy with the audio/t140c Format ...............8
+   5. Recommended Procedure ...........................................8
+      5.1. Recommended Basic Procedure ................................8
+      5.2. Transmission before and after "Idle Periods" ...............9
+      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 audio/t140c Format .....11
+      7.2. SDP Examples ..............................................12
+   8. Security Considerations ........................................13
+      8.1. Confidentiality ...........................................13
+      8.2. Integrity .................................................13
+      8.3. Source Authentication .....................................13
+   9. Congestion Considerations ......................................14
+   10. IANA Considerations ...........................................15
+      10.1. Registration of MIME Media Type audio/t140c ..............15
+      10.2. SDP Mapping of MIME Parameters ...........................16
+      10.3. Offer/Answer Consideration ...............................17
+   11. Acknowledgements ..............................................17
+   12. Normative References ..........................................17
+   13. Informative References ........................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                        [Page 2]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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 to 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.
+   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.
+
+   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 to lower the risk of loss.  Since 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, as examples, conferencing systems, firewalls, and network
+   translation devices.  This, in turn, eases the design and increases
+   the possibility for prompt and proper media delivery.
+
+   This document introduces a method of transporting text interleaved
+   with voice within the same RTP session.
+
+
+
+Hellstrom & Jones               Historic                        [Page 3]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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 use between Public Switched
+   Telephone Network (PSTN) gateways and is called audio/t140c.
+
+3.1.  Motivations and Rationale
+
+   The audio/t140c payload specification is intended to allow gateways
+   that are interconnecting two PSTN networks to interleave, through a
+   single RTP session, audio and text data received on the PSTN circuit.
+   This is comparable to the way in which dual-tone multifrequency
+   (DTMF) is extracted and transmitted within an RTP session [14].
+
+   The audio/t140c format SHALL NOT be used for applications other than
+   PSTN gateway applications.  In such applications, a specific
+   profiling document MAY make it REQUIRED for a specific application.
+   The reason to prefer to use audio/t140c could be for gateway
+   application where the ports are a limited and scarce resource.
+   Applications SHOULD use RFC 4103 [15] for real-time text
+   communication that falls outside the limited scope of this
+   specification.
+
+3.2.  Payload Format for Transmission of audio/t140c Data
+
+   An audio/t140c conversation RTP payload format consists of a 16-bit
+   "T140block counter" carried in network byte order (see RFC 791 [11]
+   Annex B), followed by one and only one "T140block" (see section 3.3).
+   The fields in the RTP header are set as defined in section 3.6.
+
+   The T140block counter MUST be initialized to zero the first time that
+   a packet containing a T140block is transmitted and MUST be
+   incremented by 1 each time that a new block is transmitted.  Once the
+   counter reaches the value 0xFFFF, the counter is reset to 0 the next
+   time the counter is incremented.  This T140block counter is used to
+   detect lost blocks and to avoid duplication of blocks.
+
+   For the purposes of readability, the remainder of this document
+   refers only to the T140block without making explicit reference to the
+   T140block counter.  Readers should understand that when using the
+   audio/t140c format, the T140block counter MUST always precede the
+   actual T140block, including redundant data transmissions.
+
+
+
+Hellstrom & Jones               Historic                        [Page 4]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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).  Association of RTP
+   streams can be done through the CNAME field of RTP Control Protocol
+   (RTCP) SDES function.  It is dependent on the particular application
+   and is outside the scope of this document.
+
+3.5.  Synchronization Considerations for the audio/t140c Format
+
+   The audio/t140c packets are generally transmitted as interleaved
+   packets between voice packets or other kinds of audio packets with
+   the intention to create one common audio signal in the receiving
+   equipment to be used for alternating between text and voice.  The
+   audio/t140c payload is then used to play out audio signals according
+   to a PSTN textphone coding method (usually a modem).
+
+   One should observe the RTP timestamps of the voice, text, or other
+   audio packets in order to reproduce the stream correctly when playing
+   out the audio.  Also, note that incoming text from a PSTN circuit
+   might be at a higher bit-rate than can be played out on an egress
+   PSTN circuit.  As such, it is possible that, on the egress side, a
+   gateway may not complete the play out of the text packets before it
+   is time to play the next voice packet.  Given that this application
+   is primarily for the benefit of users of PSTN textphone devices, it
+   is strongly RECOMMENDED that all received text packets be properly
+   reproduced on the egress gateway before considering any other
+   subsequent audio packets.
+
+   If necessary, voice and other audio packets should be discarded in
+   order to properly reproduce the text signals on the PSTN circuit,
+   even if the text packets arrive late.
+
+
+
+
+Hellstrom & Jones               Historic                        [Page 5]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   The PSTN textphone users commonly use turn-taking indicators in the
+   text stream, so it can be expected that as long as text is
+   transmitted, it is valid text and should be given priority over
+   voice.
+
+   Note that the usual RTP semantics apply with regards to switching
+   payload formats within an RTP session.  A sender MAY switch between
+   "audio/t140c" and some other format within an RTP session, but MUST
+   NOT send overlapping data using two different audio formats within an
+   RTP session.  This does not prohibit an implementation from being
+   split into two logical parts to send overlapping data, each part
+   using a different synchronization source (SSRC) and sending its own
+   RTP and RTCP (such an endpoint will appear to others in the session
+   as two participants with different SSRCs, but the same RTCP SDES
+   CNAME).  Further details around using multiple payloads in an RTP
+   session can be found in RFC 3550 [2].
+
+3.6.  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 this payload format is used.  For
+      profiles that use dynamic payload type number assignment, this
+      payload format can be identified by the MIME type "audio/t140c"
+      (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 3555 [17].
+
+   Sequence number: The definition of sequence numbers is available in
+      RFC 3550 [2].  Character loss is detected through the T140block
+      counter when using the audio/t140c payload format.
+
+   Timestamp: The RTP Timestamp encodes the approximate instance of
+      entry of the primary text in the packet.  For audio/t140c, the
+      clock frequency MAY be set to any value, and SHOULD be set to the
+      same value as for any audio packets in the same RTP stream in
+      order to avoid RTP timestamp rate switching.  The value SHOULD be
+      set by out of band mechanisms.  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
+      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
+
+
+
+Hellstrom & Jones               Historic                        [Page 6]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+      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 caused by
+   packet loss within acceptable limits. (See ITU-T F.703 [16].)
+
+   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.
+
+   Other protection methods MAY 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 [16] to
+   be met in all anticipated load conditions.
+
+4.1.  Payload Format When Using Redundancy
+
+   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
+   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 plus a payload type number indicating the
+   payload format audio/t140c.
+
+   After the redundant data block headers follows the redundant data
+   fields carrying T140blocks from previous packets, and finally the new
+   (primary) T140block for this packet.
+
+   Redundant data that would need a timestamp offset higher than 16383
+   due to its age at transmission MUST NOT be included in transmitted
+   packets.
+
+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                        [Page 7]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+4.2.  Using Redundancy with the audio/t140c Format
+
+   Since sequence numbers are not provided in the redundant header and
+   since the sequence number space is shared by all audio payload types
+   within an RTP session, a sequence number in the form of a T140block
+   counter is added to the T140block for transmission.  This allows the
+   redundant T140block data corresponding to missing primary data to be
+   retrieved and used properly into the stream of received T140block
+   data when using the audio/t140c payload format.
+
+   All non-empty redundant data blocks MUST contain the same data as a
+   T140block previously transmitted as primary data, and be identified
+   with a T140block counter equating to the original T140block counter
+   for that T140block.
+
+   The T140block counters preceding the text in the T140block enables
+   the ordering by the receiver.  If there is a gap in the T140block
+   counter value of received audio/t140c packets, and if there are
+   redundant T140blocks with T140block counters matching those that are
+   missing, the redundant T140blocks may be substituted for the missing
+   T140blocks.
+
+   The value of the length field in the redundant header indicates the
+   length of the concatenated T140block counter and the T140block.
+
+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.
+
+
+
+
+
+Hellstrom & Jones               Historic                        [Page 8]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   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 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 to
+   be the beginning of an idle period.  The procedure is recommended in
+   order to more rapidly detect potentially missing text before an idle
+   period or when the audio stream switches from the transmission of
+   audio/t140c to some other form of audio.
+
+   An empty T140block contains no data, neither T.140 data nor a
+   T140block counter.
+
+   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, and the
+   empty primary T140block.
+
+   When using the audio/t140c payload format, empty T140blocks sent as
+   primary data SHOULD NOT be included as redundant T140blocks, as it
+   would simply be a waste of bandwidth to send them and it would
+   introduce a risk of false detection of loss.
+
+   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
+
+   Receivers detect the loss of an audio/t140c packet by observing the
+   value of the T140block counter in a subsequent audio/t140c packet.
+
+   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].
+
+   Procedures based on detection of the packet with the M-bit set to one
+   MAY be used to reduce the risk for introducing false markers of loss.
+
+
+
+Hellstrom & Jones               Historic                        [Page 9]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   False detection will also be avoided when using audio/t140c by
+   observing the value of the T140block counter value.
+
+   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.
+
+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 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 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 Session Description Protocol (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.
+
+   In receipt of this parameter, devices MUST adhere to the request by
+   transmitting characters at a rate at or below the specified <integer>
+   value.  Examples of use in SDP are found in section 7.2.
+
+
+
+Hellstrom & Jones               Historic                       [Page 10]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+7.  Examples
+
+7.1.  RTP Packetization Examples for the audio/t140c Format
+
+   Below is an example of an audio/t140c 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|   T140c PT  |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      timestamp (8000Hz)                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     T140block counter         | T.140 encoded data            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +---------------+
+   |                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Below is an example of an RTP packet with one redundant T140block
+   using audio/t140c 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.  Note that since this is the audio/t140c payload format,
+   the redundant block of T.140 data is immediately preceded with a
+   T140block counter.
+
+    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|   T140c PT  |  timestamp offset of "R"  | "R" block length  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   T140c PT  |  "R" T140block counter        |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
+   |               "R" T.140 encoded redundant data                |
+   +                                               +---------------+
+   |                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 11]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   As a follow-on to the previous example, the example below shows the
+   next RTP packet in the sequence that does contain a new real
+   T140block when using the audio/t140c payload format.  This example
+   has 2 levels of redundancy and one primary data block.  Since the
+   previous primary block was empty, no redundant data is included for
+   that block.  This is because when using the audio/t140c payload
+   format, any previously transmitted "empty" T140blocks are NOT
+   included as redundant data in subsequent packets.
+
+    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|   T140c PT  |  timestamp offset of "R1" | "R1" block length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   T140c PT  |  "R1" T140block counter       |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
+   |               "R1" T.140 encoded redundant data               |
+   +                                               +---------------+
+   |                                               | "P" T140block |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | counter       |     "P" T.140 encoded primary data            |
+   +-+-+-+-+-+-+-+-+                                               +
+   |                                                               |
+   +                                               +---------------+
+   |                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+7.2.  SDP Examples
+
+   Below is an example of SDP describing RTP text interleaved with G.711
+   audio packets within the same RTP session from port 7200 and at a
+   maximum text rate of 6 characters per second:
+
+      m=audio 7200 RTP/AVP 0 98
+      a=rtpmap:98 t140c/8000
+      a=fmtp:98 cps=6
+
+   Below is an example using RFC 2198 to provide the recommended two
+   levels of redundancy to the text packets in an RTP session with
+   interleaving text and G.711 at a text rate no faster than 20
+   characters per second:
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 12]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+      m=audio 7200 RTP/AVP 0 98 100
+      a=rtpmap:98 t140c/8000
+      a=fmtp:98 cps=20
+      a=rtpmap:100 red/8000
+      a=fmtp:100 98/98/98
+
+   Note: While these examples utilize the RTP/AVP profile, it is not
+   intended to limit the scope of this memo to use with only that
+   profile.  Rather, any appropriate profile may be used in conjunction
+   with this memo.
+
+8.  Security Considerations
+
+   All of the security considerations from section 14 of RFC 3550 [2]
+   apply.
+
+8.1.  Confidentiality
+
+   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.
+   Secure Realtime Transport Protocol (SRTP) [13] 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 [13] provides methods for providing
+   integrity that MAY be applied.
+
+8.3.  Source Authentication
+
+   Measures to make sure that the source of text is the intended one can
+   be accomplished by a combination of methods.
+
+   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 [13] mechanisms MAY be applied to ascertain that
+   the source is maintained the same during the session.
+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 13]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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 part about
+   congestion in section 2 of RFC 3551 [10]) apply with the following
+   application-specific considerations.
+
+   Automated systems MUST NOT use this format to send large amounts of
+   text at a rate significantly above that which 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
+   achieve over the same path.  The reason 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 [12], 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 that is the
+     highest value allowable 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.
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 14]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   - Experience tells that a common mean character transmission rate
+     during a complete PSTN text telephony session in reality is around
+     2 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 make use of three-octet UTF-8 characters, two
+     redundant levels, and 300 ms between transmissions, the maximum
+     load of this application is 3500 bits/s.
+
+   - 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 also, 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 defines one RTP payload format named "t140" and an
+   associated MIME type "audio/t140c".  They have been registered by the
+   IANA.
+
+10.1.  Registration of MIME Media Type audio/t140c
+
+   MIME media type name: audio
+
+   MIME subtype name: t140c
+
+   Required parameters:
+     rate: The RTP timestamp clock rate, which is equal to the
+     sampling rate.  This parameter SHOULD have the same value as
+     for any audio codec packets interleaved in the same RTP
+     stream.
+
+   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 4351.
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 15]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   Security considerations: See section 8 of RFC 4351.
+
+   Interoperability considerations: None
+
+   Published specification: ITU-T T.140 Recommendation.
+                            RFC 4351.
+
+   Applications which use this media type:
+     Text communication systems and text conferencing tools that
+     transmit text associated with audio and within the same RTP
+     session as the audio, such as PSTN gateways that transmit
+     audio and text signals between two PSTN textphone users
+     over an IP network.
+
+   Additional information:  This type is only defined for transfer
+     via RTP.
+
+     Magic number(s): None
+     File extension(s): None
+     Macintosh File Type Code(s): None
+
+   Person & email address to contact for further information:
+     Paul E. Jones
+     E-mail: paulej@packetizer.com
+
+   Intended usage: COMMON
+
+   Author                        / Change controller:
+     Paul E. Jones               | IETF avt WG delegated from the IESG
+     paulej@packetizer.com       |
+
+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 audio/t140c format, the
+   mapping is as follows:
+
+      - The MIME type ("audio") goes in SDP "m=" as the media name.
+
+      - The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
+        the encoding name.  For audio/t140c, the clock rate MAY be set
+        to any value, and SHOULD be set to the same value as for any
+        audio packets in the same RTP stream.
+
+      - The parameter "cps" goes in SDP "a=fmtp" attribute.
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 16]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+      - 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 2198 [3].
+
+10.3.  Offer/Answer Consideration
+
+   In order to achieve interoperability within the framework of the
+   offer/answer model [9], the following consideration should be made:
+
+      - The "cps" parameter is declarative.  Both sides may provide a
+        value, which is independent of the other side.
+
+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; 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.
+
+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", STD 64,
+        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.
+
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 17]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+   [8]  Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
+        Generic Forward Error Correction", RFC 2733, December 1999.
+
+   [9]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+        Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+        Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
+
+   [11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+13.  Informative References
+
+   [12] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
+        Control for Voice Traffic in the Internet", RFC 3714, March
+        2004.
+
+   [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+        Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+        3711, March 2004.
+
+   [14] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
+        Telephony Tones and Telephony Signals", RFC 2833, May 2000.
+
+   [15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
+        RFC 4103, June 2005.
+
+   [16] ITU-T Recommendation F.703, Multimedia Conversational Services,
+        Nov 2000.
+
+   [17] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
+        Payload Formats", RFC 3555, July 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 18]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+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               Historic                       [Page 19]
+
+RFC 4351        RTP Payload for Text in an Audio Stream     January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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 provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Hellstrom & Jones               Historic                       [Page 20]
+