[要約] RFC 5168は、メディア制御のためのXMLスキーマに関するものであり、メディア制御プロトコルの相互運用性を向上させることを目的としています。
Network Working Group O. Levin
Request for Comments: 5168 Microsoft Corporation
Category: Informational R. Even
Polycom
P. Hagendorf
RADVISION
March 2008
XML Schema for Media Control
メディア制御用のXMLスキーマ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.
このドキュメントでは、Microsoft、Polycom、Radvisionによって開発され、複数のベンダーが使用した、厳密に制御された環境でのビデオ高速更新用の拡張可能なマークアップ言語（XML）スキーマを定義します。このドキュメントでは、過去3年間にわたってセッション開始プロトコル（SIP）ベースのシステムで展開されており、さまざまなベンダーからのリアルタイムインタラクティブアプリケーション全体で相互運用可能な方法で使用されている方法について説明します。新しい実装は、逆方向の互換性を除いて、説明した方法を使用することを妨げられます。RTPコントロールプロトコル（RTCP）チャネルで新しい完全なリクエストコマンドを使用するには、新しい実装が必要です。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................2
3. Background ......................................................3
4. The Video Control Commands ......................................3
5. The Schema Definition ...........................................4
6. Error Handling ..................................................5
7. Examples ........................................................5
7.1. The Fast Update Command for the Full Picture ...............5
7.2. Reporting an Error .........................................5
8. Transport .......................................................6
9. IANA Considerations .............................................6
9.1. Application/media_control+xml Media Type Registration ......6
10. Security Considerations ........................................7
11. References .....................................................8
11.1. Normative References ......................................8
11.2. Informative References ....................................8
This document defines an Extensible Markup Language (XML) Schema for video fast update request in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. Implementation of this schema for interactive video applications in Session Initiation Protocol (SIP) [5] environments was designed in order to improve user experience. This mechanism is being used by both end user video conferencing terminals and conferencing servers in shipping products. This document describes the current method, but new implementations are discouraged from using this method, except for backward compatibility with legacy systems. Shipping products and new products SHOULD use the Full Intra Request, described in [7].
このドキュメントでは、Microsoft、Polycom、Radvisionによって開発され、複数のベンダーが使用した、厳密に制御された環境でのビデオ高速更新要求のための拡張可能なマークアップ言語（XML）スキーマを定義します。セッション開始プロトコル（SIP）[5]環境におけるインタラクティブビデオアプリケーションのこのスキーマの実装は、ユーザーエクスペリエンスを改善するために設計されました。このメカニズムは、エンドユーザーのビデオ会議端末と出荷製品のサーバーを会議する両方の両方で使用されています。このドキュメントは現在の方法について説明しますが、レガシーシステムとの逆方向の互換性を除き、新しい実装はこの方法の使用を阻止します。出荷製品と新製品は、[7]に記載されている完全なリクエストを使用する必要があります。
Sending video fast update using the SIP signaling path, as described in this document, is inferior to using the RTP Control Protocol (RTCP) feedback method [7], since the command flows through all the proxies in the signaling path adding delay to the messages and causing unnecessary overload to the proxies. RTCP messages flow end-to-end and not through the signaling proxies. The RTCP feedback document [7] also adds other required control functions, such as the flow control command, which is missing from this document.
このドキュメントで説明されているように、SIPシグナリングパスを使用してビデオ高速更新を送信することは、RTPコントロールプロトコル（RTCP）フィードバック方法[7]を使用することよりも劣っています。プロキシに不必要な過負荷を引き起こします。RTCPメッセージは、シグナリングプロキシを介してではなく、エンドツーエンドでフローします。RTCPフィードバックドキュメント[7]は、このドキュメントに欠落しているフロー制御コマンドなど、他の必要な制御機能も追加します。
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 [2].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2]に記載されているように解釈される。
SIP typically uses the Real-time Transport Protocol (RTP) [6] for the transferring of real-time media.
SIPは通常、リアルタイムメディアの転送にリアルタイムトランスポートプロトコル（RTP）[6]を使用します。
RTP is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks. The RTCP feedback mechanism [8] has been introduced in order to improve basic RTCP feedback time in case of loss conditions across different coding schemes. This technique addresses signaling of loss conditions and the recommended recovery steps.
RTPは、コントロールプロトコル（RTCP）によって拡張され、大規模なマルチキャストネットワークがスケーラブルでスケーラブルでデータ配信を監視できるようにします。RTCPフィードバックメカニズム[8]は、異なるコーディングスキームにわたって損失条件の場合に基本的なRTCPフィードバック時間を改善するために導入されています。この手法は、損失条件のシグナル伝達と推奨される回復ステップに対処します。
Just recently, an extension to the feedback mechanism has been proposed [7] to express control operations on media streams as a result of application logic rather than a result of loss conditions. Note that in the decomposed systems, the implementation of the new mechanism will require proprietary communications between the applications/call control components and the media components.
つい最近では、損失条件の結果ではなく、アプリケーションロジックの結果としてメディアストリームの制御操作を表現するために、フィードバックメカニズムの拡張が提案されています[7]。分解されたシステムでは、新しいメカニズムの実装には、アプリケーション/コール制御コンポーネントとメディアコンポーネントの間の独自の通信が必要になることに注意してください。
This document describes a technology that has been deployed in SIP-based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. This memo documents this technology for the purpose of describing current practice and new implementation MUST use the RTCP Full Intra Request command specified in the RTCP-based codec control messages document[7].
このドキュメントでは、過去3年間にSIPベースのシステムで展開され、さまざまなベンダーからのリアルタイムインタラクティブアプリケーション全体で相互運用可能な方法で使用されている技術について説明しています。このメモは、現在の実践と新しい実装を記述する目的でこのテクノロジーを文書化する必要があります。RTCPベースのコーデックコントロールメッセージドキュメントで指定されたRTCPフルリクエストコマンドを使用する必要があります[7]。
Output of a video codec is a frame. The frame can carry complete information about a picture or about a picture segment. These frames are known as "Intra" frames. In order to save bandwidth, other frames can carry only changes relative to previously sent frames. Frames carrying relative information are known as "Inter" frames.
ビデオコーデックの出力はフレームです。フレームは、写真または写真セグメントに関する完全な情報を運ぶことができます。これらのフレームは「イントラ」フレームとして知られています。帯域幅を保存するために、他のフレームは、以前に送信されたフレームと比較して変更のみを運ぶことができます。相対情報を運ぶフレームは、「inter」フレームとして知られています。
Based on application logic (such as need to present a new video source), the application needs to have an ability to explicitly request from a remote encoder the complete information about a "full" picture.
アプリケーションロジック（新しいビデオソースを提示する必要があるなど）に基づいて、アプリケーションには、リモートエンコーダーから「完全な」画像に関する完全な情報を明示的に要求する機能が必要です。
An "Intra" frame may be of large size. In order to prevent causing network congestion, the current media capacity and network conditions MUST be validated before sending an "Intra" frame when receiving a fast update command, defined in this document.
「イントラ」フレームのサイズは大きい場合があります。ネットワークの輻輳の原因を防ぐために、このドキュメントで定義されている高速更新コマンドを受信するときに、「イントラ」フレームを送信する前に、現在のメディア容量とネットワーク条件を検証する必要があります。
In order to meet the presented requirements, a video primitive is defined by this document.
提示された要件を満たすために、ビデオプリミティブがこのドキュメントで定義されます。
The following command is sent to the remote encoder:
次のコマンドがリモートエンコーダーに送信されます。
o Video Picture Fast Update
o ビデオ画像高速更新
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="TightMediaControl"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="media_control">
<xs:complexType>
<xs:sequence>
<xs:element name="vc_primitive"
type="vc_primitive"
minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="general_error"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Video control primitive. -->
<xs:complexType name="vc_primitive">
<xs:sequence>
<xs:element name="to_encoder" type="to_encoder" />
<xs:element name="stream_id"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- Encoder Command: Picture Fast Update -->
<！ - エンコーダーコマンド：画像高速更新 - >
<xs:complexType name="to_encoder">
<xs:choice>
<xs:element name="picture_fast_update"/>
</xs:choice>
</xs:complexType>
</xs:schema>
Currently, only a single general error primitive is defined. It MAY be used for indicating errors in free-text format. The general error primitive MAY report problems regarding XML document parsing, inadequate level of media control support, inability to perform the requested action, etc.
現在、単一の一般的なエラー原始のみが定義されています。フリーテキスト形式のエラーを示すために使用できます。一般的なエラー原始は、XMLドキュメントの解析、メディア制御サポートの不十分なレベル、要求されたアクションを実行できないなどに関する問題を報告する場合があります。
The general error primitive MUST NOT be used for the indication of errors other than those related to media control parsing or to resultant execution. The general error primitive MUST NOT be sent back as a result of getting an error primitive.
一般的なエラー原始は、メディア制御の解析や結果としての実行に関連するエラー以外のエラーの表示に使用してはなりません。一般的なエラー原始は、エラー原始を取得した結果、送り返さないでください。
When receiving the general error response, the user agent client (UAC) that sent the request SHOULD NOT send further fast update requests in the current dialog.
一般的なエラー応答を受信するとき、リクエストを送信したユーザーエージェントクライアント（UAC）は、現在のダイアログでさらに高速更新リクエストを送信してはなりません。
According to RFC 2976 [3], the only allowable final response to a SIP INFO containing a message body is a 200 OK. If SIP INFO is used to carry the request, the error message should be carried in a separate INFO request.
RFC 2976 [3]によると、メッセージ本文を含むSIP情報に対する唯一の許容最終応答は200 OKです。SIP情報を使用してリクエストを実行する場合、エラーメッセージを別の情報リクエストで携帯する必要があります。
In the following example, the full picture "Fast Update" command is issued towards the remote video decoder(s).
次の例では、リモートビデオデコーダーに向けて「高速更新」コマンド全体が発行されます。
<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update/>
</to_encoder>
</vc_primitive>
</media_control>
</media_control>
If an error occurs during the parsing of the XML document, the following XML document would be sent back to the originator of the original Media Control document.
XMLドキュメントの解析中にエラーが発生した場合、次のXMLドキュメントが元のMedia Controlドキュメントのオリジネーターに送信されます。
<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<media_control>
<general_error>
Parsing error: The original XML segment is:...
</general_error>
</media_control>
</media_control>
The defined XML document is conveyed using the SIP INFO method [3] with the "Content-Type" set to "application/media_control+xml". This approach benefits from the SIP built-in reliability.
定義されたXMLドキュメントは、「Application/Media_Control XML」に設定された「コンテンツタイプ」を使用して、SIP情報メソッド[3]を使用して伝達されます。このアプローチは、SIP組み込みの信頼性の恩恵を受けます。
This document registers a new media type.
このドキュメントは、新しいメディアタイプを登録します。
Type name: application Subtype name: media_control+xml Required parameters: None Optional parameters: charset
タイプ名：アプリケーションサブタイプ名：media_control xml必要パラメーター：なしオプションパラメーター：charset
Indicates the character encoding of enclosed XML.
囲まれたXMLの文字エンコードを示します。
Encoding considerations: 8bit Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [4], Section 3.2.
エンコーディングの考慮事項：8ビットは、使用される文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。RFC 3023 [4]、セクション3.2を参照してください。
Security considerations: Security considerations specific to uses of this type are discussed in RFC 5168. RFC 1874 [1] and RFC 3023 [4] discuss security issues common to all uses of XML.
セキュリティ上の考慮事項：このタイプの用途に固有のセキュリティ上の考慮事項は、RFC 5168で説明されています。RFC1874[1]およびRFC 3023 [4]は、XMLのすべての用途に共通するセキュリティ問題を議論しています。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Published specification: RFC 5168 Applications that use this media type: This media type is used to convey information regarding media control commands and responses between SIP endpoints particularly for allowing a Video Fast Update intra-frame request.
公開された仕様：このメディアタイプを使用するRFC 5168アプリケーション：このメディアタイプは、メディア制御コマンドに関する情報とSIPエンドポイント間の応答に関する情報を伝達するために使用されます。
Additional information:
追加情報：
Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None.
マジックナンバー：なし。ファイル拡張子：なし。Macintoshファイルタイプコード：なし。
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Name: Roni Even E-Mail: even.roni@gmail.com
名前：roni ven email：veven.roni@gmail.com
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None.
使用に関する制限：なし。
Author: Roni Even. <even.roni@gmail.com>
Change Controller: Roni Even. <even.roni@gmail.com>
The video control command transported using the method described in the document may cause the sender of the video data to send more data within the allowed bandwidth, as described in Section 4.
ドキュメントで説明されているメソッドを使用して輸送されたビデオコントロールコマンドは、ビデオデータの送信者に、セクション4で説明されているように、許可された帯域幅内でより多くのデータを送信する可能性があります。
This document defines one control message; changing the content of the message will cause the video sender to ignore the request and send an error response. This may prevent the display of a video stream. The control message itself does not carry any sensitive information.
このドキュメントは、1つのコントロールメッセージを定義します。メッセージの内容を変更すると、ビデオ送信者はリクエストを無視し、エラー応答を送信します。これにより、ビデオストリームの表示が妨げられる可能性があります。コントロールメッセージ自体には、機密情報が含まれていません。
An eavesdropper may inject messages or change them, which may lead to either more data on the network or loss of video image. Using data integrity validation will prevent adding or changing of messages.
盗聴者はメッセージを挿入したり、それらを変更したりする場合があります。これにより、ネットワーク上のより多くのデータまたはビデオ画像の喪失につながる可能性があります。データの整合性検証を使用すると、メッセージの追加または変更が妨げられます。
If the video media is sent over a secure transport, it is recommended to secure the signaling using TLS as explained in [5]. In most cases, securing the media will require a secure signaling path.
ビデオメディアが安全なトランスポートを介して送信される場合は、[5]で説明されているように、TLSを使用してシグナリングを保護することをお勧めします。ほとんどの場合、メディアを保護するには、安全なシグナリングパスが必要です。
The security considerations of [3] and [5] apply here.
[3]および[5]のセキュリティ上の考慮事項はここに適用されます。
[1] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[1] レビンソン、E。、「SGMLメディアタイプ」、RFC 1874、1995年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[6] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[7] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[7] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きRTPオーディオビジュアルプロファイルのコーデックコントロールメッセージ（AVPF）」、RFC 5104、2008年2月。
[8] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[8] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、2006年7月。
Authors' Addresses
著者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: oritl@microsoft.com
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
Pierre Hagendorf RADVISION 24, Raul Wallenberg St. Tel-Aviv, 69719 Israel
Pierre Hagendorf Radvision 24、Raul Wallenberg St. Tel-Aviv、69719イスラエル
EMail: pierre@radvision.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。