[要約] RFC 5993は、GSM-HRのためのRTPペイロード形式を定義しています。このRFCの目的は、GSM-HRの音声データをRTPパケットにエンコードするための標準化を提供することです。
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)
モバイル通信用のグローバルシステム用のRTPペイロード形式ハーフレート（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.
このドキュメントは、モバイル通信のためのグローバルシステムのパケット化ハーフレート（GSM-HR）スピーチコーデックデータのリアルタイムトランスポートプロトコル（RTP）へのペイロード形式を指定します。ペイロード形式は、冗長性を使用したペイロードあたりの複数のフレームとパケット損失の堅牢性方法の送信をサポートします。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントは、GSMハーフレート（GSM-HR）Codec [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.
このドキュメントは、コンベンション、コーデックの簡単な説明、ペイロード形式の機能から始まります。ペイロード形式はセクション5で指定されています。例はセクション6にあります。メディアタイプの仕様とSDPへのマッピング、およびセッション説明プロトコル（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）ペイロード形式のメディアタイプ（Audio/GSM-HR-08）を登録します。注：この形式は、1999年から2000年にRFC 3551として公開された初期ドラフトバージョンで提供されたものと互換性がありません。RFC3551は、後のバージョンのオーディオビジュアルプロファイル（AVP）ドラフトに基づいていました。GSM-HRペイロード形式の仕様は提供されません。この古い形式との競合の可能性を回避するために、このドキュメントで指定されているペイロード形式のメディアタイプには、（Audio/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ネットワークで使用される音声コーデックの1つです。GSM-HRは、[TS46.002]で指定されているハーフレートの音声コーデックを示します。
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コーデックのフレーム長は20ミリ秒で、8000 Hz、つまりフレームあたり160のサンプルで狭帯域の音声がサンプリングされています。各音声フレームは、112ビットの音声パラメーターに圧縮されます。これは、5.6 kbit/sのビットレートに相当します。音声一時停止は、標準化された音声アクティビティ検出（VAD）によって検出されます。音声一時停止中、音声フレームの送信が阻害されます。Silence Descriptor（SID）フレームは、Talkspurtの最後に、および音声停止中に約480ミリ秒ごとに送信され、レシーバー側のまともな快適なノイズ（CN）品質を可能にします。
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フレームは20ミリ秒ごとにGSMベースステーションに送信され、ダウンリンクラジオトランスミッションのために480ミリ秒ごとに1つしか選択されません。IPを超えるトランスポートなど、他のアプリケーションでは、20ミリ秒ごとより頻繁にSIDフレームを送信する方が適切ですが、480ミリ秒はあまりにもまばらである可能性があります。妥協として、GSM無線ネットワークの外側のGSM-HRエンコーダー（つまり、GSMモバイルステーションではなく、GSM無線サブシステムではなく、たとえば、コアネットワークのメディアゲートウェイ）を生成することをお勧めします。160ミリ秒ごとにSIDフレームを送信します。
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.
このRTPペイロードフォーマットには、1つ以上のGSM-HRエンコードされたフレーム（フルボイスまたはサイレンス記述子（SID））がモノの音声信号を表します。同期を維持したり、フレームや失われたフレームを示すために、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ペイロードパケットで1回再送信されます。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 20-ms frame intervals. During silence periods, no speech packets are sent; however, SID packets are transmitted every now and then.
1つの音声フレームの期間は20ミリ秒です。サンプリング周波数は8000 Hzで、フレームあたり160個の音声サンプルに対応しています。RTPパケットには、エンコードされた音声またはSIDパラメーターの複数のフレームが含まれる場合があります。各パケットは、1つ以上の隣接する20 msフレーム間隔の期間をカバーします。沈黙期間中、音声パケットは送信されません。ただし、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.
冗長な伝送を介してエラーの弾力性を可能にするために、複数のパケットでカバーされている期間が時間内に重複する場合があります。レシーバーは、スピーチフレームを複数回受信する準備をする必要があります。特定のフレームは、1つのパケットのスピーチフレームとして、また別のパケットでは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タイムスタンプは、パケット内の最初のフレームにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数は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）は、パケットに掲載された最初のフレームがTalkspurtの最初のフレームである場合は1に設定されます（[RFC3551]のセクション4.1のTalkspurtの定義を参照）。他のすべてのパケットについては、マーカービットをゼロ（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:
完全なペイロードは、コンテンツのペイロードテーブル（TOC）セクションで構成され、その後、1つ以上の音声フレーム、SIDフレーム、またはNO_DATAフレームを表す音声データが続きます。次の図は、一般的なペイロード形式のレイアウトを示しています。
+-------------+-------------------------
| 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.
各TOC要素は1つのオクテットで、1つの音声フレームに対応します。したがって、TOC要素の数は、音声フレームの数（SIDフレームとNO_DATAフレームを含む）に等しくなります。各TOCエントリは、連続したスピーチまたはSIDまたはNO_DATAフレームを表します。ペイロード内のTOC要素（および対応する音声フレームデータ）nのタイムスタンプ値は（RTPタイムスタンプフィールド（n-1）*160）mod 2^32です。TOC要素の形式は次のとおりです。
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は、より多くのTOC要素が続くことを示します。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 =グッドシドフレーム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フレーム：33のSIDデータビットは、音声フレームの場合のように14オクテットに入れられ、未使用の79ビットはすべて「1」に設定されています。
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.
帯域幅を保存するために、GSM無線サブシステムで「悪い音声フレーム」、「悪いSIDフレーム」、または「NO_DATAフレーム」としてマークされたフレームは、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.
112ビットのGSM-HRコードされた音声（B1 ... B112）は、発生順にTS 46.020、付録B [TS46.020]で定義されています。最初のパラメーターの最初のビット（B1）は、ペイロードフィールドの最初のオクテット（オクテット1）の最も重要なビット（MSB）（ビット0）に配置されます。2番目のビットは、最初のオクテットのビット1に配置されます。等々。最後のビット（B112）は、Octet 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ビットのみを使用し、残りの79ビットをすべて「1」に設定することにより、音声フレームのコーディングに基づいています。
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ペイロード形式を使用する場合、送信者は、サイレント期間中、160ミリ秒ごと、つまり8番目のフレームごとにSIDフレームを生成および送信する必要があります。他の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で示されるサイズの間の不一致を受信者が見つけた場合、受信機はパケットを破棄する必要があります。これは推奨されます。これは、誤った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ビットはTOC要素です。
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
別のTOC要素が続くように、ビット0は「1」です。ビット1..3は000 =良い音声フレームビット4..7は0000 =予約されたビット8は「1」です。ビット9..11は000 =良い音声フレームビット12..15は0000 =予約済みビット16は「0」です。これ以上のTOC要素は続きません。ビット17..19は000 =良い音声フレームビット20..23は0000 =予約されています
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).
以下は、3つのフレームを運ぶペイロードの例です。中央のフレームはNO_DATAです（たとえば、RTPソースによる送信前の損失による）。
The first 24 bits are ToC elements.
最初の24ビットはTOC要素です。
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
別のTOC要素が続くように、ビット0は「1」です。ビット1..3は000 =良い音声フレームビット4..7は0000 =予約されたビット8は「1」です。ビット9..11は111 = no_dataフレームビット12..15は0000 =予約済みビット16 is '0';これ以上のTOC要素は続きません。ビット17..19は000 =良い音声フレームビット20..23は0000 =予約されています
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]をテンプレートとして使用しているメディアタイプ「Audio/ 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-Red：フレームの一次（最初の）送信と、送信者が使用する冗長送信の間に経過するミリ秒単位での最大期間。このパラメーターにより、冗長性を使用すると、レシーバーが境界遅延を持つことができます。許容値は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.
Voice Over IPやTeleconferenceなどのリアルタイムオーディオアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Intended usage: 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>
Shuaiyu Wang <wangshuaiyu@chinamobile.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.com>
Change controller:
コントローラーの変更：
IETF Audio/Video Transport working group, delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループ、IESGから委任されました。
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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPを使用してGSM-HRコーデックを採用するセッションを指定する場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名として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」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
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 残りのパラメーターは、Media型パラメーター文字列から直接コピーすることにより、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-red」は、ストリームプロパティパラメーターです。SendonlyまたはSendRecv Unicast Media Streamsの場合、パラメーターは、ストリーム送信者が使用する冗長性の制限を宣言します。Recvonlyストリームの場合、レシーバーに送信されたストリームの望ましい値を示します。応答者は値を変更する場合がありますが、オファーが宣言するのと同じ制限を使用することをお勧めします。マルチキャストの場合、提供者は制限を宣言することができます。これは、同じ値を使用して回答するものとします。このペイロード形式を使用するメディア送信者は、常に「最大赤」パラメーターを含めるようにお勧めします。この情報は、受信機のメディアストリームの処理を簡素化する可能性があります。これは、冗長性が使用されない場合に特に当てはまります。その場合、「最大赤」が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: 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.
リアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはセッションアナウンスプロトコル（SAP）[RFC2974]のSDPのような宣言的使用法では、パラメーターは次のように解釈されます。宣言的であり、参加者はセッションで宣言されているものに従わなければなりません。この場合、特定の冗長性のためにバッファメモリを割り当てるために受信機を準備する必要があることを意味します。送信は、宣言されたものよりも多くの冗長性を使用してはなりません。複数の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.
1つのメディアタイプ（Audio/GSM-HR-08）が定義されており、Media型レジストリに登録されています。セクション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.
著者は、この分野での最初の仕事について、Xiaodong Duan、Shuaiyu Wang、Rocky Wang、Ying Zhangに感謝したいと思います。また、有用な入力とコメントをしてくれたTomas Frankkilaにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Eggert、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/46_series/46.002/ 46002-700700.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/ active/46_series/46.020/46020-700。zip>。
[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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-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.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、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] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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
Xiaodong Duan China Mobile Communications Corporation 53a、Xibianmennei Ave.、Xuanwu District Beijing、100053 P.R. China Email：duanxiaodong@chinamobile.com
Shuaiyu Wang China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R. China EMail: wangshuaiyu@chinamobile.com
Shuaiyu Wang China Mobile Communications Corporation 53a、Xibianmennei Ave.、Xuanwu District Beijing、100053 P.R. China Email：wangsuaiyu@chinamobile.com
Magnus Westerlund Ericsson AB Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 EMail: magnus.westerlund@ericsson.com
マグナスウェスターランドエリクソンABファロガタン6ストックホルム、SE-164 80スウェーデン電話：46 8 719 0000メール：Magnus.westerlund@ericsson.com
Karl Hellwig Ericsson AB Ericsson Allee 1 52134 Herzogenrath Germany Phone: +49 2407 575-2054 EMail: karl.hellwig@ericsson.com
Karl Hellwig Ericsson Ab Ericsson Allee 1 52134 Herzoenrath Germany電話：49 2407 575-2054メール：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
INGEMAR JOHANSSON ERICSSON AB LaboratorieGrand 11 SE-971 28 Lulea Sweden電話：46 73 0783289メール：gemar.s.johansson@ericsson.com