Network Working Group G. Hellstrom
Request for Comments: 2793 Omnitor AB
Category: Standards Track May 2000
RTP Payload for Text Conversation
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（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.
テキストは、キーボード、手書き認識、音声認識やその他の入力方法から人間のユーザが入力したことになっています。文字入力のレートは、数秒ごとに文字以下のレベルで通常です。そのため、送信する文字の予想数が低いです。 1つのまたはいくつかの新しい文字は、各パケットを送信することが期待されます。
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に従って符号化されたテキストから成ります。一般的なケースは、単一のISO 10646文字、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]
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものと"、 "推奨"、 "MAY"、 "OPTIONAL" はあります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 characters regardless of the number of octets per character. It also implies that any composite character sequence (CCS) SHOULD be placed within one block.
「T140block」とここで定義T.140データのブロック、直後[2] RFC 1889で定義されるように、このペイロード形式で指定されたテキストの会話RTPパケットは、RTPヘッダで構成されています。このペイロード形式に固有の追加のヘッダが存在しません。 T140block [1]で指定されたような1つ以上のT.140コード要素を含みます。ほとんどのT.140コード要素は、ISO 10646 [5]文字シングルですが、いくつかは、複数の文字列です。各文字は、一個の以上のオクテットにUTF-8でエンコードされた[6]です。これは、各ブロックは関係なく、文字あたりオクテット数のUTF-8エンコードされた文字に不可欠な数を含まなければならないことを意味します。また、任意の複合文字シーケンス（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.
T140blocks [3] RFC 2198で定義されたペイロードフォーマットに従って冗長送信されてもよいです。その場合には、RTPヘッダは、このパケットのための1つ以上の冗長データブロックヘッダ、前のパケットからT140blocksを搬送する冗長データフィールドの同じ数、および最終的に新しい（一次）T140blockが続きます。
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ごとに使用される場合、ペイロード・タイプは、ペイロード・フォーマット（「RED」）を示さなければなりません。
Sequence number: The Sequence Number MUST be increased by one for each new transmitted packet. It is used for detection of packet loss and packets out of order, and can be used in the process of retrieval of redundant text, reordering of text and marking missing text.
シーケンス番号：シーケンス番号はそれぞれの新しい送信パケットに対して1つずつ増加しなければなりません。これは、パケットロス及び順序のうちのパケットの検出に使用され、冗長テキスト、テキストの並べ替えの検索の過程で使用され、不足しているテキストをマークすることができます。
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タイムスタンプは、パケット内のプライマリテキストのエントリのおおよそのインスタンスをエンコードします。 1000Hzでのクロック周波数を使用しなければなりません。シーケンシャルパケットは同じタイムスタンプを使用してはなりません。パケットは、任意の一定の持続時間を表すものではありませんので、タイムスタンプは、直接パケットロスを推測するために使用することはできません。
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ヘッダは、一つ以上の冗長データブロックヘッダ含まれるべき各冗長データブロックのための1つが続きます。これらのヘッダの各々は、このペイロード・フォーマット（「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テキストはUTF-8余分なフレーミングとT.140に指定されているコード化されています。冗長データとフォーマットを使用する場合、送信機は、各パケットに再送信するT140block世代の数を選択することができます。数値が大きいほど、テキストの損失に対するより良い保護を紹介しますが、データ速度を増加させます。
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:
パケットは一定の間隔で発生しないので、タイムスタンプは、追加情報が提供されない限り損失の存在下でパケットを識別するのに十分ではありません。シーケンス番号は、冗長ヘッダに設けられていないので、いくつかの追加の規則は次データT140blocksのストリームに適切にマージされるプライマリ・データを欠落に対応する冗長データを可能にするために従わなければなりません。
- Each redundant data block MUST contain the same data as a T140block previously transmitted as primary data, and be identified with a timestamp offset equating to the original timestamp for that T140block. - The redundant data MUST be placed in age order with most recent redundant T140block last in the redundancy area. - All T140blocks from the oldest desired generation up through the generation immediately preceding the new (primary) T140block MUST be included.
- 各冗長データブロックは、以前に一次データとして伝送T140blockと同じデータを含まなければなりません、及びタイムスタンプがそのT140blockの元のタイムスタンプに等しくするオフセットで識別されます。 - 冗長データは冗長領域内の最後の最も最近の冗長T140blockと年齢順に置かなければなりません。 - アップ直ちに新しい（一次）T140blockの前世代を経て、最も古い所望の生成から全てT140blocksを含まなければなりません。
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.
これらのルールは、冗長T140blocksのシーケンス番号は、RTPヘッダ内のシーケンス番号から後方に数えることによって推測することを可能にします。結果は、ペイロード内のすべてのテキストが連続して順番になることになります。
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シーケンス番号が最後に正しく受信されたパケットのシーケンス番号と比較されます。それらが連続している場合、（のみまたは主）T140blockは、パケットから取得されます。
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.に記載されている手順に以下のパケットに含まれてもよく、各パケットに一つの冗長T140blockを使用することが推奨されます。 RTPシーケンス番号、冗長T140blocksにギャップがある場合、後続のパケットで提供され、冗長T140blocksのシーケンス番号は、そのパケットのRTPヘッダのシーケンス番号から後方に数えることによって推測されるべきです。欠落しているものと一致するシーケンス番号、冗長T140blocksがある場合は、冗長T140blocksが欠落T140blocks置換されていてもよいです。
Both for the case when redundancy is used and not used, missing data SHOULD be marked by insertion of a missing text marker in the received stream for each missing T140block, as specified in ITU-T T.140. Addendum 1 [1].
ITU-T T.140で指定されるように冗長性を使用し使用しない場合の両方は、失われたデータは、各欠落T140blockための受信されたストリームにおける欠落テキストマーカーの挿入によってマークされるべきです。補遺1 [1]。
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.
待機時間が満了する前にギャップに属するT140block持つパケットが到着した場合、このT140blockは隙間に挿入され、その後、ギャップの先端から連続T140blocksが消費されてもよいです。失われたとして、制限時間が切れる前に到着していない任意のT140blockが扱われるべきです。
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から送信するより多くの何もない場合は、最新のT140blockは、それが冗長データとして送信される前に、古い得ることの危険性を持っています。結果は、テキスト入力シーケンスの最後でパケット損失に対してあまり有効な保護です。これは避けなければならない場合のために、長さゼロの一次T140blockは、冗長データを送信することができます。
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.
一次データとして送信される任意の長さゼロのT140blocksは、通常のテキストT140blocksは、セクション2.3で説明したように、冗長T140blocksためにそのシーケンス番号推論は、正しいであろうことと同じように、後続のパケットに冗長T140blocksを含まなければなりません。
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.
最後T140blockのための冗長性が、これはパケットロス数の原因となりますのでデクリメントし、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 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（テキスト/ T140）。
MIME media type name: text
MIMEメディアタイプ名：テキスト
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勧告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
マジックナンバー（S）：なしファイルの拡張子（秒）：なしMacintoshのファイルタイプコード（S）：なし
Person & email address to contact for further information: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se
人とEメールアドレス詳細のために連絡する：グンナー・ヘルストローム電子メール：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
意図している用法：COMMON著者/変更コントローラ：グンナー・ヘルストローム| IETF AVT WG gunnar.hellstrom@omnitor.se | C / OスティーブCasner casner@cisco.com
Gunnar Hellstrom Omnitor AB Alsnogatan 7, 4 tr SE-116 41 Stockholm Sweden
グンナー・ヘルストロームOmnitorAlsnögatan7,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
電話：+46 708 204 288/46 8 556 002 03ファックス：+46 8 556 002 06 Eメール：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.
著者は、そのためのペイロードフォーマットのユーザビリティを検証するための開発環境を提供するためのエリクソン・モバイルコミュニケーションのミッキーナシリに、レビューし、この文書の作成上のアドバイスと貴重な支援のためのスティーブンCasnerとコリンパーキンスに感謝したい、とミケーレ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.、フレデリック、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]パーキンス、C.、Kouvelas、I.、ハードマン、V.、ハンドレー、M.及びJ. Bolot、 "冗長オーディオデータのRTPペイロード"、RFC 2198、1997年9月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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] Yergeau、F.、 "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 Editor機能のための基金は現在、インターネット協会によって提供されます。