RFC4573 日本語訳
4573 MIME Type Registration for RTP Payload Format for H.224. R. Even,A. Lochbaum. July 2006. (Format: TXT=13587 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Even
Request for Comments: 4573 A. Lochbaum
Category: Standard Track Polycom
July 2006
コメントを求めるワーキンググループのR.の同等の要求をネットワークでつないでください: 4573年のA.Lochbaumカテゴリ: 標準の道のPolycom2006年7月
MIME Type Registration for RTP Payload Format for H.224
H.224のためのRTP有効搭載量形式のためのMIMEの種類登録
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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メディアタイプを示します。 それは構文を定義します、そして、Session記述プロトコル(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
1. 序論…2 2. 用語…2 3. 遠くにカメラ制御プロトコルを終わらせてください…2 4. IANA問題…2 4.1. メディアは登録をタイプします…2 5. SDPパラメタ…4 5.1. SDP申し出答えモデルがある用法…4 6. セキュリティ問題…5 7. 参照…5 7.1. 標準の参照…5 7.2. 有益な参照…6
Even & Lochbaum Standard Track [Page 1] RFC 4573 FECC July 2006
標準のLochbaum道の[1ページ]RFC4573FECC2006年7月さえ
1. Introduction
1. 序論
The document registers the H224 media type, which may be used by systems that use SDP [RFC4566].
ドキュメントはH224メディアタイプを示します。(タイプはSDP[RFC4566]を使用するシステムによって使用されるかもしれません)。
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.
H.323別館Q[ITU.H323]のRTPパケットが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]を定義するでしょう。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で[RFC2119]について説明して、対応するRTP実装のために要件レベルを示すとき本書では解釈されることであるべきですか?
3. Far-End Camera Control Protocol
3. 遠端カメラ制御プロトコル
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.
この簡単なプロトコルはITU-T H.224パケットでRTP/UDPチャンネルで運ばれた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)で説明されます。
4. IANA Considerations
4. IANA問題
4.1. Media Type Registration
4.1. メディアは登録をタイプします。
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].
このセクションはこのペイロード形式に関連しているメディアタイプと名前について説明します。 登録はRFC4288[RFC4288]で定義されたテンプレートを使用します。 それはRFC3555[RFC3555]に続きます。
Even & Lochbaum Standard Track [Page 2] RFC 4573 FECC July 2006
標準のLochbaum道の[2ページ]RFC4573FECC2006年7月さえ
4.1.1. Registration of MIME Media Type application/h224
4.1.1. MIMEメディアTypeアプリケーション/h224の登録
MIME media type name: application
MIMEメディア型名: アプリケーション
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、Annex Q[ITU.H323]を見ます)、バイナリ・データを含んでいます。 セクション4.8を見ます。[RFC4288]
Security considerations: See Section 6 of RFC 4573.
セキュリティ問題: RFC4573のセクション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
広められた仕様: RFC4573
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
意図している用法: 一般的
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縁どりによって、その結果、転送のためにRTP[RFC3550]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送はこのとき、定義されません。
Author: Roni Even
以下を書いてください。 ロニ、同等
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
Even & Lochbaum Standard Track [Page 3] RFC 4573 FECC July 2006
標準のLochbaum道の[3ページ]RFC4573FECC2006年7月さえ
5. SDP Parameters
5. SDPパラメタ
The media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows:
アプリケーション/h224ストリングが写像されるメディアタイプはSessionで以下の記述プロトコル(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 MUSTでは、アプリケーションになってください。 輸送SHALLはどんな適切なRTPプロフィール(例えば、RFC3551[RFC3551])でありも、ありますペイロードが、タイプする。ダイナミック。
o The encoding name in the "a=rtpmap" line of SDP MUST be h224
(the MIME subtype).
o コード化はh224が(MIME「副-タイプ」)であったなら"a=rtpmap"でSDP MUSTの台詞を命名します。
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.4kbit/秒です。
5.1. Usage with the SDP Offer Answer Model
5.1. SDP申し出答えモデルがある用法
When offering FECC using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
Offer/答えモデル[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.
遠端カメラコントロールコミュニケーションはuni方向上です。 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.
いつ申出人のカメラを離れて制御できるか、そして、そして/または、それは、申出人が他のすべての場合でsendrecvチャンネルを提供するのをH.224能力交渉を使用するつもりです。
The answerer behavior is as follows:
answererの振舞いは以下の通りです:
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を使用しないつもりであるなら、answererは申し出を拒絶するかもしれません。
Even & Lochbaum Standard Track [Page 4] RFC 4573 FECC July 2006
標準のLochbaum道の[4ページ]RFC4573FECC2006年7月さえ
6. Security Considerations
6. セキュリティ問題
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.224ペイロード形式、H.323で定義されています、別館QはRFC3550からRTPヘッダー構造を使用することでRTPに基づくパケット構造を定義します。 それらのパケットはRTP仕様[RFC3550]で議論したセキュリティ問題を受けることがあります。 これは、メディアストリームの秘密性が暗号化で達成されるのを含意します。 安全なRealtime Transportプロトコル(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パケットのデータ保全保護はRECOMMENDEDです。 例えば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を上に与えますが、他の可能な選択は存在しています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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]国際Telecommunications Union、「H.224を使用するビデオ会議のための遠端カメラ制御プロトコル」ITU T1994年11月のRecommendation H.281。
[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]国際Telecommunications Union、「H.221 LSD/HSD/HLPチャンネルを使用するシンプレクスアプリケーションのための実時間制御プロトコル」、ITU-T Recommendation 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]国際Telecommunications Union、「展示はサービスの非保証品質を提供するローカル・エリア・ネットワークのためにシステムと設備に電話をします」、ITU-T Recommendation 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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Even & Lochbaum Standard Track [Page 5] RFC 4573 FECC July 2006
標準のLochbaum道の[5ページ]RFC4573FECC2006年7月さえ
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
7.2. Informative References
7.2. 有益な参照
[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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、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の種類登録」、RFC3555、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
Authors' Addresses
作者のアドレス
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
ロニ同等のPolycom94DerechイエムHamoshavot Petach Tikva49130イスラエル
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 Polycom6500場所のBlvd川、ビル6オースチン、テキサス78730米国
EMail: alochbaum@polycom.com
メール: alochbaum@polycom.com
Even & Lochbaum Standard Track [Page 6] RFC 4573 FECC July 2006
標準のLochbaum道の[6ページ]RFC4573FECC2006年7月さえ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Even & Lochbaum Standard Track [Page 7]
同等、そして、Lochbaumの標準の道[7ページ]
一覧
スポンサーリンク
