Network Working Group G. Hellstrom
Request for Comments: 2793 Omnitor AB
Category: Standards Track May 2000
Network Working Group G. Hellstrom
Request for Comments: 2793 Omnitor AB
Category: Standards Track May 2000
RTP Payload for Text Conversation
文本会话的RTP有效负载
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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].
本备忘录描述了如何在RTP数据包中传输文本会话内容。ITU-T建议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.
该RTP有效负载描述包含可选的可能性，包括来自已经传输的分组的冗余文本，以减少由分组丢失引起的文本丢失的风险。冗余编码遵循RFC 2198。
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.
此备忘录定义了用于在RTP数据包中承载文本会话内容的有效负载类型。ITU-T建议T.140[1]中规定了文本对话会话内容。文本对话单独使用或与其他对话设施（如视频和语音）结合使用，以形成多媒体对话服务。文本会话会话中的文本在可用时立即发送，或以较小的缓冲延迟发送。
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规定文本和其他T.140元素必须通过UTF-8转换以ISO 10 646-1代码传输。这使得实现国际上有用的应用程序以及在现代信息技术环境中处理文本变得容易。遵循本规范的RTP数据包的有效载荷由根据T.140编码的文本组成，没有任何额外的帧。常见的情况是单个ISO10646字符，UTF-8编码。
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.
T.140要求传输通道以原始顺序提供不重复的字符。文本对话用户希望文本在传递时不会丢失或丢失少量信息。如果可以指出丢失的信息，接受损失的意愿预计会更高。
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.
因此，这里指定了一种基于RTP的机制。它以正确的顺序提供文本到达，没有重复，并检测和指示丢失。它还包括重复数据以实现冗余的可选可能性，以降低丢失风险。由于数据包开销通常远大于T.140内容，因此冗余方案对信道负载的增加最小。
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]
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释
When transport of T.140 text session data in RTP is desired, the payload as described in this specification SHOULD be used.
当需要在RTP中传输T.140文本会话数据时，应使用本规范中所述的有效载荷。
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
此有效负载格式指定的文本会话RTP数据包由RFC 1889[2]中定义的RTP报头组成，紧接着是一个T.140数据块，此处定义为“T140block”。没有特定于此有效负载格式的附加标头。T140块包含[1]中规定的一个或多个T.140代码元素。大多数T.140代码元素是单个ISO10646[5]字符，但有些是多字符序列。每个字符都经过UTF-8编码[6]为一个或多个八位字节。这意味着每个块必须包含整数个UTF-8编码
characters regardless of the number of octets per character. It also implies that any composite character sequence (CCS) SHOULD be placed within one block.
不考虑每个字符的八位字节数。它还意味着任何复合字符序列（CCS）都应该放在一个块中。
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.
T140块可以根据RFC 2198[3]中定义的有效载荷格式进行冗余传输。在这种情况下，RTP报头后面紧跟着一个或多个冗余数据块报头，相同数量的冗余数据字段承载来自先前数据包的T140块，最后是该数据包的新（主）T140块。
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for T.140 text streams:
每个RTP数据包都以一个固定的RTP报头开始。RTP固定标题的以下字段用于T.140文本流：
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").
有效负载类型（PT）：RTP有效负载类型的分配特定于使用此有效负载格式的RTP配置文件。对于使用动态有效负载类型编号分配的配置文件，该有效负载格式由名称“T140”标识（参见第6节）。如果按照RFC 2198使用冗余，有效负载类型必须指示有效负载格式（“红色”）。
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.
时间戳：RTP时间戳对数据包中主文本输入的近似实例进行编码。必须使用1000 Hz的时钟频率。连续数据包不得使用相同的时间戳。由于数据包不代表任何恒定的持续时间，时间戳不能用于直接推断数据包丢失。
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").
当需要根据RFC 2198冗余传输数据时，RTP报头后面跟着一个或多个冗余数据块报头，每个冗余数据块对应一个。这些报头中的每一个都提供了相应数据块的时间戳偏移量和长度，以及指示此有效负载格式的有效负载类型号（“T140”）。
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.
T.140文本按照T.140中的规定进行UTF-8编码，无额外框架。当使用具有冗余数据的格式时，发送器可以选择在每个分组中重新传输的T140块生成数。数字越大，可以更好地防止文本丢失，但会提高数据速率。
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:
由于分组不是以固定的间隔生成的，除非提供额外的信息，否则时间戳不足以在存在丢失的情况下识别分组。由于冗余报头中未提供序列号，因此必须遵循一些附加规则，以允许与丢失的主数据相对应的冗余数据正确合并到主数据流T140块中：
- 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.
- 每个冗余数据块必须包含与先前作为主数据传输的T140块相同的数据，并用与该T140块的原始时间戳相等的时间戳偏移来标识。-冗余数据必须按时间顺序放置，最新的冗余T140块最后一个在冗余区域。-必须包括从最旧的所需生成到新（主）T140块之前的生成的所有T140块。
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.
这些规则允许通过从RTP报头中的序列号向后计数来推断冗余T140块的序列号。结果将是有效负载中的所有文本都是连续的，并且是有序的。
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.
- 按顺序重新排列收到的文本。-标记由于数据包丢失而丢失文本的位置。-通过使用冗余数据补偿丢失的数据包。
Packets are transmitted only when there is valid T.140 data to transmit. The sequence number is used for sequencing of T.140 data.
只有当有有效的T.140数据要传输时，才会传输数据包。序列号用于对T.140数据进行排序。
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.
在接收时，将RTP序列号与最后正确接收的数据包的序列号进行比较。如果它们是连续的，则从数据包中检索（唯一或主要）T140块。
3.2 Recommended procedure for compensation for lost packets.
3.2 建议的丢失数据包补偿程序。
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.
为了在分组丢失的情况下减少数据丢失，可以按照RFC 2198中的过程在分组中包括冗余数据。如果网络条件未知，建议在每个数据包中使用一个冗余T140块。如果RTP序列号中存在间隙，并且冗余T140块在后续数据包中可用，则应通过从该数据包的RTP报头中的序列号向后计数来推断冗余T140块的序列号。如果存在序列号与缺失序列号匹配的冗余T140块，则可以用冗余T140块替换缺失的T140块。
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].
对于使用冗余和未使用冗余的情况，应按照ITU-T T.140中的规定，通过在接收流中为每个缺失T140块插入缺失文本标记来标记缺失数据。增编1[1]。
3.3 Recommended procedure for compensation for packets out of order.
3.3 建议的程序，用于对无序数据包进行补偿。
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.
为了防止分组无序到达，可以在接收机中实现以下过程。如果对接收到的数据包的分析显示序列中存在间隙，并且没有可用的冗余数据来填补该间隙，则可以将接收到的数据包保存在缓冲器中，以允许丢失的数据包到达。建议将等待时间限制为0.5秒。对于使用冗余的情况，如果已知该产品大于0.5秒，则等待时间应延长至冗余生成数乘以T.140缓冲计时器。
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.
如果具有属于该间隙的t140块的分组在等待时间到期之前到达，则将该t140块插入该间隙中，然后可以消耗该间隙前缘的连续t140块。任何在时限到期前未到达的T140块应视为丢失。
3.4 Transmission during "silent periods" when redundancy is used.
3.4 使用冗余时的“静默期”传输。
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.
当使用冗余传输方案时，并且没有更多的东西可以从T.140传输，最新的T140块在作为冗余数据传输之前有变老的风险。结果是，在文本输入序列结束时，针对数据包丢失的保护不太有用。对于应该避免这种情况的情况，可以使用冗余数据传输零长度主T140块。
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.
如第2.3节所述，作为主数据发送的任何零长度T140块必须作为冗余T140块包含在后续数据包中，就像正常文本T140块一样，以便冗余T140块的序列号推断是正确的。
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.
最后一个T140块的冗余不应通过重复传输相同的数据包（具有相同的序列号）来实现，因为这将导致RTCP中报告的数据包丢失计数减少。
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 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 |
+ +
+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
图：RTP文本包的示例。
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.
由于所述有效载荷格式的目的是在文本对话中携带文本，因此以加密形式的安全措施非常重要。文本会话会话中的数据量较低，因此可以选择任何加密方法并将其应用于T.140会话内容或整个RTP分组。当包含冗余数据时，与RFC 2198相同的安全注意事项适用。
This document defines a new RTP payload name and associated MIME type, T140 (text/t140).
本文档定义了一个新的RTP负载名称和相关的MIME类型T140（text/T140）。
MIME media type name: text
MIME媒体类型名称：text
MIME subtype name: t140
MIME子类型名称：t140
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: T140 text can be transmitted with RTP as specified in RFC 2793.
编码注意事项：按照RFC 2793的规定，T140文本可以通过RTP传输。
Security considerations: None
安全考虑：无
Interoperability considerations: None
互操作性注意事项：无
Published specification: ITU-T T.140 Recommendation. RFC 2793.
已发布规范：ITU-T.140建议。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
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
联系人和电子邮件地址以获取更多信息：Gunnar Hellstrom电子邮件：Gunnar。hellstrom@omnitor.se
Intended usage: COMMON
Author / Change controller:
Gunnar Hellstrom | IETF avt WG
gunnar.hellstrom@omnitor.se | c/o Steve Casner casner@cisco.com
Intended usage: COMMON
Author / Change controller:
Gunnar Hellstrom | IETF avt WG
gunnar.hellstrom@omnitor.se | c/o Steve Casner casner@cisco.com
Gunnar Hellstrom Omnitor AB Alsnogatan 7, 4 tr SE-116 41 Stockholm Sweden
Gunnar Hellstrom Omnitor AB Alsnogatan 7，4 tr SE-116 41瑞典斯德哥尔摩
Phone: +46 708 204 288 / +46 8 556 002 03
Fax: +46 8 556 002 06
EMail: gunnar.hellstrom@omnitor.se
Phone: +46 708 204 288 / +46 8 556 002 03
Fax: +46 8 556 002 06
EMail: gunnar.hellstrom@omnitor.se
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.
作者要感谢Stephen Casner和Colin Perkins对本文档创建的宝贵支持，感谢爱立信移动通信公司的Mickey Nasiri提供开发环境，感谢Michele Mizarro验证有效载荷格式的可用性。
[1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1, (2000).
[1] ITU-T建议T.140（1998）-多媒体应用的文本对话协议，修订件1，（2000年）。
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[3] Perkins, C., Kouvelas, I., Hardman, V., Handley, M. and J. Bolot, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[3] Perkins，C.，Kouvelas，I.，Hardman，V.，Handley，M.和J.Bolot，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character Set.
[5] ISO/IEC 10646-1:（1993），通用多八位编码字符集。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[6] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。