RFC 4573 - MIME Type Registration for RTP Payload Format for H.224 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4573
タイトル : RFC 4573 - H.224のRTPペイロード形式のMIMEタイプ登録
翻訳編集 : 自動生成

[要約] RFC 4573は、H.224のRTPペイロード形式のためのMIMEタイプ登録に関する規格です。このRFCの目的は、H.224のRTPペイロード形式を正確に識別し、適切な処理を行うためのMIMEタイプを定義することです。

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

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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メディアタイプを登録します。これは、H.224を使用してファーエンドカメラ制御プロトコルをサポートするために必要なセッション説明プロトコル（SDP）パラメーターの構文とセマンティクスを定義します。

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. Introduction

1. はじめに

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.

このドキュメントでは、H.323 Annex 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.

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.

この単純なプロトコルは、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で説明されています。

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].

このセクションでは、このペイロード形式に関連付けられたメディアの種類と名前について説明します。登録は、RFC 4288 [RFC4288]で定義されているテンプレートを使用します。RFC 3555 [RFC3555]に従います。

4.1.1. Registration of MIME Media Type application/h224

4.1.1. MIMEメディアタイプアプリケーションの登録/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、付録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:

詳細については、人とメールアドレスをお問い合わせください。

Roni Even: roni.even@polycom.co.il

roni偶数：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:

Change Controller：

IETF Audio/Video Transport working group, delegated from the IESG.

IETFオーディオ/ビデオトランスポートワーキンググループ、IESGから委任されました。

5. SDP Parameters

5. SDPパラメーター

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 SDPの「m =」行のメディア名は適用されなければなりません。トランスポートは、適用可能な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 kbit/secです。

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.

オファー/回答モデル[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を使用してリモートビデオエンドポイントの機能を学習するつもりがない場合、センドンリーチャネルを提供します。

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を使用するつもりがない場合、申し出を拒否する場合があります。

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.323で定義されたH.224ペイロード形式、付録Qは、RFC 3550のRTPヘッダー構造を使用してRTPに基づいてパケット構造を定義します。これらのパケットは、RTP仕様[RFC3550]で説明されているセキュリティに関する考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。セキュアリアルタイムトランスポートプロトコル（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 Annex 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 Annex 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] International Telecommunications Union、「H.224を使用したビデオ会議のためのファーエンドカメラ制御プロトコル」、1994年11月、H.281 ITUT推奨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] International Telecommunications Union、「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] International Telecommunications Union、「保証されていないサービス品質を提供するローカルエリアネットワーク向けの視覚電話システムと機器」、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] 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月。

[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月。

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プロファイル」、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.、McGrew、D.、Naslund、M.、Carrara、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] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。

Authors' Addresses

著者のアドレス

Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel

Roni均等なPolycom 94 Derech Em Hamoshavot Petach Tikva 49130イスラエル

   EMail: roni.even@polycom.co.il

Andrew Lochbaum Polycom 6500 River Place Blvd, Building 6 Austin, TX 78730 USA

Andrew Lochbaum Polycom 6500 River Place Blvd、Building 6 Austin、TX 78730 USA

   EMail: alochbaum@polycom.com

Full Copyright Statement

完全な著作権声明

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 provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。