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
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.
このドキュメントは、マイクロソフト、ポリコム、RADVISIONが開発し、複数のベンダーが使用厳密に制御された環境でのビデオ高速更新のための拡張マークアップ言語（XML）スキーマを定義します。この文書では、過去3年間のセッション開始プロトコル（SIP）ベースのシステムで展開されていて、相互運用可能な方法で異なるベンダーからのリアルタイムの対話型アプリケーション間で使用されている方法を説明しています。新しい実装では、下位互換性の目的以外で説明した方法を使用してからがっかりしています。新しい実装は、RTP制御プロトコル（RTCP）チャネルに新しいフル・イントラRequestコマンドを使用する必要があります。
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].
このドキュメントは、マイクロソフト、ポリコム、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シグナリングパスを使用してビデオ高速アップデートを送信する、[7] RTP制御プロトコル（RTCP）フィードバック方法を使用することに劣りますそして、プロキシへの不必要な過負荷の原因となります。 RTCPメッセージは、エンドエンドにしていないシグナリングプロキシを介して流れます。 [7] RTCPフィードバック文書はまた、この文書から欠落しているフロー制御コマンドなどの他の必要な制御機能を付加します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
SIP typically uses the Real-time Transport Protocol (RTP) [6] for the transferring of real-time media.
SIPは、一般的にリアルタイムメディアの転送のために[6]リアルタイムトランスポートプロトコル（RTP）を使用しています。
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.
ビデオコーデックの出力は、フレームです。フレームピクチャについて又は画像セグメントに関する完全な情報を運ぶことができます。これらのフレームは、「イントラ」フレームとして知られています。帯域幅を節約するために、他のフレームは、以前に送られたフレームに対する変更を運ぶことができます。相対的な情報を運ぶフレームは、「インター」フレームとして知られています。
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" ?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<xs:schema id="TightMediaControl" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<XS：スキーマID = "TightMediaControl" のelementFormDefault = "資格" の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>
<XS：complexTypeの名前= "vc_primitive"> <XS：配列> <XS：要素名= "to_encoder" タイプ= "to_encoder" /> <XS：要素名= "のstream_id" タイプ= "XS：文字列" のminOccurs =」 0" のmaxOccurs = "無制限" /> </ XS：配列> </ 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：complexTypeの名前= "to_encoder"> <XS：選択> <XS：要素名= "picture_fast_update" /> </ XS：選択> </ XS：complexTypeの>
</xs:schema>
</ XS：スキーマ>
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 INFOにのみ許容される最終応答は、200 OKです。 SIP INFOリクエストを搬送するために使用される場合、エラーメッセージが別INFO要求で実施すべきです。
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" ?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<media_control>
<Media_control>
<vc_primitive> <to_encoder> <picture_fast_update/> </to_encoder> </vc_primitive>
<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文書は、元のメディアコントロール文書の発信元に送り返されます。
<?xml version="1.0" encoding="utf-8" ?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<media_control>
<Media_control>
<general_error> Parsing error: The original XML segment is:... </general_error>
<GENERAL_ERROR>解析エラーは：元のXMLセグメントである：... </ 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文書は、「アプリケーション/ media_control + XML」に設定された「コンテンツタイプ」と[3] SIP INFO法を用いて搬送されます。 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の必須パラメータ：なしオプションのパラメータ：文字セット
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.
エンコードの考慮事項：8bitが使用される文字エンコーディングに応じて、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.
セキュリティの考慮事項：この種の用途に固有のセキュリティ上の考慮事項は、[1]およびRFC 3023 [4] XMLのすべての使用に共通のセキュリティ上の問題を議論するRFC 5168. RFC 1874で説明されています。
Interoperability considerations: None.
相互運用性に関する注意事項：なし。
Published specification: RFC 5168
公開された仕様：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.
このメディアタイプは、特にビデオ高速アップデートイントラフレーム要求を可能にするためのSIPエンドポイント間のメディア制御コマンドと応答に関する情報を伝えるために使用されます。このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None.
マジックナンバー（S）：なし。拡張（複数可）ファイル：なし。 Macintoshのファイルタイプコード（S）：なし。
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Name: Roni Even E-Mail: even.roni@gmail.com
名前：ロニでもEメール：even.roni@gmail.com
Intended usage: LIMITED USE
意図している用法：限定使用
Restrictions on usage: None.
使用に関する制限：なし。
Author: Roni Even. <even.roni@gmail.com>
著者：ロニでも。 <even.roni@gmail.com>
Change Controller: Roni Even. <even.roni@gmail.com>
でもローニ：コントローラーを変更します。 <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.
この文書では、一つの制御メッセージを定義します。メッセージの内容を変更する要求を無視し、エラー応答を送信する映像送信が発生します。これは、ビデオストリームの表示を防ぐことができます。制御メッセージ自体は、機密情報を運ぶことはありません。
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.
ビデオメディアがセキュアトランスポートを介して送信される場合、それはで説明したようにTLSを使用してシグナリングを確保することが推奨される[5]。ほとんどの場合、メディアの確保がセキュアなシグナリングパスが必要になります。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.、フレデリック、R.、およびV.ヤコブソン、 "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]ウェンガー、S.、チャンドラ、U.、ウェスター、M.、およびB.ビルマ、RFC 5104、2008年2月 "フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）におけるコーデック制御メッセージを"。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、「リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル-Basedフィードバック（RTP / AVPF） 」、RFC 4585、2006年7月。
Authors' Addresses
著者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
oriTレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: oritl@microsoft.com
メールアドレス：oritl@microsoft.com
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
Pierre Hagendorf RADVISION 24, Raul Wallenberg St. Tel-Aviv, 69719 Israel
ピエールHagendorf RADVISION 24、ラウル・ワレンバーグ聖テルアビブ、イスラエル69719
EMail: pierre@radvision.com
メールアドレス：pierre@radvision.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。