Internet Engineering Task Force (IETF) X. Duan
Request for Comments: 5993 S. Wang
Category: Standards Track China Mobile Communications Corporation
ISSN: 2070-1721 M. Westerlund
K. Hellwig
I. Johansson
Ericsson AB
October 2010
RTP Payload Format for
Global System for Mobile Communications Half Rate (GSM-HR)
Abstract
抽象
This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.
この文書では、リアルタイムトランスポートプロトコル（RTP）にモバイルコミュニケーションズハーフレート（GSM-HR）音声コーデックのデータのためのグローバルシステムのパケットのペイロード形式を指定します。ペイロード・フォーマットは、冗長性を使用してペイロードパケット損失ロバストネス方法ごとに複数のフレームの送信をサポートします。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5993.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5993で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4
5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8
5.2.2. Encoding of Silence Description Frames . . . . . . . . 8
5.3. Implementation Considerations . . . . . . . . . . . . . . 8
5.3.1. Transmission of SID Frames . . . . . . . . . . . . . . 8
5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8
5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. 3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 12
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 14
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document specifies the payload format for packetization of GSM Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Real-time Transport Protocol (RTP) [RFC3550]. The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.
この文書では、リアルタイムトランスポートプロトコル（RTP）[RFC3550]にGSMハーフレート（GSM-HR）コーデック[TS46.002]符号化された音声信号のパケットのためのペイロードのフォーマットを指定します。ペイロード・フォーマットは、冗長性を使用してペイロードパケット損失ロバストネス方法ごとに複数のフレームの送信をサポートします。
This document starts with conventions, a brief description of the codec, and payload format capabilities. The payload format is specified in Section 5. Examples can be found in Section 6. The media type specification and its mappings to SDP, and considerations when using the Session Description Protocol (SDP) offer/answer procedures are then specified. The document ends with considerations related to congestion control and security.
この文書は、規則にコーデックの簡単な説明を開始し、ペイロードフォーマット機能を提供します。ペイロード・フォーマットは、セッション記述プロトコル（SDP）を使用する場合5としては、オファー/アンサー・プロシージャが指定されているセクション6内のメディアタイプの仕様とそのマッピングSDP、および考慮事項を見つけることができるセクションに指定されています。文書には、輻輳制御とセキュリティに関連する考慮事項で終わります。
This document registers a media type (audio/GSM-HR-08) for the Real-time Transport Protocol (RTP) payload format for the GSM-HR codec. Note: This format is not compatible with the one provided back in 1999 to 2000 in early draft versions of what was later published as RFC 3551. RFC 3551 was based on a later version of the Audio-Visual Profile (AVP) draft, which did not provide any specification of the GSM-HR payload format. To avoid a possible conflict with this older format, the media type of the payload format specified in this document has a media type name that is different from (audio/GSM-HR).
この文書では、GSM-HRコーデックのためのリアルタイムトランスポートプロトコル（RTP）ペイロード形式のメディアタイプ（オーディオ/ GSM-HR-08）を登録します。注：この形式は後でRFC 3551. RFC 3551として発行されたものの初期のドラフトバージョンに2000に1999年に戻って1と互換性がありませんでした、オーディオビジュアルプロファイル（AVP）ドラフトの後のバージョンに基づいていましたGSM-HRペイロードフォーマットの任意の仕様を提供しません。この古い形式で可能な衝突を回避するために、この文書で指定されたペイロード形式のメディアタイプ（オーディオ/ GSM-HR）は異なるメディアタイプ名を有しています。
This document uses the normal IETF bit-order representation. Bit fields in figures are read left to right and then down. The leftmost bit in each field is the most significant. The numbering starts from 0 and ascends, where bit 0 will be the most significant.
この文書は、通常のIETFビット順序表現を使用しています。図中のビットフィールドを右にして、上下左読み込まれます。各フィールドの左端のビットは最も重要です。番号は0から始まり、ビット0が最上位になるところ、上昇します。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The Global System for Mobile Communications (GSM) network provides with mobile communication services for nearly 3 billion users (statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of the speech codecs used in GSM networks. GSM-HR denotes the Half Rate speech codec as specified in [TS46.002].
移動体通信用グローバルシステム（GSM）ネットワークは、ほぼ30億人のユーザー（2008年統計）のための移動通信サービスを提供します。 GSMハーフレート（GSM-HR）コーデックは、GSMネットワークで使用される音声コーデックのひとつです。 [TS46.002]に指定されているGSM-HRは、ハーフレートの音声コーデックを示しています。
Note: For historical reasons, these 46-series specifications are internally referenced as 06-series. A simple mapping applies; for example, 46.020 is referenced as 06.20, and so on.
注意：歴史的な理由により、これらの46シリーズの仕様は、内部的に06シリーズとして参照されています。単純なマッピングが適用されます。例えば、46.020は、そうで06.20として参照され、。
The GSM-HR codec has a frame length of 20 ms, with narrowband speech sampled at 8000 Hz, i.e., 160 samples per frame. Each speech frame is compressed into 112 bits of speech parameters, which is equivalent to a bit rate of 5.6 kbit/s. Speech pauses are detected by a standardized Voice Activity Detection (VAD). During speech pauses, the transmission of speech frames is inhibited. Silence Descriptor (SID) frames are transmitted at the end of a talkspurt and about every 480 ms during speech pauses to allow for a decent comfort noise (CN) quality on the receiver side.
GSM-HRコーデックは、8000 Hzでサンプリングされた狭帯域音声、すなわち、フレーム当たり160個のサンプルで、20ミリ秒のフレーム長を有しています。各音声フレームは5.6キロビット/秒のビットレートに相当する音声パラメータ、の112ビットに圧縮されます。音声休止は、標準化された音声アクティビティ検出（VAD）によって検出されます。音声ポーズの間に、音声フレームの送信が禁止されます。無音記述子（SID）フレームが受信側でまともなコンフォートノイズ（CN）の品質を可能にするために、休止通話中有音部の末尾とほぼすべて480ミリ秒で送信されます。
The SID frame generation in the GSM radio network is determined by the GSM mobile station and the GSM radio subsystem. SID frames come during speech pauses in the uplink from the mobile station about every 480 ms. In the downlink to the mobile station, when they are generated by the encoder of the GSM radio subsystem, SID frames are sent every 20 ms to the GSM base station, which then picks only one every 480 ms for downlink radio transmission. For other applications, like transport over IP, it is more appropriate to send the SID frames less often than every 20 ms, but 480 ms may be too sparse. We recommend as a compromise that a GSM-HR encoder outside of the GSM radio network (i.e., not in the GSM mobile station and not in the GSM radio subsystem, but, for example, in the media gateway of the core network) should generate and send SID frames every 160 ms.
GSM無線ネットワークにおけるSIDフレーム生成は、GSM移動局とGSM無線サブシステムによって決定されます。 SIDフレームはすべて480ミリ約移動局から上りリンクにおいて音声休止の間に来ます。それらはGSM無線サブシステムのエンコーダによって生成された移動局へのダウンリンクにおいて、SIDフレームは、次に、ダウンリンク無線伝送のための唯一のすべての480ミリ秒を選ぶGSM基地局に20msごとに送信されます。他のアプリケーションでは、IP上でのデータ転送のように、SIDは20ミリ秒毎よりも頻繁にフレームを送信することがより適切であるが、480ミリ秒はあまりにもまばらなことがあります。我々は、GSM無線ネットワークの外部GSM-HRエンコーダ（すなわち、しない、GSM移動局ではなく、GSM無線サブシステムではなく、例えば、コアネットワークのメディアゲートウェイに）生成することを妥協案としてお勧めそしてSIDごとに160ミリ秒のフレームを送信します。
This RTP payload format carries one or more GSM-HR encoded frames -- either full voice or silence descriptor (SID) -- representing a mono speech signal. To maintain synchronization or to indicate unsent or lost frames, it has the capability to indicate No_Data frames.
完全な音声または無音記述子（SID）のいずれか - - モノラル音声信号を表す、このRTPペイロードフォーマットは、一つ以上のGSM-HR符号化フレームを運びます。同期を維持するためか、未送信または失われたフレームを示すために、それがNO_DATAフレームを示すために能力を持っています。
Generic forward error correction within RTP is defined, for example, in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC 2198 [RFC2198]. Either scheme can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bit rate. Please see either RFC for a discussion of the implications of the higher bit rate to network congestion.
RTP内の一般的な順方向誤り訂正は、RFC 5109 [RFC5109]は、例えば、定義されています。オーディオ冗長符号化は、RFC 2198 [RFC2198]で定義されています。どちらの方式では、より高いビットレートを犠牲にして、RTPパケットストリームに冗長な情報を追加して、パケットロスに対してより弾力性にするために使用することができます。ネットワークの輻輳に高いビットレートの意味についての説明は、いずれかのRFCを参照してください。
In addition to these media-unaware mechanisms, this memo specifies an optional-to-use GSM-HR-specific form of audio redundancy coding, which may be beneficial in terms of packetization overhead. Conceptually, previously transmitted transport frames are aggregated together with new ones. A sliding window can be used to group the frames to be sent in each payload. Figure 1 below shows an example.
これらのメディア非認識機構に加えて、このメモは、パケットのオーバーヘッドの点で有益であり得るオーディオ冗長符号化のオプションに使用GSM-HR固有の形式を指定します。概念的には、以前に送信された伝送フレームは、新しいものと一緒に集約されます。スライディングウィンドウは、グループに各ペイロードに送信するフレームを使用することができます。図1は、下記の例を示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An Example of Redundant Transmission
図1：冗長送信例
Here, each frame is retransmitted once in the following RTP payload packet. f(n-2)...f(n+4) denote a sequence of audio frames, and p(n-1)...p(n+4) a sequence of payload packets.
ここで、各フレームは、以下のRTPペイロードパケットに一回再送信されます。 fは（N-2）、···、F（N + 4）オーディオフレームのシーケンスを示し、P（N-1）... P（N + 4）ペイロード・パケットのシーケンス。
The mechanism described does not really require signaling at the session setup. However, signaling has been defined to allow the sender to voluntarily bound the buffering and delay requirements. If nothing is signaled, the use of this mechanism is allowed and unbounded. For a certain timestamp, the receiver may acquire multiple copies of a frame containing encoded audio data. The cost of this scheme is bandwidth, and the receiver delay is necessary to allow the redundant copy to arrive.
説明のメカニズムは、実際にセッションセットアップでシグナリングを必要としません。しかし、シグナリングは、送信者が自主的にバッファリングと遅延要件を拘束することを可能にするために定義されています。何も知らされていない場合は、このメカニズムの使用が許可され、無制限れます。特定のタイムスタンプのために、受信機は、符号化オーディオデータを含むフレームの複数のコピーを取得してもよいです。このスキームのコストは帯域幅であり、受信遅延は、冗長コピーが到達できるようにする必要があります。
This redundancy scheme provides a functionality similar to the one described in RFC 2198, but it works only if both original frames and redundant representations are GSM-HR frames. When the use of other media coding schemes is desirable, one has to resort to RFC 2198.
この冗長方式は、RFC 2198に記載したものと同様の機能を提供し、それは、元のフレームと冗長表現の両方が、GSM-HRフレームである場合にのみ動作します。他のメディア符号化方式の使用が望ましい場合には、一つはRFC 2198に頼らなければなりません。
The sender is responsible for selecting an appropriate amount of redundancy, based on feedback regarding the channel conditions, e.g., in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 9 for more details).
送信者は、RTP制御プロトコル（RTCP）[RFC3550]レシーバレポートに、例えば、チャネル状態に関するフィードバックに基づいて、冗長性の適切な量を選択する責任があります。送信者はまた、冗長性（詳細については、セクション9を参照）によって悪化することができる混雑を回避する責任があります。
The format of the RTP header is specified in [RFC3550]. The payload format described in this document uses the header fields in a manner consistent with that specification.
RTPヘッダのフォーマットは、[RFC3550]で指定されています。この文書に記載されたペイロード・フォーマットは、その仕様と一致する方法でヘッダフィールドを使用します。
The duration of one speech frame is 20 ms. The sampling frequency is 8000 Hz, corresponding to 160 speech samples per frame. An RTP packet may contain multiple frames of encoded speech or SID parameters. Each packet covers a period of one or more contiguous
1つの音声フレームの持続時間は20ミリ秒です。サンプリング周波数は、フレーム当たり160個の音声サンプルに対応し、8000 Hzです。 RTPパケットは、符号化された音声またはSIDパラメータの複数のフレームを含んでいてもよいです。各パケットは、1つのまたはそれ以上の連続の期間をカバー
20-ms frame intervals. During silence periods, no speech packets are sent; however, SID packets are transmitted every now and then.
20ミリ秒のフレーム間隔。沈黙期間中は、音声パケットは送信されません。しかし、SIDパケットはすべての今して送信されます。
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times. A given frame MUST NOT be encoded as a speech frame in one packet and as a SID frame or as a No_Data frame in another packet. Furthermore, a given frame MUST NOT be encoded with different voicing modes in different packets.
冗長伝送を介してエラー回復を可能にするために、複数のパケットにより覆わ期間が時間的に重なってもよいです。受信機は、任意の音声フレームを複数回受信するように準備しなければなりません。所与のフレームは、一つのパケットの音声フレームとして、およびSIDフレームとして、または別のパケット内NO_DATAフレームとして符号化されてはいけません。さらに、所与のフレームが異なるパケットで異なる発声モードで符号化されてはいけません。
The rules regarding maximum payload size given in Section 3.2 of [RFC5405] SHOULD be followed.
[RFC5405]のセクション3.2で与えられた最大ペイロードサイズに関する規則に従わされるべきです。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame in the packet. The timestamp clock frequency SHALL be 8000 Hz. The timestamp is also used to recover the correct decoding order of the frames.
RTPタイムスタンプは、パケットの最初のフレームのための符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプのクロック周波数は8000 Hzのものでなければなりません。タイムスタンプはまた、フレームの正しい復号化順序を回復するために使用されます。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame carried in the packet is the first frame in a talkspurt (see definition of the talkspurt in Section 4.1 of [RFC3551]). For all other packets, the marker bit SHALL be set to zero (M=0).
パケットで運ばれた最初のフレームが有音部の最初のフレームであるときはいつでも、RTPヘッダのマーカービット（M）は（[RFC3551]のセクション4.1でトークスパートの定義を参照）を1に設定します。他のすべてのパケットのために、マーカービットがゼロ（M = 0）に設定されなければなりません。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format.
このメモで定義されたフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。使用中のRTPプロファイルは、現在、このペイロード形式のための動的ペイロードタイプを結合義務付けます。
The remaining RTP header fields are used as specified in RFC 3550 [RFC3550].
残りのRTPヘッダフィールドは、RFC 3550 [RFC3550]で指定されるように使用されています。
The complete payload consists of a payload table of contents (ToC) section, followed by speech data representing one or more speech frames, SID frames, or No_Data frames. The following diagram shows the general payload format layout:
完全なペイロードは、一つ以上の音声フレーム、SIDフレーム、又はNO_DATAフレームを表す音声データに続くコンテンツ（TOC）セクションのペイロードテーブル、から成ります。以下の図は一般的なペイロードフォーマットのレイアウトを示しています。
+-------------+-------------------------
| ToC section | speech data section ...
+-------------+-------------------------
Figure 2: General Payload Format Layout
図2：一般的なペイロードフォーマットのレイアウト
Each ToC element is one octet and corresponds to one speech frame; the number of ToC elements is thus equal to the number of speech frames (including SID frames and No_Data frames). Each ToC entry represents a consecutive speech or SID or No_Data frame. The timestamp value for ToC element (and corresponding speech frame data) N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32. The format of the ToC element is as follows.
各目次要素は1つのオクテットであり、1つの音声フレームに対応します。目次要素の数は、このように（SIDフレームやNO_DATAフレームなど）、音声フレームの数に等しいです。各目次のエントリは、連続したスピーチやSIDまたはNO_DATAフレームを表します。目次要素（および対応する音声フレームデータ）Nペイロード内のタイムスタンプ値は、（RTPタイムスタンプフィールド+（N-1）* 160）MOD 2 ^ 32です。次のように目次要素の形式です。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+
Figure 3: The TOC Element
図3：TOC要素
F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes the last ToC element.
F：フラグに従ってください。 1より目次要素が続くことを示します。 0は、最後のToC素子です。
R: Reserved bits; MUST be set to zero, and MUST be ignored by receiver.
R：予約ビット。ゼロに設定しなければなりません、そして受信機によって無視されなければなりません。
FT: Frame type 000 = Good Speech frame 001 = Reserved 010 = Good SID frame 011 = Reserved 100 = Reserved 101 = Reserved 110 = Reserved 111 = No_Data frame
FT：フレームタイプ000 =良い音声フレーム001 =予約済み010 =良いSIDフレーム011 =予約済み100 =予約済み101 =予約済み110 =予約済み111 = NO_DATAフレーム
The length of the payload data depends on the frame type:
ペイロードデータの長さは、フレームタイプによって異なります。
Good Speech frame: The 112 speech data bits are put in 14 octets.
グッドスピーチフレーム：112音声データビットは14個のオクテットに入れています。
Good SID frame: The 33 SID data bits are put in 14 octets, as in the case of Speech frames, with the unused 79 bits all set to "1".
良好なSIDフレーム：音声の場合には「1」に、すべてのセットの未使用の79ビットで、フレームとして33のSIDのデータビットは、14個のオクテットに置かれています。
No_Data frame: Length of payload data is zero octets.
NO_DATAフレーム：ペイロードデータの長さがゼロのオクテットです。
Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad SID frame", or "No_Data frame" are not sent in RTP packets, in order to save bandwidth. They are marked as "No_Data frame", if they occur within an RTP packet that carries more than one speech frame, SID frame, or No_Data frame.
「悪いスピーチフレーム」、「悪いSIDフレーム」、または「NO_DATAフレーム」としてGSM無線サブシステム内でマークされたフレームは、帯域幅を節約するために、RTPパケットで送信されません。彼らは、複数の音声フレーム、SIDフレーム、またはNO_DATAフレームを運ぶRTPパケット内に発生した場合、これらは、「NO_DATAフレーム」としてマークされています。
The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS 46.020, Annex B [TS46.020], in their order of occurrence. The first bit (b1) of the first parameter is placed in the most significant bit (MSB) (bit 0) of the first octet (octet 1) of the payload field; the second bit is placed in bit 1 of the first octet; and so on. The last bit (b112) is placed in the least significant bit (LSB) (bit 7) of octet 14.
GSM-HR符号化された音声（B1 ... B112）の112ビットは、その出現順に、付属書B [TS46.020]、TS 46.020に定義されています。最初のパラメータの最初のビット（b1）はペイロードフィールドの最上位ビット（MSB）最初のオクテットの（ビット0）（オクテット1）に配置されています。第2のビットは、最初のオクテットのビット1に配置されます。等々。最後のビット（B112）はオクテット14の最下位ビット（LSB）（ビット7）に配置されます。
The GSM-HR codec applies a specific coding for silence periods in so-called SID frames. The coding of SID frames is based on the coding of speech frames by using only the first 33 bits for SID parameters and by setting all of the remaining 79 bits to "1".
GSM-HRコーデックは、いわゆるSIDフレームで沈黙期間のための特定の符号化を適用します。 SIDフレームの符号化は、SIDパラメータにのみ最初の33ビットを使用することによって、「1」に、残りの79ビットの全てを設定することにより、音声フレームの符号化に基づいています。
An application implementing this payload format MUST understand all the payload parameters that are defined in this specification. Any mapping of the parameters to a signaling protocol MUST support all parameters. So an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating when the communicating entities support this version of the specification.
このペイロード形式を実装アプリケーションは、本明細書で定義されているすべてのペイロード・パラメータを理解しなければなりません。シグナリングプロトコルのパラメータの任意のマッピングは、すべてのパラメータをサポートしなければなりません。そうSDPを使用してアプリケーションにこのペイロード形式の実装は、それらのSDPマッピングされた形で全てのペイロードのパラメータを理解する必要があります。この要件は、実装は常にそれが通信エンティティは、このバージョンの仕様をサポートする際に通信可能であるかどうかを決定できるようになります。
When using this RTP payload format, the sender SHOULD generate and send SID frames every 160 ms, i.e., every 8th frame, during silent periods. Other SID transmission intervals may occur due to gateways to other systems that use other transmission intervals.
このRTPペイロードフォーマットを使用する場合、送信者は、SIDはすべて160ミリ秒、サイレント期間中、すなわち、毎8フレームを、フレーム生成して送信すべきです。他のSIDの送信間隔は、他の送信間隔を使用する他のシステムへのゲートウェイに起こり得ます。
The reception of redundant audio frames, i.e., more than one audio frame from the same source for the same time slot, MUST be supported by the implementation.
冗長音声フレーム、即ち、同じタイムスロットで同じソースから複数のオーディオフレームの受信は、実装によってサポートされなければなりません。
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC of the payload, the receiver SHOULD discard the packet. This is recommended, because decoding a frame parsed from a payload based on erroneous ToC data could severely degrade the audio quality.
受信機は、受信したペイロードのサイズとペイロードの目次で示す大きさとの間に不一致が検出された場合、受信機は、パケットを破棄すべきです。誤ったTOCデータに基づいて、ペイロードから解析されたフレームを復号することは深刻なオーディオ品質を低下させる可能性があるため、これは、推奨されます。
A few examples below highlight the payload format.
いくつかの例は以下のペイロードフォーマットを強調表示します。
Below is a basic example of the aggregation of 3 consecutive speech frames into a single packet.
以下、単一のパケットに3つの連続した音声フレームの集合の基本的な例です。
The first 24 bits are ToC elements.
最初の24ビットは、目次要素です。
Bit 0 is '1', as another ToC element follows. Bits 1..3 are 000 = Good speech frame Bits 4..7 are 0000 = Reserved Bit 8 is '1', as another ToC element follows. Bits 9..11 are 000 = Good speech frame Bits 12..15 are 0000 = Reserved Bit 16 is '0'; no more ToC elements follow. Bits 17..19 are 000 = Good speech frame Bits 20..23 are 0000 = Reserved
別の目次要素は次のようにビット0が「1」です。別の目次要素は次のように0000 =予約済みビット8は、「1」である4..7 000 =良い音声フレームのビットであるビット1..3。ビット9..11は12..15 000 =良い音声フレームのビットでは0000である=予約ビット16が「0」です。これ以上のToC要素が続きません。 0000 =予約されてい20..23 000 =良い音声フレームのビットは17..19ビット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 2 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|
+-+-+-+-+-+-+-+-+
Below is an example of a payload carrying 3 frames, where the middle one is No_Data (for example, due to loss prior to transmission by the RTP source).
以下中央一方が（前のRTPソースによる伝送に損失例えば、起因）NO_DATAで3つのフレームを運ぶペイロードの一例です。
The first 24 bits are ToC elements.
最初の24ビットは、目次要素です。
Bit 0 is '1', as another ToC element follows. Bits 1..3 are 000 = Good speech frame Bits 4..7 are 0000 = Reserved Bit 8 is '1', as another ToC element follows. Bits 9..11 are 111 = No_Data frame Bits 12..15 are 0000 = Reserved Bit 16 is '0'; no more ToC elements follow. Bits 17..19 are 000 = Good speech frame Bits 20..23 are 0000 = Reserved
別の目次要素は次のようにビット0が「1」です。別の目次要素は次のように0000 =予約済みビット8は、「1」である4..7 000 =良い音声フレームのビットであるビット1..3。ビット9..11 111 = NO_DATAフレームビット12..15である0000である=予約ビット16が「0」です。これ以上のToC要素が続きません。 0000 =予約されてい20..23 000 =良い音声フレームのビットは17..19ビット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 3 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This RTP payload format is identified using the media type "audio/ GSM-HR-08", which is registered in accordance with [RFC4855] and uses [RFC4288] as a template. Note: Media subtype names are case-insensitive.
このRTPペイロードフォーマットは、テンプレートとして[RFC4855]および使用[RFC4288]に従って登録されたメディアタイプ「オーディオ/ GSM-HR-08」を使用して識別されます。注意：メディアサブタイプ名は大文字と小文字を区別しません。
The media type for the GSM-HR codec is allocated from the IETF tree, since GSM-HR is a well-known speech codec. This media type registration covers real-time transfer via RTP.
GSM-HRは、周知の音声コーデックであるため、GSM-HRコーデックのメディアタイプは、IETFツリーから割り当てられています。このメディアタイプの登録はRTP経由でリアルタイム転送をカバーしています。
Note: Reception of any unspecified parameter MUST be ignored by the receiver to ensure that additional parameters can be added in the future.
注：指定されていないパラメータの受信は、追加のパラメータは、将来的に追加することができることを保証するために、受信機で無視しなければなりません。
Type name: audio
型名：オーディオ
Subtype name: GSM-HR-08
サブタイプ名：GSM-HR-08
Required parameters: none
必須パラメータ：なし
Optional parameters:
オプションのパラメータ：
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are integers between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
MAX-赤：フレームのプライマリ（最初の）送信と送信者が使用する任意の冗長伝送の間に経過ミリ秒の最大継続時間。このパラメータは、冗長性を使用した場合、受信機が有界遅延を持つことができます。許容値は、パラメータが省略された場合、冗長性の利用に制限が存在しない（使用されない冗長性）0との間の整数および65535です。
ptime: See [RFC4566].
PTIME：[RFC4566]を参照してください。
maxptime: See [RFC4566].
maxptime：[RFC4566]を参照してください。
Encoding considerations:
エンコードの考慮事項：
This media type is framed and binary; see Section 4.8 of RFC 4288 [RFC4288].
このメディアタイプは、フレームとバイナリされます。 RFC 4288 [RFC4288]のセクション4.8を参照してください。
Security considerations:
セキュリティの考慮事項：
See Section 10 of RFC 5993.
RFC 5993のセクション10を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
The media subtype name contains "-08" to avoid potential conflict with any earlier drafts of GSM-HR RTP payload types that aren't bit-compatible.
メディアサブタイプ名が含まれている「-08」ビット互換性がありませんGSM-HR RTPペイロードタイプのいずれかの以前のドラフトとの競合を避けるために。
Published specifications:
公開された仕様：
RFC 5993, 3GPP TS 46.002
RFC 5993、3GPP TS 46.002
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Real-time audio applications like voice over IP and teleconference.
IPおよび電話会議、ボイスオーバーなどのリアルタイム・オーディオ・アプリケーションに最適です。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
インゲマル・ヨハンソン<ingemar.s.johansson@ericsson.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage:
使用に関する制限事項：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプは、RTPフレーミングに依存し、したがってのみRTP [RFC3550]を介して転送するために定義されています。他のフレーミングプロトコル内の輸送は、この時点で定義されていません。
Authors:
著者：
Xiaodong Duan <duanxiaodong@chinamobile.com>
ξプレスAodong D U <セグメント暁東@China Mobile.com>
Shuaiyu Wang <wangshuaiyu@chinamobile.com>
なぜなら王のシュウ<元帥と@China Mobile.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
マグヌスウェスター<magnus.westerlund@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
インゲマル・ヨハンソン<ingemar.s.johansson@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.com>
カールHellwigさん<karl.hellwig@ericsson.com>
Change controller:
コントローラを変更します。
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ、。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the GSM-HR codec, the mapping is as follows:
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドに特定のマッピングを有します。 SDPは、GSM-HRコーデックを採用セッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000, and the encoding parameters (number of channels) MUST either be explicitly set to 1 or omitted, implying a default value of 1.
O（ペイロードフォーマット名）メディアサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。 「a = rtpmap」のRTPクロックレートは8000でなければなりません、と符号化パラメータ（チャンネル数）が明示的に1のデフォルト値を意味する、1に設定するか省略しなければなりません。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
O任意の残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプパラメータ文字列から直接コピーすることにより、SDPの「a =のfmtp」属性に行きます。
The following considerations apply when using SDP offer/answer procedures to negotiate the use of GSM-HR payload in RTP:
RTPにGSM-HRペイロードの使用を交渉するSDPオファー/アンサー手続きを使用する場合は、次の考慮事項が適用されます。
o The SDP offerer and answerer MUST generate GSM-HR packets as described by the offered parameters.
提供されるパラメータによって記載されるようにO SDP提供者と回答は、GSM-HRパケットを生成しなければなりません。
o In most cases, the parameters "maxptime" and "ptime" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer/ answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way.
Oほとんどの場合、パラメータ「maxptime」と「PTIMEは、」相互運用性には影響しません。しかし、パラメータの設定は、アプリケーションのパフォーマンスに影響を与えることができます。 「PTIME」パラメータのSDPオファー/アンサー取り扱いは[RFC3264]に記述されています。 「maxptime」パラメータは同じように扱われなければなりません。
o The parameter "max-red" is a stream property parameter. For sendonly or sendrecv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0.
Oパラメータ「MAX-赤は」ストリームプロパティ・パラメータです。 sendonlyの又はのsendrecvユニキャストメディアストリームのために、パラメータは、ストリームの送信者が使用する冗長性に制限を宣言する。 recvonlyでストリームの場合、それが受信機に送信されたストリームのための所望の値を示しています。回答は、値を変更する場合がありますが、オファーは宣言すると同じ制限を使用することをお勧めします。マルチキャストの場合には、提供者は、制限を宣言することができます。これは、同じ値を使用して回答するものとします。このペイロード形式を使用してメディアの送信者は、常に「MAX-赤」パラメータを含めることをお勧めします。この情報は、受信機にメディアストリームの処理を簡素化する可能性があります。これは、冗長性は使用されません場合は特にそうです、「MAX-赤」が0に設定されている場合には。
o Any unknown media type parameter in an offer SHALL be removed in the answer.
Oのオファー内の任意の未知のメディアタイプパラメータが答えに撤去しなければなりません。
In declarative usage, like SDP in the Real Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], the parameters SHALL be interpreted as follows:
次のように宣言用法では、リアルタイムストリーミングプロトコル（RTSP）でSDP [RFC2326]またはセッションアナウンスメントプロトコル（SAP）[RFC2974]のように、パラメータは解釈されなければなりません。
o The stream property parameter ("max-red") is declarative, and a participant MUST follow what is declared for the session. In this case, it means that the receiver MUST be prepared to allocate buffer memory for the given redundancy. Any transmissions MUST NOT use more redundancy than what has been declared. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small.
Oストリームプロパティ・パラメータ（「MAX-赤」）は、宣言され、参加者はセッションのために宣言されているものに従わなければなりません。この場合、受信機は、所与の冗長性のためのバッファメモリを割り当てるために調製しなければならないことを意味します。任意の送信は宣言されているものよりも多くの冗長性を使用してはなりません。以上の構成は、複数のRTPペイロードタイプを宣言することで、必要に応じて提供されてもよいです。しかし、種類の数が小さく維持されなければなりません。
o Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
O任意の「maxptime」と「PTIME」の値は、セッションの参加者が合理的な性能を達成できることを保証するために注意して選択する必要があります。
One media type (audio/GSM-HR-08) has been defined, and it has been registered in the media types registry; see Section 7.1.
一つのメディアタイプ（オーディオ/ GSM-HR-08）定義されており、それはメディアタイプレジストリに登録されています。 7.1節を参照してください。
The general congestion control considerations for transporting RTP data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g., "RTP/AVP" [RFC3551].
RTPデータを転送するための一般的な輻輳制御の考慮事項が適用されます。 RTP [RFC3550]と該当RTPプロファイル、例えば、 "RTP / AVP" [RFC3551]を参照。
The number of frames encapsulated in each RTP payload highly influences the overall bandwidth of the RTP stream due to header overhead constraints. Packetizing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness. If forward error correction (FEC) is used, the amount of FEC-induced redundancy needs to be regulated such that the use of FEC itself does not cause a congestion problem.
各RTPペイロードにカプセル化されたフレームの数は非常にオーバーヘッド制約ヘッダによるRTPストリームの全体的な帯域幅に影響を与えます。各RTPペイロードに複数のフレームをパケット化して増加した遅延および減少エラー耐性を犠牲にし、ヘッダオーバヘッドしたがって送られたパケットの数を減らすことができます。前方誤り訂正（FEC）を使用する場合、FECによって誘発される冗長性の量は、FEC自体の使用が輻輳の問題を起こさないように調整する必要があります。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload, and integrity of the RTP packets through a suitable cryptographic integrity protection mechanism. A cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining whether or not an RTP packet is from a member of the RTP session.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[RFC3550]で議論したセキュリティ問題を受けることであり、該当RTPプロファイルです。このメモ内で定義されたRTPペイロードフォーマットを運ぶRTPパケットのための主要なセキュリティ上の考慮事項は、機密性、完全性、およびソース信憑です。機密性は、適切な暗号の完全性保護機構を介してRTPペイロードの暗号化、およびRTPパケットの整合性によって達成されます。暗号システムはまた、ペイロードのソースの認証を可能にすることができます。このRTPペイロードフォーマットに適したセキュリティ・メカニズムは、機密性、完全性保護、及びRTPパケットがRTPセッションのメンバーからのものであるか否かを判定することができる少なくとも元認証を提供すべきです。
Note that the appropriate mechanism to provide security to RTP and payloads following this may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, the usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g., for RTP over TCP), but other alternatives may also exist.
この次のRTP及びペイロードにセキュリティを提供するための適切な機構が変化してもよいことに留意されたいです。これは、アプリケーション、輸送、および使用されるシグナリングプロトコルに依存しています。したがって、単一のメカニズムは、適切な場合にも、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]の使用が推奨され、十分ではありません。使用することができる他の機構は、IPSec [RFC4301]とトランスポート層セキュリティ（TLS）は、[RFC5246]（例えば、TCP上のRTPのための）が、他の選択肢も存在し得ます。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data; nor does the RTP payload format contain any active content.
このRTPペイロードフォーマットとメディアデコーダは、パケット処理のために受信側計算の複雑さの有意な不均一性を示し、したがってによる病理学的データを受信すると、サービス拒否の脅威をもたらす可能性は低いありません。 RTPペイロード形式は、任意のアクティブコンテンツが含まれていません。
The authors would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky Wang, and Ying Zhang for their initial work in this area. Many thanks also go to Tomas Frankkila for useful input and comments.
著者は、この分野での最初の仕事のため暁東ドゥアン、Shuaiyu王、ロッキー王、および英張に感謝したいと思います。多くのおかげでも有用な入力とコメントのためにトーマスFrankkilaに行きます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項"、BCP 145、RFC 5405、2008年11月。
[TS46.002] 3GPP, "Half rate speech; Half rate speech processing functions", 3GPP TS 46.002, June 2007, <http:// www.3gpp.org/ftp/Specs/archive/46_series/46.002/ 46002-700.zip>.
[TS46.002] 3GPP、 "ハーフレート音声、ハーフレート音声処理機能"、3GPP TS 46.002、2007年6月、<のhttp：// www.3gpp.org/ftp/Specs/archive/46_series/46.002/ 46002から700 .zipファイル>。
[TS46.020] 3GPP, "Half rate speech; Half rate speech transcoding", 3GPP TS 46.020, June 2007, <http://www.3gpp.org/ftp/ Specs/archive/46_series/46.020/46020-700.zip>.
[TS46.020] 3GPP、 "ハーフレート音声、ハーフレート音声トランスコーディング"、3GPP TS 46.020、2007年6月、<http://www.3gpp.org/ftp/仕様/アーカイブ/ 46_series / 46.020 / 46020から700。ファスナー>。
[RFC2198] 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.
[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]李、A.、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 5109、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
Authors' Addresses
著者のアドレス
Xiaodong Duan China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R. China EMail: duanxiaodong@chinamobile.com
地区北京、100053 P.R.中国メール無しAodong D U [XI] UM中国移動通信社の53A、ξサイドドアAVE、X UA N :. @China Mobile.comセグメント暁東
Shuaiyu Wang China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R. China EMail: wangshuaiyu@chinamobile.com
シュウ王中国移動通信社の53A、ξサイドドアAVEの、X UA N地区北京せず、100053中華人民共和国メール:.元帥と@China Mobile.com理由
Magnus Westerlund Ericsson AB Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 EMail: magnus.westerlund@ericsson.com
マグヌスウェスターエリクソンABFärögatan6ストックホルム、SE-164 80スウェーデン電話：+46 8 719 0000 Eメール：magnus.westerlund@ericsson.com
Karl Hellwig Ericsson AB Ericsson Allee 1 52134 Herzogenrath Germany Phone: +49 2407 575-2054 EMail: karl.hellwig@ericsson.com
カールHellwigさんエリクソンABエリクソンアリー1 52134 Herzogenrathのドイツ電話：+49 2407 575から2054 Eメール：karl.hellwig@ericsson.com
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea Sweden Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
インゲマル・ヨハンソン、エリクソンAB研究所グランド11 SE-971 28ルレオスウェーデン電話：+46 73 0783289 Eメール：ingemar.s.johansson@ericsson.com