[要約] RFC 4040は、64 kbit/sの透過型通話のためのRTPペイロード形式に関する仕様です。このRFCの目的は、透過型通話の品質を向上させるために、RTPペイロード形式を定義することです。
Network Working Group R. Kreuter
Request for Comments: 4040 Siemens AG
Category: Standards Track April 2005
RTP Payload Format for a 64 kbit/s Transparent Call
64 kbit/s透明な呼び出しのRTPペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".
このドキュメントでは、「ClearMode」と呼ばれる擬似コデックを使用して、RTPパケットで64 Kbit/sチャネルデータを透過的に運ぶ方法について説明します。また、「Audio/ClearMode」と呼ばれる関連MIMEタイプの登録としても機能します。
"Clearmode" is a basic feature of VoIP Media Gateways.
「ClearMode」は、VoIPメディアゲートウェイの基本的な機能です。
Table of Contents
目次
1. Introduction.................................................. 2
2. Conventions Used in This Document............................. 2
3. 64 kbit/s Data Stream Handling and RTP Header Parameters...... 3
4. IANA Considerations........................................... 3
5. Mapping to Session Description Protocol (SDP) Parameters...... 5
6. Security Considerations....................................... 5
7. References.................................................... 6
7.1. Normative References..................................... 6
7.2. Informative References................................... 6
8. Acknowledgements.............................................. 7
Voice over IP (VoIP) Media Gateways need to carry all possible data streams generated by analog terminals or integrated services digital network (ISDN) terminals via an IP network. Within this document a
Voice over IP（VoIP）メディアゲートウェイは、IPネットワークを介してアナログ端末または統合サービスデジタルネットワーク（ISDN）端子によって生成されたすべての可能なデータストリームを運ぶ必要があります。このドキュメント内a
VoIP Media Gateway is a device that converts a (digital or analog) linear data stream to a digital packetized data stream or vice versa. Refer to RFC 2719 [10] for an introduction into the basic architecture of a Media Gateway based network.
VoIP Media Gatewayは、（デジタルまたはアナログ）線形データストリームをデジタルパケット化されたデータストリームに変換するデバイス、またはその逆です。メディアゲートウェイベースのネットワークの基本アーキテクチャの紹介については、RFC 2719 [10]を参照してください。
Usually a VoIP Media Gateway does some processing on the data it converts besides packetization or depacketization; i.e. echo cancellation or dual tone multifrequency (DTMF) detection, and especially a coding/decoding. But there is a class of data streams that does not rely on or allow any data processing within the VoIP Media Gateway except for packetization or depacketization. ISDN data terminals i.e. will produce data streams that are not compatible with a non-linear encoding as used for voice.
通常、VoIPメディアゲートウェイは、パケット化またはデパケット化以外に、変換するデータでいくつかの処理を行います。すなわち、エコーキャンセルまたはデュアルトーンマルチフェーク（DTMF）検出、特にコーディング/デコード。ただし、パケット化またはデパケットを除いて、VoIPメディアゲートウェイ内のデータ処理に依存しない、または許可しないデータストリームのクラスがあります。ISDNデータ端子、つまり、音声に使用される非線形エンコードと互換性のないデータストリームを生成します。
For such applications, there is a necessity for a transparent relay of 64 kbit/s data streams in real-time transport protocol (RTP) [4] packets. This mode is often referred to as "clear-channel data" or "64 kbit/s unrestricted". No encoder/decoder is needed in that case, but a unique RTP payload type is necessary and a related MIME type is to be registered for signaling purposes.
このようなアプリケーションには、リアルタイムトランスポートプロトコル（RTP）[4]パケットで64 Kbit/sデータストリームの透明リレーが必要です。このモードは、多くの場合、「クリアチャネルデータ」または「64 kbit/s無制限」と呼ばれます。その場合、エンコーダー/デコーダーは必要ありませんが、一意のRTPペイロードタイプが必要であり、関連するMIMEタイプがシグナリングの目的で登録されます。
Clearmode is not restricted to the examples described above. It can be used by any application, that does not need a special encoding/decoding for transfer via a RTP connection.
ClearModeは、上記の例に制限されていません。任意のアプリケーションで使用できます。これは、RTP接続を介して転送に特別なエンコード/デコードを必要としません。
This payload format document describes a pseudo-codec called "Clearmode", for sample oriented 64 kbit/s data streams with 8 bits per sample. It is in accordance with RFC 2736 [1], which provides a guideline for the specification of new RTP payload formats.
このペイロード形式のドキュメントでは、サンプルあたり8ビットのサンプル指向64 Kbit/sデータストリームについて、「ClearMode」と呼ばれる擬似コデックについて説明しています。これは、新しいRTPペイロード形式の仕様のガイドラインを提供するRFC 2736 [1]に従っています。
Examples for the current use of Clearmode are the transfer of "ISDN 7 kHz voice" and "ISDN data" in VoIP Media Gateways.
ClearModeの現在の使用の例は、VoIPメディアゲートウェイでの「ISDN 7 kHz音声」と「ISDNデータ」の転送です。
This document also serves as the MIME type registration according to RFC 2045 [2] and RFC 2048 [3], which defines procedures for registration of new MIME types within the IETF tree.
このドキュメントは、IETFツリー内の新しいMIMEタイプの登録手順を定義するRFC 2045 [2]およびRFC 2048 [3]に従って、MIMEタイプの登録としても機能します。
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 [8].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [8]に記載されているように解釈される。
Clearmode does not use any encoding or decoding. It just provides packetization.
ClearModeはエンコードまたはデコードを使用しません。パケット化を提供するだけです。
Clearmode assumes that the data to be handled is sample oriented with one octet (8bits) per sample. There is no restriction on the number of samples per packet other than the 64 kbyte limit imposed by the IP protocol. The number of samples SHOULD be less than the path maximum transmission unit (MTU) minus combined packet header length. If the environment is expected to have tunnels or security encapsulation as part of operation, the number of samples SHOULD be reduced to allow for the extra header space.
ClearModeは、処理するデータがサンプルごとに1オクテット（8ビット）でサンプル指向であると想定しています。IPプロトコルによって課された64 kbyte制限以外に、パケットごとのサンプルの数に制限はありません。サンプルの数は、パス最大透過ユニット（MTU）を引いたパケットヘッダーの長さをマイナスするよりも少なくする必要があります。環境に操作の一部としてトンネルまたはセキュリティカプセル化があると予想される場合、追加のヘッダースペースを可能にするためにサンプルの数を減らす必要があります。
The payload packetization/depacketization for Clearmode is similar to the Pulse Code Modulation (PCMU or PCMA) handling described in RFC 3551 [5]. Each Clearmode octet SHALL be octet-aligned in an RTP packet. The sign bit of each octet SHALL correspond to the most significant bit of the octet in the RTP packet.
ClearModeのペイロードパケット化/デパケット化は、RFC 3551 [5]で説明されているパルスコード変調（PCMUまたはPCMA）処理に似ています。各ClearModeオクテットは、RTPパケットでオクテットに並べられます。各オクテットのサインビットは、RTPパケットのオクテットの最も重要なビットに対応するものとします。
A sample rate of 8000 Hz MUST be used. This calculates to a 64 kbit/s transmission rate per channel.
8000 Hzのサンプルレートを使用する必要があります。これにより、チャネルあたりの64 kbit/s伝送速度に計算されます。
The Timestamp SHALL be set as described in RFC 3550 [4].
タイムスタンプは、RFC 3550 [4]に記載されているように設定するものとします。
The marker bit is always zero. Silence suppression is not applicable for Clearmode data streams.
マーカービットは常にゼロです。沈黙の抑制は、クリアモードデータストリームには適用されません。
The payload type is dynamically assigned and is not presented in this document.
ペイロードタイプは動的に割り当てられており、このドキュメントには表示されません。
RTP header fields not mentioned here SHALL be used as specified in RFC 3550 [4] and any applicable profile.
ここで言及されていないRTPヘッダーフィールドは、RFC 3550 [4]および該当するプロファイルで指定されているように使用するものとします。
This document specifies the use of RTP over unicast and multicast UDP as well as TCP. (This does not preclude the use of this definition when RTP is carried by other lower-layer protocols.)
このドキュメントは、UnicastおよびマルチキャストUDPよりもRTPの使用、およびTCPを指定しています。（これは、RTPが他の低層プロトコルによって運ばれた場合、この定義の使用を排除しません。）
This document registers the following MIME subtype: audio/clearmode.
このドキュメントは、次のMIMEサブタイプを登録します：Audio/ClearMode。
To: ietf-types@iana.org
宛先：ietf-types@iana.org
Subject: Registration of MIME media type audio/clearmode
件名：Mime Media Type Audio/ClearModeの登録
MIME media type name: audio MIME subtype name: clearmode
MIMEメディアタイプ名：オーディオMIMEサブタイプ名：ClearMode
Required parameters: none
必要なパラメーター：なし
Optional parameters: ptime, maxptime
オプションのパラメーター：ptime、maxptime
"ptime" gives the length of time in milliseconds represented by the media in a packet, as described in RFC 2327 [6].
「Ptime」は、RFC 2327 [6]に記載されているように、パケットでメディアが表すミリ秒の時間を与えます。
"maxptime" represents the maximum amount of media, which can be encapsulated in each packet, expressed as time in milliseconds, as described in RFC 3267 [9].
「Maxptime」は、RFC 3267 [9]で説明されているように、各パケットに時間として表される各パケットにカプセル化できるメディアの最大量を表します。
Encoding considerations:
考慮事項のエンコード：
This type is only defined for transfer via RTP [4].
このタイプは、RTP [4]を介した転送に対してのみ定義されます。
Security considerations:
セキュリティ上の考慮事項：
See Section 6 of RFC 4040
RFC 4040のセクション6を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4040
公開された仕様：RFC 4040
Applications, which use this media type:
このメディアタイプを使用するアプリケーション：
Voice over IP Media Gateways, transferring "ISDN 64 kb/s data", "ISDN 7 kHz voice", or other 64 kbit/s data streams via an RTP connection
IPメディアゲートウェイの音声、「ISDN 64 KB/sデータ」、「ISDN 7 kHz音声」、またはRTP接続を介してその他の64 kbit/sデータストリームの転送
Note: the choice of the "audio" top-level MIME type was made because the dominant uses of this pseudo-codec are expected to telephony and voice-gateway-related. The "audio" type allows the use of sharing of the port in the SDP "m=" line with codecs such as audio/g711 [6], [7], for one example. This sharing is an important application and would not be possible otherwise.
注：「オーディオ」のトップレベルのマイムタイプの選択が行われました。この擬似コデックの支配的な用途は、テレフォニーとボイスゲートウェイ関連が予想されるためです。「オーディオ」タイプは、1つの例として、Audio/G711 [6]、[7]などのコーデックとSDP「M =」ラインでポートを共有することを可能にします。この共有は重要なアプリケーションであり、そうでなければ不可能です。
Additional information: none
追加情報：なし
Intended usage: COMMON
意図された使用法：共通
Author/Change controller:
著者/変更コントローラー：
IETF Audio/Video transport working group delegated from the IESG
IESGから委任されたIETFオーディオ/ビデオトランスポーキングワーキンググループ
Parameters are mapped to SDP [6] in a standard way.
パラメーターは、標準的な方法でSDP [6]にマッピングされます。
o The MIME type (audio) goes in SDP "m=" as the media name.
o MIMEタイプ（オーディオ）は、SDP "M ="でメディア名として掲載されます。
o The MIME subtype (clearmode) goes in SDP "a=rtpmap" as the encoding name.
o MIMEサブタイプ（ClearMode）は、エンコーディング名としてSDP "a = rtpmap"になります。
o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o オプションのパラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」および「A = MaxPtime」属性に移動します。
An example mapping is as follows:
マッピングの例は次のとおりです。
audio/clearmode; ptime=10
Audio/ClearMode;ptime = 10
m=audio 12345 RTP/AVP 97
a=rtpmap:97 CLEARMODE/8000
a=ptime:10
Note that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places.
RTPプロファイルで定義されているペイロード形式（エンコーディング）名前は、一般的に上品に表示されることに注意してください。MIMEサブタイプは、一般的に小文字で表示されます。これらの名前は、両方の場所でケースに依存しません。
Implementations using the payload format defined in this specification are subject to the security considerations discussed in the RFC 3550 [4]. The payload format described in this document does not specify any different security services. The primary function of this payload format is to add a transparent transport for a 64 kbit/s data stream.
この仕様で定義されているペイロード形式を使用した実装は、RFC 3550 [4]で説明されているセキュリティ上の考慮事項の対象となります。このドキュメントで説明されているペイロード形式は、別のセキュリティサービスを指定しません。このペイロード形式の主な機能は、64 kbit/sのデータストリームに透明な輸送を追加することです。
Confidentiality of the media streams is achieved by encryption, for example by application of the Secure RTP profile [11].
メディアストリームの機密性は、たとえば安全なRTPプロファイルの適用により、暗号化によって達成されます[11]。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication MAY be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. Overload can also occur, if the sender chooses to use a smaller packetization period, than the receiver can process. The ptime parameter can be used to negotiate an appropriate packetization during session setup.
他のIPベースのプロトコルと同様に、状況によっては、受信者が、望ましいまたは望ましくないあまりにも多くのパケットを受け取るだけで過負荷になる場合があります。ネットワーク層認証は、望ましくないソースからパケットを破棄するために使用できますが、認証自体の処理コストが高すぎる場合があります。受信者が処理できるよりも、送信者がより小さなパケット化期間を使用することを選択した場合、過負荷も発生する可能性があります。PTIMEパラメーターを使用して、セッションのセットアップ中に適切なパケット化を交渉できます。
In general RTP is not an appropriate transfer protocol for reliable octet streams. TCP is better in those cases. Besides that, packet loss due to congestion is as much an issue for clearmode, as for other payload formats. Refer to RFC 3551 [5], section 2, for a discussion of this issue.
一般に、RTPは信頼できるオクテットストリームの適切な転送プロトコルではありません。これらの場合、TCPは優れています。それに加えて、輻輳によるパケットの損失は、他のペイロード形式と同様に、ClearModeにとっても問題です。この問題の議論については、RFC 3551 [5]、セクション2を参照してください。
[1] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[1] Handley、M。and C. Perkins、「RTPペイロード形式の仕様の作家のためのガイドライン」、BCP 36、RFC 2736、1999年12月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[3] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[9] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[9] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、「リアルタイムトランスポートプロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）および適応型マルチレートワイドバンドのファイルストレージ形式（AMR-WB）Audio Codecs "、RFC 3267、2002年6月。
[10] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[10] Ong、L.、Rytina、I.、Garcia、M.、Schwarzbauer、H.、Coene、L.、Lin、H.、Juhasz、I.、Holdrege、M。、およびC. Sharp、 "Sharpのフレームワークアーキテクチャ輸送」、RFC 2719、1999年10月。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[11] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
The editor would like to acknowledge the help of the IETF AVT Working Group and, in particular the help of Colin Perkins and Magnus Westerlund for their intensive reviews and comments.
編集者は、IETF AVTワーキンググループの助け、特にコリンパーキンスとマグナスウェスターランドの集中的なレビューとコメントの支援を認めたいと考えています。
Author's Address
著者の連絡先
Ruediger Kreuter Siemens AG 81730 Munich, Germany
Ruediger Kreuter Siemens AG 81730ミュンヘン、ドイツ
EMail: ruediger.kreuter@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。