Network Working Group R. Even
Request for Comments: 4573 A. Lochbaum
Category: Standard Track Polycom
July 2006
MIME Type Registration for RTP Payload Format for H.224
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224.
会話型ビデオアプリケーションでは、遠端カメラ制御プロトコルは、リモートカメラを制御するために参加者によって使用されます。一般的に使用されるプロトコルはH.224を超えるITU H.281です。ドキュメントはH224メディアタイプを登録します。これは、構文とセッション記述プロトコル（SDP）H.224を使用して遠端カメラ制御プロトコルをサポートするために必要なパラメータの意味を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Far-End Camera Control Protocol .................................2
4. IANA Considerations .............................................2
4.1. Media Type Registration ....................................2
5. SDP Parameters ..................................................4
5.1. Usage with the SDP Offer Answer Model ......................4
6. Security Considerations .........................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................6
The document registers the H224 media type, which may be used by systems that use SDP [RFC4566].
文書は、SDP [RFC4566]を使用するシステムによって使用されてもよいH224メディアタイプを登録します。
This media type is used for supporting the simple far-end camera control protocol on SDP-based systems. The media type helps signaling gateways between H.323 [ITU.H323] and SDP-based systems to use far-end camera control, end to end, without any protocol translation in the middle.
このメディアタイプは、SDPベースのシステムでは、単純な遠端カメラ制御プロトコルをサポートするために使用されます。メディアタイプは、中央に任意のプロトコル変換せずに、遠端カメラ制御を使用端へためにH.323 [ITU.H323]とSDPベースのシステムとの間のゲートウェイをシグナリングするのに役立ちます。
The document defines the H224 media type since the RTP packets in H.323 annex Q [ITU.H323] carry H.224 frames [ITU.H224]. The far-end camera control protocol (FECC) is internal to the H.224 frame and is identified by the client ID field of the H.224 packet.
323附属書QでRTPパケットが[ITU.H323] H.224フレームを運ぶので、文書は[ITU.H224] H224メディアタイプを定義します。遠端カメラ制御プロトコル（FECC）は、H.224フレームの内部にあり、H.224パケットのクライアントIDフィールドによって識別されます。
The document will define the SDP [RFC4566] parameters needed to support the above far-end camera control protocol in systems that use SDP.
文書は、SDPを使用するシステムにおいて、上記遠端カメラ制御プロトコルをサポートするために必要なSDP [RFC4566]のパラメータを定義します。
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 RFC2119 [RFC2119] and indicate requirement levels for compliant RTP implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [RFC2119]に記載されており、対応RTP実装の要求レベルを示すものと解釈されます。
This simple protocol is based on ITU-T H.281[ITU.281] frames carried in ITU-T H.224 packets in an RTP/UDP channel. H.323 annex Q specifies how to build the RTP packets from the H.224 packets.
この単純なプロトコルは、RTP / UDPチャネルでのITU-T H.224パケットで運ばれたITU-T H.281 [ITU.281]フレームに基づいています。 H.323別館Qは、H.224パケットからRTPパケットを構築する方法を指定します。
Using far end camera control protocol in point-to-point calls and multipoint calls for packet-switch networks is described in H.323, annex Q.
ポイントツーポイントコール及びパケット交換ネットワークの多地点通話に使用遠端カメラ制御プロトコルは、H.323、附属書Q.に記載されています
This section describes the media types and names associated with this payload format. The registration uses the templates defined in RFC 4288 [RFC4288]. It follows RFC 3555 [RFC3555].
このセクションでは、このペイロード形式に関連付けられているメディアの種類と名前を示します。登録はRFC 4288 [RFC4288]で定義されたテンプレートを使用しています。これは、RFC 3555 [RFC3555]に従います。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: H224
MIMEサブタイプ名：H224
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations:
エンコードの考慮事項：
This media type is framed (see H.323, Annex Q [ITU.H323]) and contains binary data; see Section 4.8 of [RFC4288]
このメディアタイプは、フレーム（H.323、附属書Q [ITU.H323]を参照）、バイナリデータを含んでいます。 [RFC4288]のセクション4.8を参照してください
Security considerations: See Section 6 of RFC 4573.
セキュリティの考慮事項：RFC 4573のセクション6を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
Terminals sending simple far-end camera control commands should use this MIME type. Receivers who cannot support the protocol will reject the channel.
シンプルな遠端カメラ制御コマンドを送信する端末は、このMIMEタイプを使用する必要があります。プロトコルをサポートすることができない受信機は、チャネルを拒否します。
Published specification: RFC 4573
公開された仕様：RFC 4573
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Video conferencing applications.
ビデオ会議アプリケーション。
Additional information: None
追加情報：なし
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Roni Even: roni.even@polycom.co.il
ロニさえ：roni.even@polycom.co.il
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage:
使用に関する制限事項：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプは、RTPフレーミングに依存し、これが唯一のRTCP [RFC 3550]を介して転送するために定義されています。他のフレーミングプロトコル内の輸送は、この時点で定義されていません。
Author: Roni Even
著者：ロニでも
Change controller:
コントローラを変更します。
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ、。
The media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows:
次のようにメディアタイプアプリケーション/ H224列は、セッション記述プロトコル（SDP）内のフィールドにマッピングされます。
o The media name in the "m=" line of SDP MUST be application. The transport SHALL be any applicable RTP profile (for example RFC 3551 [RFC3551]), and the payload type is dynamic.
メディア名O「M =」SDPの行はアプリケーションでなければなりません。輸送は、任意の適用可能なRTPプロファイルでなければならない、及びペイロードタイプ（例えば、RFC 3551 [RFC3551]のための）動的です。
o The encoding name in the "a=rtpmap" line of SDP MUST be h224 (the MIME subtype).
O SDPの「A = rtpmap」ラインでエンコーディング名は、H224（MIMEサブタイプ）でなければなりません。
o The default clock rate in the "a=rtpmap" line MUST be 4800.
O「A = rtpmap」行のデフォルトのクロック・レートは4800でなければなりません。
The recommended maximum bandwidth for this protocol is 6.4 kbit/sec.
このプロトコルのために推奨される最大帯域幅は、6.4キロビット/秒です。
When offering FECC using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
オファー/アンサーモデル[RFC3264]でSDPを使用してFECCを提供する場合、以下の考慮事項が必要です。
Far-end camera control communication is uni-directional. H.224 is bi-directional and can be used to learn the capabilities of the remote video end point, e.g., how many cameras it has. The offer answer exchange is dependent on the functionality of both sides.
遠端カメラ制御通信は一方向です。 H.224は、双方向であり、それが持っている、例えば、どのように多くのカメラ、遠隔ビデオエンドポイントの機能を学ぶために使用することができます。ご回答交換は両側の機能に依存しています。
The offerer offers a sendonly channel if its camera cannot be remotely controlled and if the offerer does not intend to use H.224 to learn the capabilities of the remote video endpoints.
そのカメラを遠隔操作することができない場合や、オファーがリモートビデオエンドポイントの機能を学ぶためにH.224を使用することを意図していない場合は、オファーがsendonlyのチャネルを提供しています。
In all other cases, when the offerer's camera can be remotely controlled and/or it intends to use H.224 capabilities negotiation, the offerer offers a sendrecv channel.
オファー側のカメラを遠隔制御することができ、および/またはそれがH.224機能のネゴシエーションを使用しようとするとき、他のすべての例では、オファー側はSENDRECVチャネルを提供しています。
The answerer behavior is as follows:
以下のように回答の動作は次のとおりです。
If it receives an offer with sendonly, it answers with a recvonly if it supports far-end camera control; otherwise, it ignores/rejects the offer.
それがsendonlyのとの申し出を受けた場合は、遠端カメラ制御をサポートしている場合、それはがrecvonlyと答えます。それ以外の場合は、/を提示申し出を拒否無視します。
If it receives an offer with sendrecv and its camera can be remotely controlled, or it intends to use H.224 capabilities negotiation, it answers with a sendrecv option. If its camera cannot be remotely controlled, it can answer with a sendonly attribute. The answerer may also reject the offer if he does not support FECC or does not intend to use FECC at the moment.
それはSENDRECVとの申し出を受けて、そのカメラを遠隔制御することができ、またはそれはH.224機能のネゴシエーションを使用しようとするならば、それはSENDRECVオプションで答えます。そのカメラを遠隔操作することができない場合は、それがsendonlyの属性で答えることができます。彼はFECCをサポートしていないか、現時点ではFECCを使用することを意図していない場合は回答にも提供を拒否することができます。
H.224 payload format, defined in H.323, annex Q defines packet structure based on RTP using the RTP header structure from RFC 3550. Those packets are subject to the security considerations discussed in the RTP specification [RFC3550]. This implies that confidentiality of the media streams is achieved by encryption. Secure Realtime Transport Protocol (SRTP) [RFC3711] may be used to provide both encryption and integrity protection of RTP flow.
H.323で定義されたH.224ペイロードフォーマットは、附属書Qは、それらのパケットがRTP仕様[RFC3550]で説明したセキュリティ上の考慮の対象となっているRFC 3550からRTPヘッダ構造を使用して、RTPに基づいたパケット構造を定義します。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。セキュアリアルタイム転送プロトコル（SRTP）[RFC3711]はRTPフローの両方の暗号化と整合性の保護を提供するために使用することができます。
A potential denial-of-service threat exists for data that causes application behavior like camera movement. The attacker can inject pathological datagrams into the stream that cause the receiver to change the camera position. Therefore, the usage of data origin authentication and data integrity protection of at least the H.323 annex Q packet is RECOMMENDED; for example, with SRTP.
潜在的なサービス拒否の脅威は、カメラの動きのようなアプリケーションの動作をさせるデータのために存在します。攻撃者は、受信機は、カメラの位置を変化させる流れに病理学的データグラムを注入することができます。そのため、データ発信元認証および少なくともH.323別館のQパケットのデータ完全性保護の使用が推奨されます。例えば、SRTPと。
Note that the appropriate mechanism to ensure confidentiality and integrity of H.323 annex Q packets and their payloads is very dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
H.323別館のQパケットとそのペイロードの機密性と完全性を確保するための適切なメカニズムは、アプリケーション上および使用するトランスポートおよびシグナリングプロトコルに非常に依存していることに注意してください。 SRTPは、上記の例のように与えられているがこのように、他の可能な選択肢が存在します。
[ITU.281] International Telecommunications Union, "A far end camera control protocol for videoconferences using H.224", ITU- T Recommendation H.281, November 1994.
[ITU.281]国際電気通信連合、ITU-T勧告H.281、1994年11月「H.224を使用してビデオ会議のための遠端カメラ制御プロトコル」。
[ITU.H224] International Telecommunications Union, "A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, February 2000.
[ITU.H224]国際電気通信連合、 "H.221 LSD / HSD / HLPチャネルを使用して単純なアプリケーションのためのリアルタイム制御プロトコル。"、ITU-T勧告H.224、2000年2月。
[ITU.H323] International Telecommunications Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", ITU-T Recommendation H.323, July 2003.
[ITU.H323]国際電気通信連合、ITU-T勧告H.323、2003年7月「非保証サービスの品質を提供するローカルエリアネットワークのためのビジュアル電話システムおよび機器」。
[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年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月。
[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月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[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月。
Authors' Addresses
著者のアドレス
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
ロニでもポリコム94 DerechエムHamoshavotペタク・チクヴァ49130イスラエル
EMail: roni.even@polycom.co.il
メールアドレス：roni.even@polycom.co.il
Andrew Lochbaum Polycom 6500 River Place Blvd, Building 6 Austin, TX 78730 USA
アンドリューLochbaumポリコム6500川場所ブルバード、ビル6オースティン、TX 78730 USA
EMail: alochbaum@polycom.com
メールアドレス：alochbaum@polycom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。