Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6230 NS-Technologies
Category: Standards Track T. Melanchuk
ISSN: 2070-1721 Rainwillow
S. McGlashan
Hewlett-Packard
May 2011
Media Control Channel Framework
Abstract
抽象
This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.
この文書では、アプリケーション・プログラミング・ロジックとメディア処理が分散されているアプリケーションの展開のためのフレームワークおよびプロトコルを記述しています。これは、アプリケーション・プログラミング・ロジックがシームレスに同じ物理ネットワークエンティティ上の同じ場所に配置されていない適切なリソースにアクセスできることを意味します。フレームワークは、アプリケーションサーバと、メディアサーバなどの関連外部サーバとの間のアプリケーションレベルの制御メカニズムを確立するためにセッション開始プロトコル（SIP）を使用します。
The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope.
このフレームワークを作成するための動機は、IETFでXCONワーキンググループによって定義されるような会議システムは、分散させることができる集中型会議システムの要件を満たすのに適したインターフェースを提供することです。しかし、この範囲に限定されるものではありません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6230.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6230で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behavior for Constructing Requests . . . . . . . . 17
6.2. General Behavior for Constructing Responses . . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
12.3. Control Channel Policy Management . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. Control Packages Registration Information . . . . . . . . 38
13.1.1. Control Package Registration Template . . . . . . . . 39
13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
13.4. Control Framework Header Fields . . . . . . . . . . . . . 40
13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
13.6.1. Registration of MIME Media Type application/cfw . . . 41
13.6.2. Registration of MIME Media Type
application/framework-attributes+xml . . . . . . . . . 42
13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 43
13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 43
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Common Package Components . . . . . . . . . . . . . . 47
A.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 47
Real-time media applications are often developed using an architecture where the application logic and media processing activities are distributed. Commonly, the application logic runs on "application servers", but the processing runs on external servers, such as "media servers". This document focuses on the framework and protocol between the application server and external processing server. The motivation for this framework comes from a set of requirements for Media Server Control, which can be found in "Media Server Control Protocol Requirements" [RFC5167]. While the Framework is not specific to media server control, it is the primary driver and use case for this work. It is intended that the framework contained in this document be able to be used for a variety of device control scenarios (for example, conference control).
リアルタイムメディアアプリケーションは、多くの場合、アプリケーション・ロジックとメディア処理活動が分散されているアーキテクチャを使用して開発されています。一般的に、アプリケーション・ロジックは、「アプリケーションサーバー」上で動作しますが、処理は、このような「メディアサーバー」などの外部のサーバ上で動作します。この文書では、アプリケーションサーバと外部の処理サーバとの間のフレームワークおよびプロトコルに焦点を当てています。このフレームワークのための動機は、「メディアサーバー制御プロトコルの要件」[RFC5167]で見ることができるメディアサーバ制御のための要件のセットから来ています。フレームワークは、メディアサーバーコントロールに固有のものではないが、それがこの作品の主なドライバーとユースケースです。なお、この文書に含まれているフレームワークは、デバイス制御のシナリオ（例えば、会議コントロール）の種々のために使用することができることが意図されます。
This document does not define a particular SIP extension for the direct control of external components. Rather, other documents, known as "Control Packages", extend the Control Framework described by this document. Section 8 provides a comprehensive set of guidelines for creating such Control Packages.
この文書では、外部コンポーネントを直接制御するための特定のSIP拡張機能を定義していません。むしろ、「コントロールパッケージ」として知られている他の文書は、この文書で説明したコントロールフレームワークを拡張します。第8節は、このような制御パッケージを作成するためのガイドラインの包括的なセットを提供します。
Current IETF device control protocols, such as Megaco [RFC5125], while excellent for controlling media gateways that bridge separate networks, are troublesome for supporting media-rich applications in SIP networks. This is because Megaco duplicates many of the functions inherent in SIP. Rather than using a single protocol for session establishment and application media processing, application developers need to translate between two separate mechanisms. Moreover, the model provided by the framework presented here, using SIP, better matches the application programming model than does Megaco.
例えばMegacoのような現在のIETFデバイス制御プロトコル、[RFC5125]は、別々のネットワークをブリッジメディアゲートウェイを制御するための優れながら、SIPネットワークにおけるメディアリッチアプリケーションをサポートするため煩雑です。 Megacoのは、SIPに固有の機能の多くを複製するためです。むしろセッション確立およびアプリケーションメディア処理のための単一のプロトコルを使用するよりも、アプリケーション開発者は、2つの別個の機構の間で変換する必要があります。また、フレームワークによって提供されるモデルは、SIP、よりよいマッチのMegacoの場合よりも、アプリケーション・プログラミング・モデルを使用して、ここに提示しました。
SIP [RFC3261] provides the ideal rendezvous mechanism for establishing and maintaining control connections to external server components. The control connections can then be used to exchange explicit command/response interactions that allow for media control and associated command response results.
SIP [RFC3261]は、外部サーバコンポーネントへの制御接続を確立し、維持するための理想的なランデブーメカニズムを提供します。制御接続は、メディア制御及び関連コマンド応答の結果を可能にする明示的なコマンド/レスポンス相互作用を交換するために使用することができます。
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 BCP 14, [RFC2119], as scoped to those conformance targets.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように、それらの適合性ターゲットを対象として、解釈されます。
The following additional terms are defined for use in this document:
以下の追加条件は、本文書で使用するために定義されています。
User Agent Client (UAC): As specified in [RFC3261].
ユーザエージェントクライアント（UAC）：[RFC3261]で指定されているように。
User Agent Server (UAS): As specified in [RFC3261].
ユーザエージェントサーバ（UAS）：[RFC3261]で指定されているように。
B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
B2BUA：B2BUAは、バックツーバックのSIPユーザエージェントです。
Control Server: A Control Server is an entity that performs a service, such as media processing, on behalf of a Control Client. For example, a media server offers mixing, announcement, tone detection and generation, and play and record services. The Control Server has a direct Real-Time Transport Protocol (RTP) [RFC3550] relationship with the source or sink of the media flow. In this document, we often refer to the Control Server simply as "the Server".
制御サーバ：制御サーバは、制御クライアントに代わって、そのようなメディア処理として、サービスを実行するエンティティです。例えば、メディアサーバは、混合、発表、トーン検出と生成、および再生および録音サービスを提供しています。コントロールサーバは、直接リアルタイムトランスポートプロトコル（RTP）メディアフローのソースまたはシンクと[RFC3550]の関係を持っています。この文書では、私たちはしばしば単に「サーバ」としてコントロール・サーバーを参照してください。
Control Client: A Control Client is an entity that requests processing from a Control Server. Note that the Control Client might not have any processing capabilities whatsoever. For example, the Control Client may be an application server (B2BUA) or other endpoint requesting manipulation of a third party's media stream that terminates on a media server acting in the role of a Control Server. In this document, we often refer to the Control Client simply as "the Client".
コントロールクライアント：コントロールクライアントは、コントロール・サーバーから処理を依頼するエンティティです。コントロールクライアントは、いかなる処理能力を持っていない可能性がありますので注意してください。例えば、クライアントの制御は、制御サーバの役割で行動するメディアサーバー上で終端し、第三者のメディアストリームの操作を要求するアプリケーションサーバ（B2BUA）または他のエンドポイントかもしれません。この文書では、私たちはしばしば、単に「クライアント」としてコントロールクライアントを参照してください。
Control Channel: A Control Channel is a reliable connection between a Client and Server that is used to exchange Framework messages. The term "Connection" is used synonymously within this document.
制御チャネル：制御チャネルは、フレームワークのメッセージを交換するために使用され、クライアントとサーバー間の確実な接続です。用語「接続」は、本文書内同義語として使用されます。
Framework Message: A Framework message is a message on a Control Channel that has a type corresponding to one of the Methods defined in this document. A Framework message is often referred to by its method, such as a "CONTROL message".
フレームワークのメッセージ：フレームワークメッセージは、この文書で定義されたメソッドの1つに対応する型を持つ制御チャネル上のメッセージです。フレームワークメッセージは、多くの場合、「制御メッセージ」として、その方法によって参照されます。
Method: A Method is the type of a Framework message. Four Methods are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
方法：この方法は、フレームワークメッセージのタイプです。 4つの方法は、この文書で定義されています：SYNC、CONTROL、REPORT、およびK-ALIVEを。
Control Command: A Control Command is an application-level request from a Client to a Server. Control Commands are carried in the body of CONTROL messages. Control Commands are defined in separate specifications known as "Control Packages".
制御コマンド：制御コマンドは、クライアントからサーバーへのアプリケーションレベルの要求です。制御コマンドは制御メッセージのボディに搭載されています。制御コマンドは、「コントロールパッケージ」として知られている別の仕様で定義されています。
Framework Transaction: A Framework Transaction is defined as a sequence composed of a Control Framework message originated by either a Control Client or Control Server and responded to with a Control Framework response code message. Note that the Control Framework has no "provisional" responses. A Control Framework transaction is referenced throughout the document as a 'Transaction-Timeout'.
フレームワークトランザクション：フレームワークのトランザクションがコントロールフレームワークのメッセージ管理クライアントまたは制御サーバーのいずれかによって発信され、コントロールフレームワーク応答コードメッセージによって応答からなる配列として定義されます。コントロールフレームワークがない「暫定」応答がないことに注意してください。コントロールフレームワークのトランザクションは、「トランザクションタイムアウト」として文書全体で参照されます。
Transaction-Timeout: The maximum allowed time between a Control Client or Server issuing a Framework message and it arriving at the destination. The value for 'Transaction-Timeout' is 10 seconds.
トランザクション・タイムアウト：コントロールクライアントまたはサーバがフレームワークのメッセージを発行し、それが目的地に到着する間の最大許容時間。 「トランザクション・タイムアウト」の値は10秒です。
This document details mechanisms for establishing, using, and terminating a reliable transport connection channel using SIP and the Session Description Protocol offer/answer [RFC3264] exchange. The established connection is then used for controlling an external server. The following text provides a non-normative overview of the mechanisms used. Detailed, normative guidelines are provided later in the document.
この文書では、確立し使用して、およびSIPおよびセッション記述プロトコル・オファー/アンサー[RFC3264]の交換を使用して、信頼性の高いトランスポート接続チャネルを終了するためのメカニズムを詳しく説明します。確立された接続は、外部のサーバを制御するために使用されます。次のテキストが使用されるメカニズムの非規範的な概要を提供します。詳細は、規範的なガイドラインは、文書の後半で提供されています。
Control Channels are negotiated using standard SIP mechanisms that would be used in a similar manner to creating a SIP multimedia session. Figure 1 illustrates a simplified view of the mechanism. It highlights a separation of the SIP signaling traffic and the associated Control Channel that is established as a result of the SIP interactions.
制御チャネルはSIPマルチメディアセッションの作成と同様の方法で使用される標準のSIPメカニズムを使用してネゴシエートされます。図1は、機構の簡略図を示します。これは、SIPの相互作用の結果として確立されているSIPシグナリングトラフィックおよび関連する制御チャネルの分離を強調しています。
Initial analysis into the Control Framework, as documented in [MSCL-THOUGHTS], established the following. One might ask, "If all we are doing is establishing a TCP connection to control the media server, why do we need SIP?" This is a reasonable question. The key is that we use SIP for media session establishment. If we are using SIP for media session establishment, then we need to ensure the URI used for session establishment resolves to the same node as the node for session control. Using the SIP routing mechanism, and having the server initiate the TCP connection back, ensures this works. For example, the URI sip:myserver.example.com may resolve to sip: server21.farm12.northeast.example.net, whereas the URI http://myserver.example.com may resolve to http://server41.httpfarm.central.example.net. That is, the host part is not necessarily unambiguous.
コントロールフレームワークへの初期分析は、[MSCL-THOUGHTS]に記載されているように、次のように確立しました。一つは、「私たちはSIP必要か、なぜ、我々がやっているすべてのメディアサーバーを制御するために、TCPコネクションを確立している場合は？」と尋ねるかもしれませんこれは、合理的な質問です。キーは、私たちがメディアセッション確立のためのSIPを使用することです。私たちは、メディアセッション確立のためのSIPを使用している場合は、次に我々は、セッション制御用ノードと同じノードに解決URIは、セッション確立のために使用を確認する必要があります。 SIPルーティング機構を使用して、サーバを有するバックTCP接続を開始し、この動作を確実にします。例えば、URIのSIP：myserver.example.comは一口に解決されることがあります。server21.farm12.northeast.example.net、URI http://myserver.example.comがHTTPに解決する場合がある：//server41.httpfarm。 central.example.net。つまり、ホスト部分は、必ずしも明確なではありません。
The use of SIP to negotiate the Control Channel provides many inherent capabilities, which include:
制御チャネルを交渉するためにSIPを使用するには、多くの固有の機能を提供します：
o Service location - Use SIP Proxies and Back-to-Back User Agents for locating Control Servers.
Oサービスの場所 - 使用SIPプロキシおよびコントロール・サーバーを見つけるためのバックツーバックユーザエージェント。
o Security mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication.
Oセキュリティ・メカニズム - などトランスポート層セキュリティ（TLS）およびクライアント認証として活用確立されたセキュリティ・メカニズム。
o Connection maintenance - The ability to re-negotiate a connection, ensure it is active, and so forth.
O接続メンテナンス - 、接続を再ネゴシエート等がアクティブであることを確認し、そしてする能力。
o Application agnostic - Generic protocol allows for easy extension.
Oとらわれないアプリケーション - 一般的なプロトコルは、簡単に拡張することができます。
As mentioned in the previous list, one of the main benefits of using SIP as the session control protocol is the "Service Location" facilities provided. This applies both at a routing level, where [RFC3263] provides the physical location of devices, and at the service level, using Caller Preferences [RFC3840] and Callee Capabilities [RFC3841]. The ability to select a Control Server based on service-level capabilities is extremely powerful when considering a distributed, clustered architecture containing varying services (for example, voice, video, IM). More detail on locating Control Server resources using these techniques is outlined in Section 4.1 of this document.
前のリストで述べたように、セッション制御プロトコルとしてSIPを使用することの主な利点の一つは、提供された「サービスロケーション」の施設です。これは、両方の[RFC3263]は発信者のプリファレンス[RFC3840]と呼び出し先機能[RFC3841]を使用して、物理デバイスの位置、およびサービスレベルを提供するルーティング・レベルで適用されます。様々なサービス（例えば、音声、ビデオ、IM）を含む分散型、クラスタ化されたアーキテクチャを検討する際に、サービスレベルの機能に基づいてコントロール・サーバーを選択する機能は非常に強力です。これらの技術を使用して制御サーバーリソースを見つけるの詳細は、このドキュメントのセクション4.1に概説されています。
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
図1：基本アーキテクチャ
The example from Figure 1 conveys a 1:1 connection between the Control Client and the Control Server. It is possible, if required, for the client to request multiple Control Channels using separate SIP INVITE dialogs between the Control Client and the Control Server entities. Any of the connections created between the two entities can then be used for Server control interactions. The control connections are orthogonal to any given media session. Specific media session information is incorporated in control interaction commands, which themselves are defined in external packages, using the XML schema defined in Appendix A. The ability to have multiple Control Channels allows for stronger redundancy and the ability to manage high volumes of traffic in busy systems.
コントロールクライアントと制御サーバーとの間の1接続：図1の例では、1を搬送します。必要であれば、クライアントはコントロールクライアントおよびコントロール・サーバー・エンティティ間のダイアログをINVITE別のSIPを使用して、複数の制御チャネルを要求することは、可能です。 2つのエンティティ間で作成された接続のいずれかが、[サーバーコントロールの相互作用のために使用することができます。制御接続は、任意のメディアセッションに直交しています。特定のメディアセッション情報は、複数の制御チャネルを有する能力が強く、冗長性と忙しい中で大量のトラフィックを管理する能力を可能にし、付録Aで定義されたXMLスキーマを使用して、自分自身が外部のパッケージで定義されているコントロールの対話コマンド、中に組み込まれていますシステム。
Consider the following simple example for session establishment between a Client and a Server. (Note: Some lines in the examples are removed for clarity and brevity.) Note that the roles discussed are logical and can change during a session, if the Control Package allows.
クライアントとサーバーの間のセッションを確立するため、次の簡単な例を考えてみましょう。 （注：例のいくつかのラインは明瞭かつ簡潔にするために除去される。）で考察ロールは論理的制御パッケージが許可されている場合、セッション中に変更することができることに留意されたいです。
The Client constructs and sends a standard SIP INVITE request, as defined in [RFC3261], to the external Server. The Session Description Protocol (SDP) payload includes the required information for Control Channel negotiation and is the primary mechanism for conveying support for this specification. The application/cfw MIME type is defined in this document to convey the appropriate SDP format for compliance to this specification. The Connection-Oriented Media (COMEDIA) [RFC4145] specification for setting up and maintaining reliable connections is used as part of the negotiation mechanism (more detail available in later sections). The Client also includes the 'cfw-id' SDP attribute, as defined in this specification, which is a unique identifier used to correlate the underlying Media Control Channel with the offer/answer exchange.
クライアントの構築と外部サーバに、[RFC3261]で定義されるような標準的なSIPは、INVITE要求を送信します。セッション記述プロトコル（SDP）ペイロードは、制御チャネルのネゴシエーションのために必要な情報が含まれており、本明細書のサポートを搬送するための主要なメカニズムです。アプリケーション/ CFWのMIMEタイプはこの仕様に準拠するために適切なSDPフォーマットを伝達するために、この文書で定義されています。セットアップおよび信頼性のある接続を維持する接続指向メディア（COMEDIA）[RFC4145]仕様は、ネゴシエーションメカニズム（後のセクションで利用可能詳細）の一部として使用されます。オファー/アンサー交換で基本となるメディア制御チャネルを相関させるために使用される一意の識別子であり、この仕様で定義されているクライアントはまた、「CFW-ID」SDP属性を含んでいます。
Client Sends to External Server:
クライアントが外部サーバに送信します：
INVITE sip:External-Server@example.com SIP/2.0 To: <sip:External-Server@example.com> From: <sip:Client@example.com>;tag=64823746 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d Call-ID: 7823987HJHG6 Max-Forwards: 70 CSeq: 1 INVITE Contact: <sip:Client@clientmachine.example.com> Content-Type: application/sdp Content-Length: [..]
：<External-Server@example.com SIP：>：にExternal-Server@example.com SIP / 2.0：SIPのINVITE <一口：Client@example.com>;タグ= 64823746経由：SIP / 2.0 / UDPクライアント。 example.com;ブランチ= z9hG4bK72dのCall-ID：7823987HJHG6マックス・フォワード：70のCSeq：1連絡先をINVITE：<SIP：Client@clientmachine.example.com>のContent-Type：アプリケーション/ SDPのContent-Length：[..]
v=0 o=originator 2890844526 2890842808 IN IP4 controller.example.com s=- c=IN IP4 controller.example.com m=application 49153 TCP cfw a=setup:active a=connection:new a=cfw-id:H839quwhjdhegvdga
アクティブA =接続：新A = CFW-ID：H839quwhjdhegvdga =セットアップC = IN IP4 controller.example.com M =アプリケーション49153 TCPのCFWのA - IP4 controller.example.com S = IN V = 0 0 =発信2890844526 2890842808
On receiving the INVITE request, an external Server supporting this mechanism generates a 200 OK response containing appropriate SDP and formatted using the application/cfw MIME type specified in this document. The Server inserts its own unique 'cfw-id' SDP attribute, which differs from the one received in the INVITE (offer).
INVITE要求を受信すると、このメカニズムをサポートする外部サーバは、適切なSDPこの文書で指定されたアプリケーション/ CFWのMIMEタイプを使用してフォーマットを含む200 OK応答を生成します。サーバーは、INVITE（申し出）で受信されたものとは異なる独自の「CFW-ID」SDP属性を、挿入されます。
External Server Sends to Client:
外部サーバがクライアントに送信します：
SIP/2.0 200 OK To: <sip:External-Server@example.com>;tag=28943879 From: <sip:Client@example.com>;tag=64823746 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4
SIP / 2.0 200 OKに：<SIP：External-Server@example.com>;タグ= 28943879から：<SIP：Client@example.com>;タグ= 64823746経由：SIP / 2.0 / UDP client.example.com。ブランチ= z9hG4bK72d;受け取ら= 192.0.2.4
Call-ID: 7823987HJHG6 CSeq: 1 INVITE Contact: <sip:External-Server@servermachine.example.com> Content-Type: application/sdp Content-Length: [..]
コールIDを：7823987HJHG6のCSeq：1連絡先をINVITE：<SIP：External-Server@servermachine.example.com>のContent-Type：アプリケーション/ SDPのContent-Length：[..]
v=0 o=responder 2890844526 2890842808 IN IP4 server.example.com s=- c=IN IP4 mserver.example.com m=application 7563 TCP cfw a=setup:passive a=connection:new a=cfw-id:U8dh7UHDushsdu32uha
V = 0 0 =レスポンダ2890844526 2890842808 IN IP4 server.example.com S = - C = IN IP4 mserver.example.com M =アプリケーション7563 TCPのCFWのA =セットアップ：受動A =接続：新しいA = CFW-ID：U8dh7UHDushsdu32uha
The Control Client receives the SIP 200 OK response and extracts the relevant information (also sending a SIP ACK). It creates an outgoing (as specified by the SDP 'setup' attribute of 'active') TCP connection to the Control Server. The connection address (taken from 'c=') and port (taken from 'm=') are used to identify the remote port in the new connection.
コントロールクライアントは、SIP 200 OK応答を受信し（またSIP ACKを送信する）関連情報を抽出します。これは、コントロール・サーバーへのTCP接続の発信（「アクティブ」のSDP「セットアップ」で指定された属性）を作成します。接続（「C =」から採取）アドレス及び（M「=」から取った）ポートは、新しい接続のリモートポートを識別するために使用されます。
Once established, the newly created connection can be used to exchange requests and responses as defined in this document. If required, after the Control Channel has been set up, media sessions can be established using standard SIP Third Party Call Control (3PCC) [RFC3725].
設立後は、新しく作成された接続は、この文書で定義された要求と応答を交換するために使用することができます。必要に応じて制御チャネルが設定された後、メディアセッションは、標準SIP第三者呼制御（3PCC）[RFC3725]を使用して確立することができます。
Figure 2 provides a simplified example where the framework is used to control a User Agent's RTP session.
図2は、フレームワークは、ユーザエージェントのRTPセッションを制御するために使用される単純化した例を提供します。
+--------Control SIP Dialog(1)---------+
| |
v v
+-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack|
| +---+-----+---+ +---+-----+---+
| | | | |
| | Control |<--Control Channel(1)-->| |
| | Client | | Control |
| +-------------+ | Server |
+--+--+ | |
|User | | |
|Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+
Figure 2: Participant Architecture
図2：参加者の建築
The link (1) represents the SIP INVITE dialog usage and dedicated Control Channel previously described in this overview section. The link (2) from Figure 2 represents the User Agent SIP INVITE dialog usage interactions and associated media flow. A User Agent creates a SIP INVITE dialog usage with the Control Client entity. The Control Client entity then creates a SIP INVITE dialog usage to the Control Server, using B2BUA type functionality. Using the interaction illustrated by (2), the Control Client negotiates media capabilities with the Control Server, on behalf of the User Agent, using SIP 3PCC. [RFC3725].
リンクは、（1）ダイアログ使用と以前にこの概要のセクションで説明した専用制御チャネルを、SIP INVITEを表します。図2からのリンク（2）は、ユーザエージェントSIPダイアログ使用の相互作用と関連するメディアフローをINVITE表します。ユーザエージェントは、SIPは、コントロールクライアントエンティティとの対話の使用をINVITE作成します。コントロールクライアントエンティティは、B2BUAタイプの機能を使用して、SIPは、制御サーバへのダイアログの使用をINVITE作成します。 （2）で示される相互作用を使用して、コントロールクライアントは、SIP 3PCCを使用して、ユーザーエージェントに代わって、制御サーバとメディア機能をネゴシエートします。 [RFC3725]。
This section describes the setup, using SIP, of the dedicated Control Channel. Once the Control Channel has been established, commands can be exchanged (as discussed in Section 6).
このセクションでは、専用の制御チャネルのSIPを使用して、セットアップを説明しています。制御チャネルが確立された後（第6節で議論するように）、コマンドを交換することができます。
When a UAC wishes to establish a Control Channel, it MUST construct and transmit a new SIP INVITE request for Control Channel setup. The UAC MUST construct the INVITE request as defined in [RFC3261].
UACは、制御チャネルを確立しようとするとき、それは、制御チャネルのセットアップのためのINVITEリクエストを新しいSIPを構築し、伝えなければなりません。 [RFC3261]で定義されるようにUACは、INVITE要求を構築しなければなりません。
If a reliable response is received (as defined in [RFC3261] and [RFC3262]), the mechanisms defined in this document are applicable to the newly created SIP INVITE dialog usage.
信頼性の応答は（[RFC3261]及び[RFC3262]で定義されるように）受信された場合、この文書で定義されたメカニズムは、ダイアログを使用INVITE新しく作成されたSIPにも適用可能です。
The UAC SHOULD include a valid session description (an 'offer' as defined in [RFC3264]) in an INVITE request using the Session Description Protocol defined in [RFC4566] but MAY choose an offer-less INVITE as per [RFC3261]. The SDP SHOULD be formatted in accordance with the steps below and using the MIME type application/ cfw, which is registered in Section 13. The following information defines the composition of specific elements of the SDP payload the offerer MUST adhere to when used in a SIP-based offer/answer exchange using SDP and the application/cfw MIME type. The SDP being constructed MUST contain only a single occurrence of a Control Channel definition outlined in this specification but can contain other media lines if required.
UACは、[RFC4566]で定義されたセッション記述プロトコルを使用してINVITE要求に有効なセッション記述（[RFC3264]で定義されたとして「提供」）を含むべきであるが、[RFC3261]に従ってINVITEのオファーレスを選ぶかもしれません。 SDPは、以下の手順に従ってフォーマットし、以下の情報がSIPで使用する場合申出がに従う必要がありSDPペイロードの特定元素の組成を定義するセクション13に登録されたMIMEタイプapplication / CFWを使用する必要がありSDPおよびアプリケーション/ CFWのMIMEタイプを使用してベースのオファー/アンサー交換。 SDPは、本明細書で概説制御チャネル定義の単一の発生を含まなければなりませんが、必要に応じて他のメディア行を含むことができる構築されます。
The Connection Data line in the SDP payload is constructed as specified in [RFC4566]:
SDPペイロード内の接続データライン[RFC4566]で指定されるように構成されています。
c=<nettype> <addrtype> <connection-address>
C = <NETTYPE> <ADDRTYPE> <接続アドレス>
The first sub-field, <nettype>, MUST equal the value "IN". The second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The third sub-field for Connection Data is <connection-address>. This supplies a representation of the SDP originator's address, for example, DNS/IP representation. The address is the address used for connections.
最初のサブフィールドは、<NETTYPE>、値「IN」と等しくなければなりません。第2サブフィールド、<ADDRTYPE>、「IP4」または「IP6」のいずれかを等しくなければなりません。接続データの第3のサブフィールドは、<接続アドレス>です。これは、例えば、DNS / IPの表現のために、SDP発信者のアドレスの表現を提供します。アドレスは、接続に使用されるアドレスです。
Example:
例：
c=IN IP4 controller.example.com
C IN = IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry:
SDPは、対応するメディア記述エントリを含まなければなりません：
m=<media> <port> <proto> <fmt>
M = <メディア> <ポート> <プロト> <FMT>
The first "sub-field", <media>, MUST equal the value "application". The second sub-field, <port>, MUST represent a port on which the constructing client can receive an incoming connection if required. The port is used in combination with the address specified in the Connection Data line defined previously to supply connection details. If the entity constructing the SDP can't receive incoming connections, it must still enter a valid port entry. The use of the port value '0' has the same meaning as defined in a SIP offer/answer exchange [RFC3264]. The Control Framework has a default port defined in Section 13.5. This value is default, although a client is free to choose explicit port numbers. However, SDP SHOULD use the default port number, unless local policy prohibits its use. Using the default port number allows network administrators to manage firewall policy for Control Framework interactions. The third sub-field, <proto>, compliant to this specification, MUST support the values "TCP" and "TCP/TLS". Implementations MUST support TLS as a transport-level security mechanism for the Control Channel, although use of TLS in specific deployments is optional. Control Framework implementations MUST support TCP as a transport protocol. When an entity identifies a transport value but is not willing to establish the session, it MUST respond using the appropriate SIP mechanism. The <fmt> sub-field MUST contain the value "cfw".
最初の「サブフィールド」、<メディア>は、値「アプリケーション」に等しくなければなりません。第2サブフィールド、<ポート>は、必要に応じて構成するクライアントが着信接続を受信できるポートを表現しなければなりません。ポートは、接続の詳細を供給するために、以前に定義された接続データラインで指定されたアドレスと組み合わせて使用されます。 SDPを構築するエンティティが着信接続を受信できない場合、それはまだ有効なポートエントリを入力する必要があります。ポート値の使用は「0」SIPのオファー/アンサー交換[RFC3264]で定義されたものと同じ意味を持ちます。コントロールフレームワークは、13.5節で定義されたデフォルトのポートを持っています。クライアントは、明示的なポート番号を選択する自由があるが、この値は、デフォルトです。ローカルポリシーは、その使用を禁止している場合を除きしかし、SDPは、デフォルトのポート番号を使用する必要があります。デフォルトのポート番号を使用すると、ネットワーク管理者がコントロールフレームワークの相互作用のためのファイアウォールポリシーを管理することができます。第3サブフィールド、<プロト>、この仕様に準拠するには、値「TCP」および「TCP / TLS」をサポートしなければなりません。具体的な展開でTLSの使用は任意ですが、実装は、制御チャネルのためのトランスポート・レベルのセキュリティメカニズムとして、TLSをサポートしなければなりません。コントロールフレームワークの実装は、トランスポートプロトコルとしてTCPをサポートしなければなりません。エンティティは、トランスポート値を識別しますが、セッションを確立することを望んでいない場合は、適切なSIPメカニズムを使用して応答しなければなりません。 <FMT>サブフィールドは値「CFW」を含まなければなりません。
The SDP MUST also contain a number of SDP media attributes (a=) that are specifically defined in the COMEDIA [RFC4145] specification. The attributes provide connection negotiation and maintenance parameters. It is RECOMMENDED that a Controlling UAC initiate a connection to an external Server but that an external Server MAY negotiate and initiate a connection using COMEDIA, if network topology prohibits initiating connections in a certain direction. An example of the COMEDIA attributes is:
SDPはまた、具体的COMEDIA [RFC4145]仕様で定義されたSDPメディア属性（=）の数を含まなければなりません。属性は、接続ネゴシエーションと保守パラメータを提供します。制御UACが外部サーバーへの接続を開始することなく、ネットワークトポロジが特定の方向に接続を開始禁止した場合、外部サーバは、交渉とCOMEDIAを使用して接続を開始することができることが推奨されます。 COMEDIAの例がある属性：
a=setup:active
a=connection:new
This example demonstrates a new connection that will be initiated from the owner of the SDP payload. The connection details are contained in the SDP answer received from the UAS. A full example of an SDP payload compliant to this specification can be viewed in Section 3. Once the SDP has been constructed along with the remainder of the SIP INVITE request (as defined in [RFC3261]), it can be sent to the appropriate location. The SIP INVITE dialog usage and appropriate control connection is then established.
この例では、SDPペイロードの所有者から開始される新しい接続を示しています。接続の詳細は、UASから受信したSDPアンサーに含まれています。 SDPは、それが適切な場所に送信することができる（[RFC3261]で定義されるように）SIP INVITE要求の残りの部分と一緒に構築された後、この仕様に準拠SDPペイロードの完全な例は、セクション3に見ることができます。 SIPは、ダイアログの使用を招待し、適切な制御接続はその後、確立されています。
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. The 'cfw-id' attribute indicates an identifier that can be used within the Control Channel to correlate the Control Channel with this SIP INVITE dialog usage. The 'cfw-id' attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/answer exchanges. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange. This applies specifically to the 'connection' attribute as defined in [RFC4145]. If a SIP UAC wants to change some other parts of the SDP but reuse the already established connection, it uses the value of 'existing' in the 'connection' attribute (for example, a=connection:existing). If it has noted that a connection has failed and wants to re-establish the connection, it uses the value of 'new' in the 'connection' attribute (for example, a=connection:new). Throughout this, the connection identifier specified in the 'cfw-id' SDP parameter MUST NOT change. One is simply negotiating the underlying TCP connection between endpoints but always using the same Control Framework session, which is 1:1 for the lifetime of the SIP INVITE dialog usage.
セクション9.2で定義されるようにオファーを構築するSIP UACは、「CFW-ID」SDP属性を含まなければなりません。 「CFW-ID」属性は、ダイアログの使用をINVITEこのSIPで制御チャネルを相関させるために制御チャネル内で使用可能な識別子を示します。 「CFW-ID」属性は、UACとUAS間の相互作用のコンテキスト内で一意である必要があり、他のSIPオファー/アンサー交換に使用される「CFW-ID」のインスタンスと衝突してはなりません。 「CFW-ID」属性のために選択された値は、ダイアログ使用を招待オファー/アンサー交換の更新時に変更されていない関連するSIPの全期間のために使用されなければなりません。 [RFC4145]で定義されたように、これは「接続」属性に特異的に適用されます。 SIP UACは、SDPのいくつかの他の部分を変更するが、すでに確立された接続を再利用したい場合は、「接続」属性での既存の '（：既存例えば、A =接続）の値を使用しています。それは、接続が失敗し、接続を再確立したいと考えていたことを指摘している場合、それは（：新たとえば、A =接続のために）「接続」属性で「新しい」の値を使用しています。このを通じて、「CFW-ID」で指定された接続識別子は、SDPパラメータが変化してはいけません。一つは、単にエンドポイント間の基本的なTCPコネクションを交渉するが、常に1で同じコントロールフレームワークセッション、使用している：ダイアログの使用を、SIP INVITEの存続期間1。
A non-2xx-class final SIP response (3xx, 4xx, 5xx, and 6xx) received for the INVITE request indicates that no SIP INVITE dialog usage has been created and is treated as specified by SIP [RFC3261]. Specifically, support of this specification is negotiated through the presence of the media type defined in this specification. The receipt of a SIP error response such as "488" indicates that the offer contained in a request is not acceptable. The inclusion of the media line associated with this specification in such a rejected offer indicates to the client generating the offer that this could be due to the receiving client not supporting this specification. The client generating the offer MUST act as it would normally on receiving this response, as per [RFC3261]. Media streams can also be rejected by setting the port to "0" in the "m=" line of the session description, as defined in [RFC3264]. A client using this specification MUST be prepared to receive an answer where the "m=" line it inserted for using the Control Framework has been set to "0".
INVITE要求は全くSIPダイアログ使用が作成され、SIP [RFC3261]によって指定されるように処理されたINVITEないことを示すための非2xxのクラスの最終SIP応答（3XX、4XX、5xxの、および6xxの）を受け取りました。具体的には、本明細書のサポートは、本明細書で定義されているメディアタイプの存在を介して交渉されます。例えば、「488」のようなSIPエラー応答の受信は、要求に含まれるオファーが受け入れられないことを示しています。そのような拒否オファーに本明細書に関連付けられたメディア行を含めることがこの仕様をサポートしていない受信クライアントに起因することができると提案を生成するクライアントに指示します。プランを生成するクライアントは[RFC3261]に従って、この応答を受けた上で通常と同じように行動しなければなりません。 [RFC3264]で定義されるようにメディアストリームは、セッション記述の「M =」の行に「0」のポートを設定することによって排除することができます。この仕様を使用して、クライアントは、それがコントロールフレームワークを使用するための挿入「M =」行「0」に設定された回答を受信するように準備しなければなりません。
In this situation, the client will act as it would for any other media type with a port set to "0".
このような状況では、クライアントは、それが「0」に設定されたポートを持つ他のメディアタイプの場合と同じように機能します。
On receiving a SIP INVITE request, an external Server (SIP UAS) inspects the message for indications of support for the mechanisms defined in this specification. This is achieved through inspection of the session description of the offer message and identifying support for the application/cfw MIME type in the SDP. If the SIP UAS wishes to construct a reliable response that conveys support for the extension, it MUST follow the mechanisms defined in [RFC3261]. If support is conveyed in a reliable SIP provisional response, the mechanisms in [RFC3262] MUST also be used. It should be noted that the SDP offer is not restricted to the initial INVITE request and MAY appear in any series of messages that are compliant to [RFC3261], [RFC3262], [RFC3311], and [RFC3264].
SIP INVITEリクエストを受信すると、外部サーバ（SIP UAS）は、本明細書で定義されたメカニズムのためのサポートの表示のためにメッセージを検査します。これは、SDP内のアプリケーション/ CFWのMIMEタイプのオファーメッセージのセッション記述の検査および識別のサポートによって達成されます。 SIP UASは、拡張のサポートを伝える信頼できる応答を構築したい場合は、[RFC3261]で定義されたメカニズムに従わなければなりません。サポートが信頼SIP暫定応答で搬送されている場合は、[RFC3262]での機構も使用しなければなりません。 SDPオファーがINVITEリクエストを初期に限定されるものではなく、[RFC3261]、[RFC3262]、[RFC3311]、および[RFC3264]に準拠しているメッセージのいずれかのシリーズに現れることに留意すべきです。
When constructing an answer, the SDP payload MUST be constructed using the semantic (connection, media, and attribute) defined in Section 4.1 using valid local settings and also with full compliance to the COMEDIA [RFC4145] specification. For example, the SDP attributes included in the answer constructed for the example offer provided in Section 4.1 would look as follows:
答えを構築する場合、SDPペイロードはCOMEDIA [RFC4145]仕様に完全に準拠しても有効なローカル設定を使用して、セクション4.1で定義されたセマンティック（接続、メディア、および属性）を使用して構築されなければなりません。例えば、SDPの属性は次のようになります4.1で提供される例の提供のために構築の答えに含ま：
a=setup:passive
a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. This attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/ answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id' value received in the offer as it is used to uniquely identify and distinguish between multiple endpoints that generate SDP answers. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange.
セクション9.2で定義されているような答えを構築し、クライアントは「CFW-ID」SDP属性を含まなければなりません。この属性は、UACとUAS間の相互作用の文脈の中で一意である必要があり、他のSIPオファー/アンサー交換に使用される「CFW-ID」のインスタンスと衝突してはなりません。 「CFW-ID」は、それを一意に識別し、SDP回答を生成する複数のエンドポイントを区別するために使用されるオファーで受信した「CFW-ID」値異なっていなければなりません。 「CFW-ID」属性のために選択された値は、ダイアログ使用を招待オファー/アンサー交換の更新時に変更されていない関連するSIPの全期間のために使用されなければなりません。
Once the SDP answer has been constructed, it is sent using standard SIP mechanisms. Depending on the contents of the SDP payloads that were negotiated using the offer/answer exchange, a reliable connection will be established between the Controlling UAC and External Server UAS entities. The newly established connection is now available to exchange Control Command primitives. The state of the SIP INVITE dialog usage and the associated Control Channel are now implicitly linked. If either party wishes to terminate a Control Channel, it simply issues a SIP termination request (for example, a
SDP答えが構築されたら、それは標準のSIPメカニズムを使用して送信されます。オファー/アンサー交換を使用して交渉されたSDPペイロードの内容によっては、信頼性の高い接続は、制御UACとUAS外部サーバーのエンティティ間で確立されます。新しく確立された接続は現在、制御コマンドプリミティブを交換するために利用可能です。 SIPの状態は今、暗黙的にリンクされているダイアログの使用とそれに関連する制御チャネルを招待します。いずれかの当事者が制御チャネルを終了しようとする場合、それは単に、例えば（SIP終了要求を発行します
SIP BYE request or appropriate response in an early SIP INVITE dialog usage). The Control Channel therefore lives for the duration of the SIP INVITE dialog usage.
SIPのBYE要求または早期SIPにおける適切な応答ダイアログの使用をINVITE）。制御チャネルは、そのためのダイアログの使用を、SIP INVITEの期間中に住んでいます。
A UAS receiving a SIP OPTIONS request MUST respond appropriately as defined in [RFC3261]. The UAS MUST include the media types supported in the SIP 200 OK response in a SIP 'Accept' header to indicate the valid media types.
[RFC3261]で定義されるようにSIP OPTIONS要求を受信するUASは、適切に応答しなければなりません。 UASは、有効なメディアの種類を示すために、ヘッダ」を受け入れる] SIPにSIP 200 OK応答でサポートされているメディアタイプを含まなければなりません。
It is intended that the Control Framework will be used within a variety of architectures for a wide range of functions. One of the primary functions will be the use of the Control Channel to apply multiple specific Control Package commands to media sessions established by SIP INVITE dialogs (media dialogs) with a given remote server. For example, the Control Server might send a command to generate audio media (such as an announcement) on an RTP stream between a User Agent and a media server.
コントロールフレームワークは、機能の広い範囲のためのアーキテクチャの様々な内で使用されることが意図されます。主な機能の1つは、複数の特定の制御パッケージを適用するための制御チャネルの使用は、特定のリモートサーバーとの対話（メディア・ダイアログ）を、SIP INVITEによって確立されたメディアセッションにコマンドになります。例えば、制御サーバはユーザエージェントとメディアサーバー間のRTPストリーム上で（例えば告知など）オーディオメディアを生成するためのコマンドを送信することがあります。
SIP INVITE dialogs used to establish media sessions (see Figure 2) on behalf of User Agents MAY contain more than one Media Description (as defined by "m=" in the SDP). The Control Client MUST include a media label attribute, as defined in [RFC4574], for each "m=" definition received that is to be directed to an entity using the Control Framework. This allows the Control Client to later explicitly direct commands on the Control Channel at a specific media line (m=).
メディアセッションを確立するために使用されるダイアログを、SIP INVITE（SDPにおけるによって定義されるような「M =」）以上のメディア記述を含むかもしれユーザエージェントに代わって（図2参照）。 [RFC4574]で定義されるようにコントロールクライアントは、メディアラベル属性を含まなければなりません、それぞれについて「M =」の定義は、それがコントロールフレームワークを使用してエンティティに向けられることである受信しました。これは、特定のメディア行（M =）で制御チャネル上で、後に明示的にダイレクトコマンドにコントロールクライアントを可能にします。
This framework identifies the referencing of such associated media dialogs as extremely important. A connection reference attribute has been specified that can optionally be imported into any Control Package. It is intended that this will reduce the repetitive specifying of dialog reference language. The schema can be found in Appendix A.1.
このフレームワークは、非常に重要なような関連するメディアダイアログの参照を識別します。接続リファレンス属性は、必要に応じて、任意の制御パッケージにインポートすることができる指定されています。ダイアログ参照言語の繰り返しの指定を削減することが意図されています。スキーマは、付録A.1に記載されています。
Similarly, the ability to identify and apply commands to a group of associated media dialogs (multiparty) is also identified as a common structure that could be defined and reused, for example, playing a prompt to all participants in a Conference. The schema for such operations can also be found in Appendix A.1.
同様に、関連するメディア・ダイアログ（マルチパーティ）のグループにコマンドを識別し、適用する能力はまた、会議のすべての参加者にプロンプトを再生し、例えば、定義され、再利用できる共通の構造として同定されます。このような操作のためのスキーマも付録A.1で見つけることができます。
Support for both the common attributes described here is specified as part of each Control Package definition, as detailed in Section 8.
第8章で説明するように、ここで説明した一般的な属性の両方のサポートは、各制御パッケージ定義の一部として指定されています。
In this document, the use of the COMEDIA specification allows for a Control Channel to be set up in either direction as a result of a SIP INVITE transaction. SIP provides a flexible negotiation mechanism to establish the Control Channel, but there needs to be a mechanism within the Control Channel to correlate it with the SIP INVITE dialog usage implemented for its establishment. A Control Client receiving an incoming connection (whether it be acting in the role of UAC or UAS) has no way of identifying the associated SIP INVITE dialog usage as it could be simply listening for all incoming connections on a specific port. The following steps, which implementations MUST support, allow a connecting UA (that is, the UA with the active role in COMEDIA) to identify the associated SIP INVITE dialog usage that triggered the connection. Unless there is an alternative dialog association mechanism used, the UAs MUST carry out these steps before any other signaling on the newly created Control Channel.
制御チャネルは、SIP INVITE取引の結果として、どちらの方向に設定されるため、このドキュメントでは、COMEDIA仕様の使用ができます。 SIPは、制御チャネルを確立するための柔軟な交渉メカニズムを提供していますが、その設立のために実装ダイアログの使用を、SIP INVITEとそれを相関させる制御チャネル内のメカニズムが必要です。 （それは、UACまたはUASの役割で作用するかどうか）の着信接続を受信制御クライアントは、単に特定のポート上のすべての着信接続をリスンすることができるように関連付けられたSIPダイアログ使用をINVITE識別する方法がありません。実装がサポートしなければならない次のステップは、接続をトリガダイアログ使用をINVITE関連したSIPを識別するために（すなわち、COMEDIAにおいて積極的な役割を持つUA）と接続UAを可能にします。使用される代替ダイアログ・アソシエーション・メカニズムがない限り、UAは、新しく作成された制御チャネル上の他のシグナリング前に、次の手順を実行しなければなりません。
o Once the connection has been established, the UA acting in the active role (active UA) to initiate the connection MUST send a Control Framework SYNC request. The SYNC request MUST be constructed as defined in Section 9.1 and MUST contain the 'Dialog-ID' message header.
接続が確立されたらO、UAは、コントロールフレームワークSYNC要求を送らなければなりません接続を開始するために積極的な役割（アクティブUA）に作用します。 SYNC要求は、セクション9.1で定義されるように構成されなければならなくて、「ダイアログID」メッセージヘッダを含まなければなりません。
o The 'Dialog-ID' message header is populated with the value of the local 'cfw-id' media-level attribute that was inserted by the same client in the SDP offer/answer exchange to establish the Control Channel. This allows for a correlation between the Control Channel and its associated SIP INVITE dialog usage.
O「ダイアログID」メッセージヘッダが制御チャネルを確立するためにSDPオファー/アンサー交換に同じクライアントによって挿入されたローカル「CFW-ID」メディアレベル属性の値が取り込まれます。これは、制御チャネル間の相関を可能にし、それに関連するSIPダイアログの使用をINVITE。
o On creating the SYNC request, the active UA MUST follow the procedures outlined in Section 6.3.3. This provides details of connection keep-alive messages.
O SYNC要求を作成する、アクティブUAは、セクション6.3.3に概説された手順に従わなければなりません。これは、接続キープアライブメッセージの詳細を提供します。
o On creating the SYNC request, the active UA MUST also follow the procedures outlined in Section 6.3.4.2. This provides details of the negotiation mechanism used to determine the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection.
O SYNC要求を作成する、アクティブUAはまた、セクション6.3.4.2に概説された手順に従わなければなりません。これは、確立された制御チャネル接続で交換することができるプロトコルデータユニット（PDU）を決定するために使用する交渉メカニズムの詳細を提供します。
o The UA in the active role for the connection creation MUST then send the SYNC request. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a 2xx-class SIP response, it MUST wait for an incoming SIP ACK message before issuing the SYNC. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a reliable 1XX class SIP response, it MUST wait for an incoming SIP PRACK message before issuing the SYNC.
O接続を作成するための積極的な役割でUAは、SYNC要求を送らなければなりません。 UAは、接続を作成するための積極的な役割にSIP UASであるとの2xxクラスのSIP応答でのSDP応答を生成した場合には、SYNCを発行する前に、着信SIP ACKメッセージを待たなければなりません。 UAは、接続を作成するための積極的な役割にSIP UASで、信頼性の高い1XXクラスSIP応答のSDPその応答を生成した場合には、SYNCを発行する前に、着信SIP PRACKメッセージを待たなければなりません。
If the UA in the active role for the connection creation is a SIP UAC, it MUST send the SYNC message immediately on establishment of the Control Channel. It MUST then wait for a period of at least 2*'Transaction-Timeout' to receive a response. It MAY choose a longer time to wait, but it MUST NOT be shorter than 'Transaction-Timeout'. In general, a Control Framework transaction MUST complete within 20 (2*'Transaction-Timeout') seconds and is referenced throughout the document as 'Transaction-Timeout'.
接続の作成のための積極的な役割でUAがSIP UACであれば、それは制御チャネルの確立にすぐにSYNCメッセージを送らなければなりません。その後、応答を受信するために、少なくとも2 *「トランザクション・タイムアウト」の期間を待つ必要があります。それは待つ長い時間を選ぶかもしれないが、それは、「トランザクション・タイムアウト」より短くてはなりません。一般的には、コントロールフレームワークのトランザクションは、20（2 *「トランザクション・タイムアウト」）秒以内に完了しなければならないと「トランザクションタイムアウト」などの文書全体で参照されます。
o If no response is received for the SYNC message, a timeout occurs and the Control Channel is terminated along with the associated SIP INVITE dialog usage. The active UA MUST issue a BYE request to terminate the SIP INVITE dialog usage.
応答がSYNCメッセージを受信されない場合、O、タイムアウトが発生し、制御チャネルは、ダイアログを使用INVITE関連SIPと共に終了します。アクティブUAは、ダイアログの使用を、SIP INVITEを終了するBYEリクエストを発行しなければなりません。
o If the active UA receives a 481 response from the passive UA, this means the SYNC request was received, but the associated SIP INVITE dialog usage specified in the SYNC message does not exist. The active client MUST terminate the Control Channel. The active UA MUST issue a SIP BYE request to terminate the SIP INVITE dialog usage.
アクティブUAは受動UAからの481応答を受信した場合、O、これはSYNC要求が受信されたことを意味するが、SYNCメッセージで指定された関連したSIP INVITEダイアログ使用法は存在しません。アクティブなクライアントは、制御チャネルを終えなければなりません。アクティブUAは、ダイアログの使用を、SIP INVITEを終了させるSIP BYEリクエストを発行しなければなりません。
o All other error responses received for the SYNC request are treated as detailed in this specification and also result in the termination of the Control Channel and the associated SIP INVITE dialog usage. The active UA MUST issue a BYE request to terminate the SIP INVITE dialog usage.
制御チャネルの終了と関連したSIPダイアログを使用INVITEをもたらし、また、本明細書に詳述としてO SYNC要求を受信した他のすべてのエラー応答が処理されます。アクティブUAは、ダイアログの使用を、SIP INVITEを終了するBYEリクエストを発行しなければなりません。
o The receipt of a 200 response to a SYNC message implies that the SIP INVITE dialog usage and control connection have been successfully correlated. The Control Channel can now be used for further interactions.
O SYNCメッセージに対する200応答の受信は、SIPが正常に相関しているダイアログ使用および制御接続をINVITEことを意味します。制御チャネルは、ここでさらに相互作用のために使用することができます。
SYNC messages can be sent at any point while the Control Channel is open from either side, once the initial exchange is complete. If present, the contents of the 'Keep-Alive' and 'Dialog-ID' headers MUST NOT change. New values of the 'Keep-Alive' and 'Dialog-ID' headers have no relevance as they are negotiated for the lifetime of the Media Control Channel Framework session.
最初の交換が完了すると、制御チャネルは、いずれの側から開いている間にSYNCメッセージは、任意の時点で送信することができます。存在する場合、内容は「ダイアログ-ID」ヘッダは「-キープアライブ」と変化してはいけません。新しい「キープアライブ」の値と、彼らはメディア制御チャネルフレームワークセッションの存続のために交渉されているとして、「ダイアログ-ID」ヘッダは何の関連性を持っていません。
Once a successful Control Channel has been established, as defined in Sections 4.1 and 4.2, and the connection has been correlated, as described in previous paragraphs, the two entities are now in a position to exchange Control Framework messages. The following sub-sections specify the general behavior for constructing Control Framework requests and responses. Section 6.3 specifies the core Control Framework methods and their transaction processing.
セクション4.1と4.2で定義されて成功した制御チャネルは、確立されており、前の段落で説明したように、接続は、相関された後、2つのエンティティは、コントロールフレームワークのメッセージを交換する立場になりました。以下のサブセクションでは、コントロールフレームワークの要求と応答を構築するための一般的な動作を指定します。 6.3節は、コアコントロールフレームワークのメソッドとそれらのトランザクション処理を指定します。
An entity acting as a Control Client that constructs and sends requests on a Control Channel MUST adhere to the syntax defined in Section 9. Note that either entity can act as a Control Client depending on individual package requirements. Control Commands MUST also adhere to the syntax defined by the Control Packages negotiated in Sections 4.1 and 4.2 of this document. A Control Client MUST create a unique transaction and associated identifier for insertion in the request. The transaction identifier is then included in the first line of a Control Framework message along with the method type, as defined in the ABNF in Section 9. The first line starts with the "CFW" token for the purpose of easily extracting the transaction identifier. The transaction identifier MUST be unique in the context of the interaction between the Control Client and Control Server. This unique property helps avoid clashes when multiple client entities could be creating transactions to be carried out on a single receiving server. All required, mandatory, and optional Control Framework headers are then inserted into the request with appropriate values (see relevant individual header information for explicit detail). A 'Control-Package' header MUST also be inserted with the value indicating the Control Package to which this specific request applies. Multiple packages can be negotiated per Control Channel using the SYNC message discussed in Section 6.3.4.2.
構築し、制御チャネル上の要求はいずれかのエンティティは、個々のパッケージの要件に応じてコントロールクライアントとして作用することができることを第9ノートで定義された構文に準拠する必要があります送信コントロールクライアントとして動作するエンティティ。制御コマンドはまた、セクション4.1と、この文書の4.2で交渉制御パッケージで定義された構文に準拠する必要があります。コントロールクライアントは、要求に挿入するための固有のトランザクションと関連付けられた識別子を作成する必要があります。最初の行は容易トランザクション識別子を抽出するために、「CFW」トークンで始まる項9にABNFで定義されているトランザクション識別子は、その後、メソッドタイプと共にコントロールフレームワークメッセージの最初の行に含まれています。トランザクション識別子は、コントロールクライアントと管理サーバー間の相互作用の文脈の中でユニークでなければなりません。このユニークなプロパティは、複数のクライアントエンティティは、単一の受信用サーバ上で実行されるトランザクションを作成することができたときの衝突を避けることができます。すべての必要な、必須の、およびオプションのコントロールフレームワークヘッダーは、次に、適切な値（明示的に詳細に関連する個々のヘッダ情報を参照）とのリクエストに挿入されます。 「コントロール・パッケージ」ヘッダはまた、この特定の要求が適用される制御パッケージを示す値で挿入されなければなりません。複数のパッケージは、セクション6.3.4.2で述べたSYNCメッセージを使用して制御チャネルごとに交渉することができます。
Any Framework message that contains an associated payload MUST also include the 'Content-Type' and 'Content-Length' message headers, which indicate the MIME type of the payload specified by the individual Control Framework packages and the size of the message body represented as a whole decimal number of octets, respectively. If no associated payload is to be added to the message, the 'Content-Length' header MUST have a value of '0'.
関連するペイロードを含む任意のフレームワークメッセージは、個々の制御フレームワークパッケージで指定されたペイロードのMIMEタイプとして表されるメッセージボディのサイズを示す「コンテンツタイプ」と「コンテンツ長」メッセージヘッダーを含まなければなりませんそれぞれのオクテットの全体進数、。全く関連ペイロードがメッセージに追加されるべきではない場合は、「コンテンツ長」ヘッダは、「0」の値を有しなければなりません。
A Server receiving a Framework message request MUST respond with an appropriate response (as defined in Section 6.2). Control Clients MUST wait for a minimum of 2*'Transaction-Timeout' for a response before considering the transaction a failure and tidying state appropriately depending on the extension package being used.
フレームワークメッセージ要求を受信したサーバは、（セクション6.2で定義されるように）適切な応答で応答しなければなりません。コントロールクライアントがトランザクションに失敗したことを考慮して使用されている拡張パッケージに応じて適宜状態を片付け前に応答を2 *「トランザクション・タイムアウト」の最小値を待つ必要があります。
An entity acting as a Control Server, on receiving a request, MUST generate a response within the 'Transaction-Timeout', as measured from the Control Client. The response MUST conform to the ABNF defined in Section 9. The first line of the response MUST contain the transaction identifier used in the first line of the request, as defined in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' message headers, and these MUST be ignored if received by a Client in a response.
コントロールクライアントから測定されるように制御サーバとして動作するエンティティは、要求を受信した上で、「トランザクション・タイムアウト」内に応答を生成しなければなりません。応答は、セクション6.1で定義されるように、応答の最初の行は、要求の最初の行に使用されるトランザクション識別子を含まなければなりません、セクション9で定義されたABNFに従わなければなりません。応答は「ステータス」または「タイムアウト」というメッセージヘッダを含んではいけません、それに応答して、クライアントが受信した場合、これらは無視しなければなりません。
A Control Server MUST include a status code in the first line of the response. If there is no error, the Server responds with a 200 Control Framework status code, as defined in Section 7.1. The 200 response MAY include message bodies. If the response contains a payload, the message MUST include the 'Content-Length' and 'Content-Type' headers. When the Control Client receives a 2xx-class response, the Control Command transaction is complete.
制御サーバは、応答の最初のラインのステータスコードを含まなければなりません。エラーがない場合、サーバはセクション7.1で定義されるように、200コントロールフレームワークのステータスコードで応答します。 200応答は、メッセージ本文を含むかもしれません。応答はペイロードが含まれている場合、メッセージは、「のContent-Length」や「Content-Typeの」ヘッダを含まなければなりません。コントロールクライアントが2XXクラスの応答を受信すると、制御コマンドのトランザクションが完了しています。
If the Control Server receives a request, like CONTROL, that the Server understands, but the Server knows processing the command will exceed the 'Transaction-Timeout', then the Server MUST respond with a 202 status code in the first line of the response. Following the initial response, the server will send one or more REPORT messages as described in Section 6.3.2. A Control Package MUST explicitly define the circumstances under which the server sends 200 and 202 messages.
サーバーが理解するが、Serverは「トランザクションタイムアウト」を超過するコマンドを処理して知っていることを制御サーバは、CONTROLのような要求を受信した場合、サーバは、応答の最初の行に202のステータスコードで応じなければなりません。 6.3.2項で説明したように初期応答の後、サーバは、1つまたは複数のREPORTメッセージを送信します。制御パッケージは、明示的にサーバが200と202のメッセージを送信する状況を定義しなければなりません。
If a Control Server encounters problems with a Control Framework request (like REPORT or CONTROL), an appropriate error code MUST be used in the response, as listed in Section 7. The generation of a non-2xx-class response code to a Control Framework request (like CONTROL or REPORT) will indicate failure of the transaction, and all associated transaction state and resources MUST be terminated. The response code may provide an explicit indication of why the transaction failed, which might result in a re-submission of the request depending on the extension package being used.
制御サーバは、（REPORTまたはCONTROL等）コントロールフレームワーク要求に問題が発生した場合、セクション7のコントロールフレームワークに非2XXクラス応答コードの生成が記載されているように、適切なエラー・コードは、応答で使用されなければなりません（CONTROLまたはREPORTなど）の要求は、トランザクションの失敗を示します、および関連するすべてのトランザクションの状態とリソースを終えなければなりません。応答コードは、使用されている拡張機能パッケージに依存して要求の再提出をもたらす可能性があるトランザクションが失敗した理由の明示的な指示を提供することができます。
The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods.
CONTROL、REPORT、K-ALIVE、およびSYNC：コントロールフレームワークは、4つの要求（メソッド）のタイプを定義します。実装は、これら4つのメソッドを送受信サポートしなければなりません。
The following sub-sections specify each Control Framework method and its associated transaction processing.
以下のサブセクションでは、各コントロールフレームワークの方法及びそれに関連するトランザクション処理を指定します。
A CONTROL message is used by the Control Client to pass control-related information to a Control Server. It is also used as the event-reporting mechanism in the Control Framework. Reporting events is simply another usage of the CONTROL message, which is permitted to be sent in either direction between two participants in a session, carrying the appropriate payload for an event. The message is constructed in the same way as any standard Control Framework message, as discussed in Section 6.1 and defined in Section 9. A CONTROL message MAY contain a message body. The explicit Control Command(s) of the message payload contained in a CONTROL message are specified in separate Control Package specifications. Separate Control Package specifications MUST conform to the format defined in Section 8.4. A CONTROL message containing a payload MUST include a 'Content-Type' header. The payload MUST be one of the payload types defined by the Control Package. Individual packages MAY allow a CONTROL message that does not contain a payload. This could in fact be a valid message exchange within a specific package; if it's not, an appropriate package-level error message MUST be generated.
制御メッセージは、制御サーバへの制御関連情報を渡すためにコントロールクライアントによって使用されます。また、コントロールフレームワークでのイベント報告機構として使用されています。イベントを報告することは、単にイベントのための適切なペイロードを運ぶ、セッション中に2人の参加者の間でどちらの方向に送信することが許可された制御メッセージの別の使用方法です。セクション6.1で説明したと制御メッセージがメッセージ本体を含むかもしれ項9で定義されたメッセージは、任意の標準的な制御フレームワークのメッセージと同様に構成されています。制御メッセージに含まれるメッセージ・ペイロードの明示的な制御コマンド（複数可）は、別々の制御パッケージの仕様で指定されています。別々の制御パッケージの仕様は、8.4節で定義されたフォーマットに従わなければなりません。ペイロードを含む制御メッセージは、「コンテンツタイプ」ヘッダを含まなければなりません。ペイロードは、制御パッケージで定義されたペイロードタイプのいずれかでなければなりません。個々のパッケージは、ペイロードが含まれていませんCONTROLメッセージを可能にすることができます。これは実際には特定のパッケージ内の有効なメッセージ交換である可能性があります。そうでない場合は、適切なパッケージ・レベルのエラーメッセージが生成されなければなりません。
A 'REPORT' message is used by a Control Server when processing of a CONTROL command extends beyond the 'Transaction-Timeout', as measured from the Client. In this case, the Server returns a 202 response. The Server returns status updates and the final results of the command in subsequent REPORT messages.
CONTROLコマンドの処理は、クライアントから測定されるように、「トランザクション・タイムアウト」を超えて拡張したときに「REPORT」というメッセージは、コントロール・サーバーで使用されています。この場合、サーバーは202応答を返します。サーバーは、ステータスの更新とその後のREPORTメッセージ内のコマンドの最終結果を返します。
All REPORT messages MUST contain the same transaction ID in the request start line that was present in the original CONTROL transaction. This correlates extended transactions with the original CONTROL transaction. A REPORT message containing a payload MUST include the 'Content-Type' and 'Content-Length' headers indicating the payload MIME type [RFC2045] defined by the Control Package and the length of the payload, respectively.
すべてのREPORTメッセージは、元の制御トランザクションに存在した要求のスタートラインに同じトランザクションIDを含まなければなりません。これは、元の制御トランザクションと拡張されたトランザクションを相関させます。ペイロードを含むREPORTメッセージは、「コンテンツタイプ」とはそれぞれ、制御パッケージによって定義されたペイロードのMIMEタイプ[RFC2045]及びペイロードの長さを示す「のContent-Length」ヘッダを含まなければなりません。
On receiving a CONTROL message, a Control Server MUST respond within 'Transaction-Timeout' with a status code for the request, as specified in Section 6.2. If the processing of the command completes within that time, a 200 response code MUST be sent. If the command does not complete within that time, the response code 202 MUST be sent indicating that the requested command is still being processed and the CONTROL transaction is being extended. The REPORT method is then used to update and terminate the status of the extended transaction. The Control Server should not wait until the last possible opportunity to make the decision of issuing a 202 response code and should ensure that it has plenty of time for the response to arrive at the Control Client. If it does not have time, transactions will be terminated (timed out) at the Control Client before completion.
6.2節で指定された制御メッセージを受信すると、制御サーバは、要求のステータスコードを「トランザクションタイムアウト」内に応答しなければなりません。コマンドの処理がその時間内に完了した場合、200レスポンスコードを送らなければなりません。コマンドは、その時間内に完了しない場合、応答コード202は、要求されたコマンドは、まだ処理されていると制御トランザクションが延長されていることを示す送らなければなりません。報告方法は、次に、拡張トランザクションのステータスを更新し、終了するために使用されます。コントロールサーバは202レスポンスコードを発行する決定を行うために最後の可能な機会まで待つべきではありませんし、それがコントロールクライアントに到達する応答のための時間の多くを持っていることを確認する必要があります。それは時間を持っていない場合は、トランザクションが完了する前に、コントロールのクライアントで（タイムアウトした）に終了します。
A Control Server issuing a 202 response MUST ensure the message contains a 'Timeout' message header. This header MUST have a value in seconds that is the amount of time the recipient of the 202 message MUST wait before assuming that there has been a problem and terminating the extended transaction and associated state.
メッセージを確実にしなければなりません202応答を発行制御サーバは「タイムアウト」メッセージヘッダを含んでいます。このヘッダは202メッセージの受信者は問題があったと仮定すると、拡張トランザクションと関連付けられた状態を終了する前に待機しなければならない時間の量であり、秒単位で値を有しなければなりません。
The initial REPORT message MUST contain a 'Seq' (Sequence) message header with a value equal to '1'. Note: the 'Seq' numbers at both Control Client and Control Server for Framework messages are independent.
初期REPORTメッセージは「1」に等しい値を持つ「配列」（配列）メッセージヘッダを含まなければなりません。注意：フレームワークメッセージのコントロールクライアントと管理サーバーの両方で「配列」の数字は独立しています。
All REPORT messages for an extended CONTROL transaction MUST contain a 'Timeout' message header. This header will contain a value in seconds that is the amount of time the recipient of the REPORT message MUST wait before assuming that there has been a problem and terminating the extended transaction and associated state. On receiving a REPORT message with a 'Status' header of 'update', the Control Client MUST reset the timer for the associated extended CONTROL transaction to the indicated timeout period. If the timeout period approaches and no intended REPORT messages have been generated, the entity acting as a Control Framework UAS for the interaction MUST generate a REPORT message containing, as defined in this paragraph, a 'Status' header of 'update' with no associated payload. Such a message acts as a timeout refresh and in no way impacts the extended transaction because no message body or semantics are permitted. It is RECOMMENDED that a minimum value of 10 and a maximum value of 15 seconds be used for the value of the 'Timeout' message header. It is also RECOMMENDED that a Control Server refresh the timeout period of the CONTROL transaction at an interval that is not too close to the expiry time. A value of 80% of the timeout period could be used. For example, if the timeout period is 10 seconds, the Server would refresh the transaction after 8 seconds.
拡張制御トランザクションのすべてのレポートメッセージは「タイムアウト」メッセージヘッダを含まなければなりません。このヘッダは、REPORTメッセージの受信者は問題があったと仮定すると、拡張トランザクションと関連付けられた状態を終了する前に待機しなければならない時間の量であり、秒単位で値を含むであろう。 「更新」の「ステータス」ヘッダとREPORTメッセージを受信すると、クライアントの制御は指示されたタイムアウト時間に関連する拡張制御トランザクションのタイマーをリセットしなければなりません。タイムアウト期間アプローチと無意図REPORTメッセージが生成されている場合は、この段落、無関連のある「更新」の「ステータス」ヘッダに定義されているように、エンティティは、含有REPORTメッセージを生成しなければならない相互作用のためのコントロールフレームワークUASとして動作しますペイロード。メッセージ・ボディやセマンティクスが許可されていないため、このようなメッセージは、拡張トランザクションタイムアウトリフレッシュとしてあり、決してへの影響に作用します。 10の最小値と15秒の最大値は「タイムアウト」メッセージヘッダーの値のために使用することを推奨されています。また、制御サーバが有効期限に近づきすぎない間隔で制御トランザクションのタイムアウト期間を更新することが推奨されます。タイムアウト期間の80％の値を使用することができます。タイムアウト期間が10秒であれば、例えば、サーバーは8秒後にトランザクションを更新します。
Subsequent REPORT messages that provide additional information relating to the extended CONTROL transaction MUST also include and increment by 1 the 'Seq' header value. A REPORT message received that has not been incremented by 1 MUST be responded to with a 406 response and the extended transaction MUST be considered terminated. On receiving a 406 response, the extended transaction MUST be terminated. REPORT messages MUST also include a 'Status' header with a value of 'update'. These REPORT messages sent to update the extended CONTROL transaction status MAY contain a message body, as defined by individual Control Packages and specified in Section 8.5. A REPORT message sent updating the extended transaction also acts as a timeout refresh, as described earlier in this section. This will result in a transaction timeout period at the initiator of the original CONTROL request being reset to the interval contained in the 'Timeout' message header.
拡張制御トランザクションに関する追加情報を提供して、後続のREPORTメッセージはまた、1「配列」ヘッダの値によって含み、インクリメントしなければなりません。 REPORTメッセージ406応答で応答しなければならない1だけインクリメントされておらず、拡張トランザクションを終了考慮しなければならないことを受け取りました。 406応答を受信すると、拡張トランザクションを終えなければなりません。 REPORTメッセージは、「更新」の値と「ステータス」ヘッダを含まなければなりません。個々の制御パッケージで定義され、セクション8.5で指定された拡張制御トランザクションのステータスを更新するために送られたこれらのREPORTメッセージは、メッセージ本文を含むかもしれません。前述のセクションで説明するように拡張されたトランザクションの更新を送信REPORTメッセージは、タイムアウトリフレッシュとして作用します。これは、「タイムアウト」メッセージヘッダに含まれる間隔にリセットされ、元の制御要求の開始時にトランザクションのタイムアウト期間をもたらすであろう。
When all processing for an extended CONTROL transaction has taken place, the entity acting as a Control Server MUST send a terminating REPORT message. The terminating REPORT message MUST increment the value in the 'Seq' message header by the value of '1' from the previous REPORT message. It MUST also include a 'Status' header with a value of 'terminate' and MAY contain a message body. It MUST also contain a 'Timeout' message header with a valid value. The inclusion of the 'Timeout' header is for consistency, and its value is ignored. A Control Framework UAC can then clean up any pending state associated with the original CONTROL transaction.
拡張制御トランザクションのすべての処理が行われた場合には、コントロール・サーバーとして動作するエンティティは、終端REPORTメッセージを送らなければなりません。終端REPORTメッセージは、以前の報告メッセージから「1」の値で「配列」メッセージヘッダーの値をインクリメントしなければなりません。それはまた、「終了」の値が「ステータス」ヘッダを含まなければなりませんとメッセージ本体を含むかもしれません。また、有効な値に「タイムアウト」メッセージヘッダを含まなければなりません。 「タイムアウト」ヘッダを含めることは、一貫性のためであり、その値は無視されます。コントロールフレームワークUACは、元の制御トランザクションに関連付けられているすべての保留状態をクリーンアップすることができます。
The protocol defined in this document may be used in various network architectures. This includes a wide range of deployments where the clients could be co-located in a secured, private domain, or spread across disparate domains that require traversal of devices such as Network Address Translators (NATs) and firewalls. A keep-alive mechanism enables the Control Channel to be kept active during times of inactivity. This is because many firewalls have a timeout period after which connections are closed. This mechanism also provides the ability for application-level failure detection. It should be noted that the following procedures apply only to the Control Channel being created. For details relating to the SIP keep-alive mechanism, implementers should seek guidance from SIP Outbound [RFC5626].
この文書で定義されたプロトコルは、様々なネットワークアーキテクチャで使用することができます。これは、クライアントがセキュリティで保護された、プライベートドメイン内に同じ場所に配置、または、そのような翻訳器（NAT）やファイアウォールアドレス、ネットワークなどのデバイスの横断を必要と本質的に異なるドメイン間で分散させることができ展開の広い範囲を含みます。キープアライブメカニズムは、制御チャネルが非アクティブの時間中にアクティブに保つことができます。多くのファイアウォールは、接続が閉じられた後のタイムアウト期間を持っているためです。このメカニズムは、アプリケーション・レベルの故障検出能力を提供します。以下の手順でのみ作成される制御チャネルに適用されることに留意すべきです。 SIPのキープアライブメカニズムに関する詳細については、実装者は、SIPアウトバウンド[RFC5626]から指導を求めるべきです。
The following keep-alive procedures MUST be implemented. Specific deployments MAY choose not to use the keep-alive mechanism if both entities are in a co-located domain. Note that choosing not to use the keep-alive mechanism defined in this section, even when in a co-located architecture, will reduce the ability to detect application-level errors, especially during long periods of inactivity.
次のキープアライブ手順を実装する必要があります。具体的な展開は、両方のエンティティが同じ場所に配置されているドメインではキープアライブメカニズムを使用しないことも選択できます。同じ場所に配置アーキテクチャでは、特に長期の休止時に、アプリケーション・レベルのエラーを検出する能力が低下する場合でも、ないことを選択すると、このセクションで定義されたキープアライブメカニズムを使用することに注意してください。
Once the SIP INVITE dialog usage has been established and the underlying Control Channel has been set up, including the initial correlation handshake using SYNC as discussed in Section 6, both entities acting in the active and passive roles, as defined in COMEDIA [RFC4145], MUST start a keep-alive timer equal to the value negotiated during the Control Channel SYNC request/response exchange. This is the value from the 'Keep-Alive' header in seconds.
SIP一旦ダイアログ使用法が確立されており、下にある制御チャネルは、セクション6で説明したように、SYNCを使用して初期相関ハンドシェークを含め、設定されたINVITE COMEDIA [RFC4145]で定義されるように、能動的および受動的な役割に作用する両方のエンティティ、制御チャネルSYNC要求/応答交換時にネゴシエートされた値に等しいキープアライブタイマーを起動する必要があります。これは、秒の「キープアライブ」ヘッダーからの値です。
When in an active role, a K-ALIVE message MUST be generated before the local keep-alive timer fires. An active entity is free to send the K-ALIVE message whenever it chooses. It is RECOMMENDED for the entity to issue a K-ALIVE message after 80% of the local keep-alive timer. On receiving a 200 OK Control Framework message for the
積極的な役割で、K-ALIVEメッセージは、ローカルのキープアライブタイマーが起動する前に生成しなければならないとき。アクティブなエンティティは、選択した時はいつでもK-ALIVEメッセージを送信するために自由です。エンティティはローカルキープアライブタイマーの80％の後にK-ALIVEメッセージを発行することをお勧めします。 200 OKコントロールフレームワークのメッセージを受信すると
K-ALIVE request, the active entity MUST reset the local keep-alive timer. If no 200 OK response is received to the K-ALIVE message, or a transport-level problem is detected by some other means, before the local keep-alive timer fires, the active entity MAY use COMEDIA re-negotiation procedures to recover the connection. Otherwise, the active entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.
K-ALIVE要求、アクティブなエンティティは、ローカルキープアライブタイマーをリセットしなければなりません。何の200 OK応答は、K-ALIVEメッセージを受信していない、またはトランスポートレベルの問題は、ローカルのキープアライブタイマーが起動する前に、いくつかの他の手段によって検出された場合、アクティブなエンティティは、接続を回復するためにCOMEDIA再交渉の手順を使用してもよい（MAY） 。それ以外の場合は、アクティブなエンティティは、ダイアログ、SIP INVITEを取り壊すと、関連する制御チャネルリソースを回復する必要があります。
When acting as a passive entity, a K-ALIVE message must be received before the local keep-alive timer fires. When a K-ALIVE request is received, the passive entity MUST generate a 200 OK Control Framework response and reset the local keep-alive timer. No other Control Framework response is valid. If no K-ALIVE message is received (or a transport level problem is detected by some other means) before the local keep-alive timer fires, the passive entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.
受動的なエンティティとして動作する場合には、K-ALIVEメッセージは、ローカルのキープアライブタイマーが起動する前に受信する必要があります。 K-ALIVE要求を受信すると、受動的なエンティティは、200 OKコントロールフレームワークの応答を生成し、ローカルキープアライブタイマーをリセットしなければなりません。他のコントロールフレームワークの応答が有効ではありません。何のK-ALIVEメッセージはローカルキープアライブタイマーが起動する前に受信されない（またはトランスポートレベルの問題がいくつかの他の手段によって検出された）場合は、パッシブエンティティは、SIP INVITEダイアログ取り壊すと関連する制御チャネルリソースを回復する必要があります。
The initial SYNC request on a Control Channel is used to negotiate the timeout period for the Control Channel keep-alive mechanism and to allow clients and servers to learn the Control Packages that each supports. Subsequent SYNC requests MAY be used to change the set of Control Packages that can be used on the Control Channel.
制御チャネル上の最初のSYNC要求が制御チャネルキープアライブメカニズムのタイムアウト時間を交渉すると、クライアントとサーバーが制御パッケージそれぞれがサポートを学ぶことを可能にするために使用されます。後続のSYNC要求が制御チャネル上で使用することができる制御パッケージのセットを変更するために使用されるかもしれません。
The initial SYNC request allows the timeout period for the Control Channel keep-alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request:
最初のSYNC要求が交渉される制御チャネルは、キープアライブメカニズムのタイムアウト時間を可能にします。次のルールは、最初のSYNC要求のために従わなければなりません：
o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to active, the 'Keep-Alive' header MUST be included in the SYNC message generated by the offerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to 120 seconds (this is consistent with SIP Outbound [RFC5626]). The value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The client that generated the SDP "Answer" (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value.
SDPオファーを開始するクライアントはCOMEDIA「セットアップ」を有する場合、Oアクティブに等しい属性、「キープアライブ」ヘッダーは申出により生成されたSYNCメッセージに含まれなければなりません。 「キープアライブ」ヘッダの値（これはSIPアウトバウンドと一致している[RFC5626]）95〜120秒の範囲であるべきです。 「キープアライブ」ヘッダーの値は600秒を超えてはなりません。 SDP「回答」（パッシブクライアント）を生成したクライアントが同じ値を持つSYNCメッセージ200応答に「キープアライブ」ヘッダをコピーする必要があります。
o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to passive, the 'Keep-Alive' header parameter MUST be included in the SYNC message generated by the answerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to
SDPオファーを開始するクライアントはCOMEDIA「セットアップ」は受動的に等しい属性を持っている場合、O、「キープアライブ」ヘッダーパラメータを回答することにより生成されたSYNCメッセージに含まれなければなりません。 「キープアライブ」ヘッダの値が95の範囲にあるべきです
120 seconds. The client that generated the SDP offer (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value.
120秒。 SDPオファーを生成したクライアント（パッシブ・クライアント）は同じ値を持つSYNCメッセージ200応答に「キープアライブ」ヘッダをコピーする必要があります。
o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to 'actpass', the 'Keep-Alive' header parameter MUST be included in the SYNC message of the entity who is the active participant in the SDP session. If the client generating the subsequent SDP answer places a value of 'active' in the COMEDIA SDP 'setup' attribute, it will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds. If the client generating the subsequent SDP answer places a value of 'passive' in the COMEDIA 'setup' attribute, the original UA making the SDP will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds.
SDPオファーを開始するクライアントはCOMEDIA「セットアップは」「actpass」に等しい属性を持っている場合は、O、「キープアライブ」ヘッダーパラメータをSDPセッションに積極的に参加して、エンティティのSYNCメッセージに含まれなければなりません。その後のSDP回答を生成し、クライアントがCOMEDIA SDP「セットアップ」属性で「アクティブ」の値を置く場合は、SYNC要求を生成し、「キープアライブ」ヘッダーが含まれます。値の範囲は95〜120秒であるべきです。その後のSDPアンサーを生成し、クライアントがCOMEDIA「セットアップ」属性の「パッシブ」の値を置く場合、元のUAは、SDPを作るSYNC要求を生成し、「キープアライブ」ヘッダーが含まれます。値の範囲は95〜120秒であるべきです。
o If the initial negotiated offer/answer results in a COMEDIA 'setup' attribute equal to 'holdconn', the initial SYNC mechanism will occur when the offer/answer exchange is updated and the active/passive roles are resolved using COMEDIA.
COMEDIA「セットアップ」の最初に交渉オファー/アンサー結果が「holdconn」に等しい属性場合は、O、オファー/アンサー交換が更新されたときに、最初のSYNCメカニズムが発生し、アクティブ/パッシブの役割がCOMEDIAを使用して解決されます。
The previous steps ensure that the entity initiating the Control Channel connection is always the one specifying the keep-alive timeout period. It will always be the initiator of the connection who generates the K-ALIVE messages.
前の手順は、制御チャネル接続を開始するエンティティは常にキープアライブタイムアウト期間を指定するものであることを確認してください。それは、常にK-ALIVEメッセージを生成し、接続のイニシエータとなります。
Once negotiated, the keep-alive timeout applies for the remainder of the Control Framework session. Any subsequent SYNC messages generated in the Control Channel do not impact the negotiated keep-alive property of the session. The 'Keep-Alive' header MUST NOT be included in subsequent SYNC messages, and if it is received, it MUST be ignored.
交渉したら、キープアライブタイムアウトがコントロールフレームワークセッションの残りの部分に適用されます。制御チャネルで生成された任意の後続のSYNCメッセージは、セッションの交渉さキープアライブプロパティには影響しません。 「キープアライブ」ヘッダーは、後続のSYNCメッセージに含まれてはならないし、それを受信した場合、それを無視しなければなりません。
As part of the SYNC message exchange, a client generating the request MUST include a 'Packages' header, as defined in Section 9. The 'Packages' header contains a list of all Control Framework packages that can be supported within this control session, from the perspective of the client creating the SYNC message. All Channel Framework package names MUST be tokens that adhere to the rules set out in Section 8. The 'Packages' header of the initial SYNC message MUST contain at least one value.
SYNCメッセージ交換の一環として、「パッケージ」ヘッダを含まなければならない要求を生成するクライアントは、「パッケージ」ヘッダから、この制御セッション内でサポートすることができ、すべてのコントロールフレームワークパッケージのリストが含まれている9節で定義されていますSYNCメッセージを作成し、クライアントの視点。すべてのチャネルのフレームワークパッケージ名は、最初のSYNCメッセージの「パッケージ」ヘッダは少なくとも1つの値を含まなければならないセクション8に記載されたルールに従ったトークンでなければなりません。
A server receiving the initial SYNC request MUST examine the contents of the 'Packages' header. If the server supports at least one of the packages listed in the request, it MUST respond with a 200 response code. The response MUST contain a 'Packages' header that lists the supported packages that are in common with those from the 'Packages' header of the request (either all or a subset). This list forms a common set of Control Packages that are supported by both parties. Any Control Packages supported by the server that are not listed in the 'Packages' header of the SYNC request MAY be placed in the 'Supported' header of the response. This provides a hint to the client that generated the SYNC request about additional packages supported by the server.
最初のSYNC要求を受けたサーバは、「パッケージ」ヘッダの内容を調べる必要があります。サーバは、要求にリストされたパッケージの少なくとも一つをサポートしている場合、それは200応答コードで応じなければなりません。応答は、要求（すべてまたはサブセットのいずれか）の「パッケージ」ヘッダからのものと共通しているサポートされているパッケージの一覧を示し「パッケージ」ヘッダを含まなければなりません。このリストは、両当事者によってサポートされている制御パッケージの共通セットを形成しています。 SYNC要求の「パッケージ」ヘッダに記載されていないサーバーでサポートされている任意のコントロールパッケージは、応答の「サポートされている」ヘッダーに配置することができます。これは、サーバーでサポートされている追加パッケージについてのSYNC要求を生成し、クライアントへのヒントを提供します。
If no common packages are supported by the server receiving the SYNC message, it MUST respond with a 422 error response code. The error response MUST contain a 'Supported' header indicating the packages that are supported. The initiating client can then choose to either re-submit a new SYNC message based on the 422 response or consider the interaction a failure. This would lead to termination of the associated SIP INVITE dialog by sending a SIP BYE request, as per [RFC3261].
共通パッケージはSYNCメッセージを受信するサーバによってサポートされていない場合は、422エラー応答コードで応じなければなりません。エラー応答がサポートされているパッケージを示す「サポート」ヘッダを含まなければなりません。開始クライアントは、その後、422応答に基づいて再提出する新しいSYNCメッセージのいずれかに選択するか、または相互作用の障害を検討することができます。これは[RFC3261]に従って、SIP BYE要求を送信することによって、ダイアログをINVITE SIP関連の終了につながります。
Once the initial SYNC transaction is completed, either client MAY choose to send a subsequent new SYNC message to re-negotiate the packages that are supported within the Control Channel. A new SYNC message whose 'Packages' header has different values from the previous SYNC message can effectively add and delete the packages used in the Control Channel. If a client receiving a subsequent SYNC message does not wish to change the set of packages, it MUST respond with a 421 Control Framework response code. Subsequent SYNC messages MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control Framework headers that appeared in the original SYNC negotiation.
最初のSYNCトランザクションが完了すると、いずれかのクライアントは、制御チャネル内でサポートされているパッケージを再交渉するために、その後、新たなSYNCメッセージを送信することを選ぶかもしれません。新しいSYNCメッセージ「パッケージ」ヘッダが効果的に追加して、制御チャネルで使用されるパッケージを削除することができ、前のSYNCメッセージは異なる値を持ちます。その後のSYNCメッセージを受信したクライアントは、パッケージのセットを変更したくない場合は、421コントロールフレームワークの応答コードで応じなければなりません。後続のSYNCメッセージは、元のSYNC交渉に登場した「ダイアログ-ID」と「キープアライブ」コントロールフレームワークヘッダの値を変更しないでください。
An entity MAY honor Control Framework commands relating to a Control Package it no longer supports after package re-negotiation. When the entity does not wish to honor such commands, it MUST respond to the request with a 420 response.
エンティティは、コントロールフレームワークは、それはもはやパッケージの再交渉後サポート制御パッケージに関連するコマンドを尊重することが可能です。エンティティは、そのようなコマンドを尊重したくない場合は、420応答で要求に応答しなければなりません。
The following response codes are defined for transaction responses to methods defined in Section 6.1. All response codes in this section MUST be supported and can be used in response to both CONTROL and REPORT messages except that a 202 MUST NOT be generated in response to a REPORT message.
以下の応答コードは6.1節で定義されたメソッドへのトランザクション応答のために定義されています。このセクションのすべての応答コードをサポートしなければなりませんし、202はREPORTメッセージに応答して生成されてはならないことを除いて、両方のCONTROLとREPORTメッセージに応じて使用することができます。
Note that these response codes apply to Framework Transactions only. Success or error indications for Control Commands MUST be treated as the result of a Control Command and returned in either a 200 response or REPORT message.
これらの応答コードは、専用Framework取引に適用されることに注意してください。制御コマンドの成功またはエラー表示は制御コマンドの結果として扱われ、200応答またはREPORTメッセージのいずれかで返さなければなりません。
The framework protocol transaction completed successfully.
フレームワークプロトコルトランザクションが正常に完了しました。
The framework protocol transaction completed successfully and additional information will be provided at a later time through the REPORT mechanism defined in Section 6.3.2.
フレームワークプロトコルトランザクションは正常に完了し、追加情報は、セクション6.3.2で定義されたREPORT機構を介して後の時点で提供されます。
The request was syntactically incorrect.
リクエストが文法的に間違っていました。
The server understood the request, but is refusing to fulfill it. The client SHOULD NOT repeat the request.
サーバーは要求を理解したが、それを実行することを拒否しています。クライアントが要求を繰り返すべきではありません。
Method not allowed. The primitive is not supported.
方法は許可されていません。プリミティブがサポートされていません。
Message out of sequence.
シーケンスのうちのメッセージ。
Intended target of the request is for a Control Package that is not valid for the current session.
要求の意図した目標は、現在のセッションのために有効ではありません制御パッケージのためです。
Recipient does not wish to re-negotiate Control Packages at this moment in time.
受信者は、時間にこの時点で制御パッケージを再交渉したくはありません。
Recipient does not support any Control Packages listed in the SYNC message.
受信者は、SYNCメッセージに記載されている任意の制御パッケージをサポートしていません。
Recipient has an existing transaction with the same transaction ID.
受信者は、同じトランザクションIDを持つ既存のトランザクションを持っています。
The transaction of the request does not exist. In response to a SYNC request, the 481 response code indicates that the corresponding SIP INVITE dialog usage does not exist.
リクエストのトランザクションが存在しません。 SYNC要求に応答して、481応答コードは、対応するSIPダイアログ使用法が存在しないINVITEことを示しています。
The recipient does not understand the request.
受信者は、要求を理解していません。
Control Packages specify behavior that extends the capability defined in this document. Control Packages MUST NOT weaken statements of "MUST" and "SHOULD" strength in this document. A Control Package MAY strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified by the specific usage of the framework.
制御パッケージは、この文書で定義された機能を拡張動作を指定します。制御パッケージは、「MUST」の文と、この文書の「べきである」強度を弱めてはなりません。制御パッケージは強化してもよい（MAY）、「推奨」、「すべきである」、および「MAY」を「MUST」の枠組みの具体的な使用によって正当化されている場合。
In addition to the usual sections expected in Standards-Track RFCs and SIP extension documents, authors of Control Packages need to address each of the issues detailed in the following sub-sections. The following sections MUST be used as a template and included appropriately in all Control-Package specifications. To reiterate, the following sections do not solely form the basis of all Control-Package specifications but are included as a minimum to provide essential package-level information. A Control-Package specification can take any valid form it wishes as long as it includes at least the following information listed in this section.
標準化過程のRFCおよびSIP拡張文書に期待される通常のセクションに加えて、制御パッケージの作者は次のサブセクションで詳述の各問題に対処する必要があります。以下のセクションでは、鋳型として使用し、すべてのコントロール・パッケージ仕様に適切に含まれなければなりません。繰り返しに、次のセクションでは、単にすべてのコントロール・パッケージ仕様の基礎を形成していないが、必須ではパッケージレベルの情報を提供するために、最低でも含まれています。コントロール・パッケージ仕様は、それがあれば、このセクションに記載されている、少なくとも以下の情報を含むように望む任意の有効な形態をとることができます。
This section MUST be present in all extensions to this document and provides a token name for the Control Package. The section MUST include information that appears in the IANA registration of the token. Information on registering Control Package tokens is contained in Section 13.
このセクションでは、このドキュメントのすべての拡張機能に存在する制御パッケージ用のトークン名を提供しなければなりません。セクションは、トークンのIANA登録に表示される情報を含まなければなりません。コントロールパッケージのトークンの登録については、セクション13に含まれています。
The Control Framework defines a number of message primitives that can be used to exchange commands and information. There are no limitations restricting the directionality of messages passed down a Control Channel. This section of a Control Package document MUST explicitly detail the types of Framework messages (Methods) that can be used as well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type.
コントロールフレームワークは、コマンドおよび情報を交換するために使用することができるメッセージプリミティブの数を定義します。制御チャネル受け継がれたメッセージの方向性を制限する制限はありません。制御パッケージドキュメントのこのセクションには、明示的に詳細と同様に使用することができますフレームワークメッセージ（メソッド）のタイプは、エンティティ間の方向性の指示を提供しなければなりません。これは、要求タイプを開始することを許可された役割タイプが含まれます。
This optional section is only included in a Control Package if the attributes for media dialog or conference reference are required, as defined and discussed in Appendix A.1. The Control Package will make strong statements (using language from RFC 2119 [RFC2119]) if the XML schema defined in Appendix A.1 is to be supported. If only part of the schema is required (for example, just 'connectionid' or 'conferenceid'), the Control Package will make equally strong statements (using language from RFC 2119 [RFC2119]).
メディア・ダイアログまたは会議参照の属性は、付録A.1で定義され、必要と説明されている場合は、このオプションの項では、唯一の制御パッケージに含まれています。制御パッケージは、付録A.1で定義されたXMLスキーマをサポートする場合には（2119 [RFC2119] RFCからの言語を使用して）強い声明を行います。スキーマの一部のみが（例えば、単に「connectionid」または「conferenceid」）必要な場合は、制御パッケージは、（RFC 2119からの言語を使用して、[RFC2119]）同じように強い声明を行います。
This mandatory section of a Control Package defines the control body that can be contained within a CONTROL command request, as defined in Section 6, or that no Control Package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type that apply to a CONTROL command request and, optionally, the associated 200 response. For Control Packages that do not have a Control Package body, making such a statement satisfies the "MUST" strength of this section in the Control Package document.
制御パッケージのこの必須のセクションは、セクション6で定義されるように、制御コマンド要求内に含まれることができる制御体を定義する、または全く制御パッケージ本体が必要とされません。このセクションでは、必要に応じて、制御コマンド要求に適用され、適切なMIME [RFC2045]体型、関連する200レスポンスの詳細な構文定義と意味論の位置を示さなければなりません。そのような文を作る制御パッケージ本体を持っていない制御パッケージの場合、コントロールパッケージの文書で、このセクションの「MUST」強度を満たします。
This mandatory section of a Control Package defines the REPORT body that can be contained within a REPORT command request, as defined in Section 6, or that no report package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type. It should be noted that the Control Framework specification does allow for payloads to exist in 200 responses to CONTROL messages (as defined in this document). An entity that is prepared to receive a payload type in a REPORT message MUST also be prepared to receive the same payload in a 200 response to a CONTROL message. For Control Packages that do not have a Control Package body, stating such satisfies the "MUST" strength of this section in the Control Package document.
制御パッケージのこの必須のセクションは、セクション6で定義されるように、REPORTコマンド要求内に含まれることができるレポートの本体を定義し、又は全くレポートパッケージ本体が必要とされないこと。このセクションでは、適切なMIME [RFC2045]体型の詳細な構文定義と意味論の位置を示さなければなりません。ペイロードは（本書で定義された）メッセージを制御するために200の応答で存在するコントロールフレームワークの仕様が許可しないことに留意すべきです。 REPORTメッセージ内のペイロードタイプを受信するように調製されるエンティティは、制御メッセージ200応答して同一のペイロードを受信するように準備しなければなりません。こうした満足する制御パッケージ文書で、このセクションの「MUST」強さを述べ、制御パッケージ本体を持っていないコントロールパッケージの。
Auditing of various Control Package properties such as capabilities and resources (package-level meta-information) is extremely useful. Such meta-data usually has no direct impact on Control Framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information.
そのような能力とリソース（パッケージレベルのメタ情報）などの各種の制御パッケージプロパティの監査は極めて有用です。このようなメタデータは、通常、コントロールフレームワークの相互作用に直接的な影響を及ぼさないが、文脈情報を学習するためにことができます。制御パッケージは、関連するパッケージの監査情報を提供するために、コントロールフレームワークの相互作用を利用することが奨励されています。
This section SHOULD include the following information:
このセクションでは、次の情報を含める必要があります。
o If an auditing capability is available in this package.
O監査機能は、このパッケージで提供されている場合。
o How auditing information is triggered (for example, using a Control Framework CONTROL message) and delivered (for example, in a Control Framework 200 response).
Oどのように監査情報を（例えば、コントロールフレームワーク制御メッセージを使用して）トリガされ（例えば、コントロールフレームワーク200応答して）送達されます。
o The location of the audit query and response format for the payload (for example, it could be a separate XML schema OR part of a larger XML schema).
ペイロードの監査クエリおよび応答フォーマットの位置（例えば、それは別のXMLスキーマ以上のXMLスキーマの一部であってもよい）、O。
It is strongly RECOMMENDED that Control Packages provide a range of message flows that represent common flows using the package and this framework document.
強く制御パッケージは、パッケージと、このフレームワークのドキュメントを使用して一般的な流れを表すメッセージ・フローの範囲を提供することが推奨されています。
The Control Framework interactions use the UTF-8 transformation format as defined in [RFC3629]. The syntax in this section uses the Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including types 'DIGIT', 'CRLF', and 'ALPHA'.
[RFC3629]で定義されるような制御フレームワーク相互作用は、UTF-8の変換フォーマットを使用します。タイプ「DIGIT」、「CRLF」、および「ALPHA」を含む[RFC5234]で定義されるようにこのセクションの構文は、拡張バッカス・ナウアフォーム（ABNF）を使用します。
Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are not case-sensitive.
そうでなければ特定のヘッダフィールドの定義において言及されない限り、フィールドの値、パラメータ名およびパラメータ値は、大文字と小文字を区別しません。
control-req-or-resp = control-request / control-response control-request = control-req-start *headers CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content] control-req-start = pCFW SP trans-id SP method CRLF control-resp-start = pCFW SP trans-id SP status-code CRLF
制御-REQ-OR-RESP =制御要求/制御応答制御要求=制御-REQ-開始*ヘッダーCRLF [制御内容】制御応答=制御-RESP-開始*ヘッダーCRLF [制御内容]コントロール-reqスタート= pCFW SPトランスのID SP方法CRLF制御-RESPスタート= pCFW SPトランス-ID SPステータスコードCRLF
pCFW = %x43.46.57; CFW in caps trans-id = alpha-num-token method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps mSYNC = %x53.59.4E.43 ; SYNC in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps
pCFW =％x43.46.57。キャップトランスID =アルファ - NUMトークン方法の他の方式mCONTROL =％のx43.4F.4E.54.52.4F.4C / = mCONTROL / mREPORT / MSYNC / MK-ALIVEでCFW。キャップでCONTROL mREPORT =％x52.45.50.4F.52.54。キャップでREPORT MSYNC =％x53.59.4E.43。キャップMK-ALIVE =％x4B.2D.41.4C.49.56.45でSYNC。 K-ALIVEキャップで
other-method = 1*UPALPHA status-code = 3*DIGIT ; any code defined in this and other documents headers = header-name CRLF
他の方式= 1 * UPALPHAステータスコード= 3 * DIGIT。このおよび他の文書のヘッダー=ヘッダ名CRLFで定義されたコード
header-name = (Content-Length /Content-Type /Control-Package /Status /Seq /Timeout /Dialog-ID /Packages /Supported /Keep-alive /ext-header)
ヘッダ名=（のContent-Length /コンテンツタイプ/コントロール・パッケージ/ステータス/配列/タイムアウト/ダイアログ-ID /パッケージ/サポート/キープアライブ/ EXT-ヘッダ）
Content-Length = "Content-Length:" SP 1*DIGIT Control-Package = "Control-Package:" SP 1*alpha-num-token Status = "Status:" SP ("update" / "terminate" ) Timeout = "Timeout:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT Dialog-ID = "Dialog-ID:" SP dialog-id-string Packages = "Packages:" SP package-name *(COMMA package-name) Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum) Keep-alive = "Keep-Alive:" SP kalive-seconds
Content-Length = "コンテンツ長：" SP 1 * DIGITコントロール・パッケージ= "コントロール・パッケージ：" SP 1 *アルファNUMトークンステータス= "ステータス：" SP（ "更新" / "終了"）タイムアウト= "タイムアウト：" SP 1 * DIGIT SEQ = "配列：" SP 1 * DIGITのダイアログ-ID = "ダイアログ-ID：" SPダイアログ-ID文字列パッケージ= "パッケージ：" SPパッケージ名*（COMMAパッケージ名）サポートされている= "サポートされている：" SPのsupprtd-alphanumの*（COMMAのsupprtd-alphanum）キープアライブ= "キープアライブ：" SPのkalive秒
dialog-id-string = alpha-num-token package-name = alpha-num-token supprtd-alphanum = alpha-num-token kalive-seconds = 1*DIGIT
ダイアログ-ID文字列= alphanumトークンパッケージ名= alphanumトークンsupprtd-alphanum = alphanumトークンkalive-秒= 1 * DIGIT
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
alphanumトークン= ALPHANUM 3 * 31 alphanum-トークンチャーalphanumトークン-チャー= ALPHANUM / "" / " - " / "+" / "％" / "=" / "/"
control-content = *OCTET
コントロール・コンテンツ= * OCTET
Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *(SP ";" gen-param ) type = token ; Section 4.2 of RFC 4288 subtype = token ; Section 4.2 of RFC 4288
Content-Typeの= "Content-Typeの" SPメディア型メディアタイプ=タイプ "/" サブタイプ*（SP ";" GEN-PARAM）=トークンタイプ。 RFC 4288サブタイプ=トークンのセクション4.2。 RFC 4288のセクション4.2
gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string
GEN-PARAM = pnameの[ "=" は、pval]のpname =トークンは、pval =トークン/引用符で囲まれた文字列
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E)
トークン= 1 *（％X21 /％x23-27 /％X2A-2B /％x2D-2E /％x30-39 /％x41-5A /％x5E-7E）
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH = "\" UPALPHA = %x41-5A ALPHANUM = ALPHA / DIGIT
引用符で囲んだ文字列= DQUOTE *（qdtext / QD-ESC）DQUOTE qdtext = SP / HTAB /％X21 /％x23-5B /％x5D-7E / UTF8-NONASCII QD-ESC =（バックスラッシュバックスラッシュ）/（バックスラッシュDQUOTE）BACKSLASH = "\" UPALPHA =％x41-5A ALPHANUM = ALPHA / DIGIT
ext-header = hname ":" SP hval CRLF
EXT-ヘッダ= hname "：" SP hval CRLF
hname = ALPHA *token hval = utf8text
hname = ALPHA *トークンhval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF-8テキスト= *（TAB /％x20-7E / UTF-8 NON ASCII）
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4。 RFC 3629から
The following table details a summary of the headers that can be contained in Control Framework interactions.
次の表は、コントロールフレームワーク相互作用に含まれることができるヘッダの概要を詳述します。
Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________
Content-Length o o - -
Control-Package R m - - -
Seq - m - -
Status R - m - -
Timeout R - m - -
Timeout 202 - m - -
Dialog-ID R - - m -
Packages - - m -
Supported r - - o -
Keep-Alive R - - o -
Content-Type o o - -
Table 1: Summary of Headers in Control Framework Interactions
表1：コントロールフレームワークの相互作用におけるヘッダの概要
The notation used in Table 1 is as follows:
次のように表1で使用される表記法です。
R: header field may only appear in requests. r: header field may only appear in responses. 2xx, 4xx, etc.: response codes with which the header field can be used. [blank]: header field may appear in either requests or responses. m: header field is mandatory. o: header field is optional. -: header field is not applicable (ignored if present).
R：ヘッダフィールドは、リクエストに表示されること。 R：ヘッダフィールドは、応答に表示されてもよいです。 2XX、4XX、等：ヘッダーフィールドが使用可能な応答コード。 [空白]：ヘッダフィールドは、要求または応答のいずれかで表示されてもよいです。 M：ヘッダフィールドは必須です。 O：ヘッダーフィールドはオプションです。 - ：ヘッダーフィールドは適用されない（存在する場合は無視）。
This specification defines a new media-level value attribute: 'cfw-id'. Its formatting in SDP is described by the following ABNF [RFC5234].
「CFW-ID」：この仕様では、新しいメディア・レベルの値の属性を定義します。 SDPでの書式は以下のABNF [RFC5234]に記載されています。
cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF
CFW-ダイアログ-ID = "A = CFW-ID：" 1 *（SP CFW-ID-名）CRLF
cfw-id-name = token
CFW-ID名=トークン
token = 1*(token-char)
トークン= 1 *（トークンチャー）
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E
トークンチャー=％X21 /％x23-27 /％X2A-2B /％x2D-2E /％x30-39 /％x41-5A /％x5E-7E
The token-char and token elements are defined in [RFC4566] but included here to provide support for the implementer of this SDP feature.
トークンチャーとトークン要素は[RFC4566]で定義されるが、このSDP機能の実装のためのサポートを提供するためにここに含まれています。
The following examples provide an abstracted flow of Control Channel establishment and Control Framework message exchange. The SIP signaling is prefixed with the token 'SIP'. All other messages are Control Framework interactions defined in this document.
以下の実施例は、抽象化された制御チャネル確立の流れとコントロールフレームワークのメッセージ交換を提供します。 SIPシグナリングはトークン「SIP」が付いています。他のすべてのメッセージは、この文書で定義されたコントロールフレームワークの相互作用です。
In this example, the Control Client establishes a Control Channel, SYNCs with the Control Server, and issues a CONTROL request that can't be completed within the 'Transaction-Timeout', so the Control Server returns a 202 response code to extend the transaction. The Control Server then follows with REPORTs until the requested action has been completed. The SIP INVITE dialog is then terminated.
この例では、コントロールクライアントは、制御チャネル、コントロールサーバと同期を確立し、制御サーバは、トランザクションを拡張するために202応答コードを返しますので、「トランザクション・タイムアウト」内に完了することができないCONTROL要求を発行します。要求されたアクションが完了するまで制御サーバは、報告と続きます。 SIP INVITEダイアログを終了します。
Control Client Control Server
| |
| (1) SIP INVITE |
| ----------------------------------------> |
| |
| (2) SIP 200 |
| <--------------------------------------- |
| |
| (3) SIP ACK |
| ----------------------------------------> |
| |
|==>=======================================>==|
| Control Channel Established |
|==>=======================================>==|
| |
| (4) SYNC |
| ----------------------------------------> |
| |
| (5) 200 |
| <--------------------------------------- |
| |
| (6) CONTROL |
| ----------------------------------------> |
| |
(1) Control Client-->Control Server (SIP): INVITE sip:control-server@example.com
（1）コントロールクライアント - >コントロールサーバ（SIP）：SIP INVITE：control-server@example.com
INVITE sip:control-server@example.com SIP/2.0 To: <sip:control-server@example.com> From: <sip:control-client@example.com>;tag=8937498 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123 CSeq: 1 INVITE Max-Forwards: 70 Call-ID: 893jhoeihjr8392@example.com Contact: <sip:control-client@pc1.example.com> Content-Type: application/sdp Content-Length: 206
SIP / 2.0 / UDP：; control-server@example.com SIP / 2.0に：<SIP：control-server@example.com>から：タグ= 8937498経由：<SIP control-client@example.com> SIPのINVITE client.example.com;ブランチ= z9hG4bK123のCSeq：1 INVITEマックス・フォワード：70のCall-ID：893jhoeihjr8392@example.com連絡先：<SIP：control-client@pc1.example.com>のContent-Type：アプリケーション/ SDPコンテンツ-length：206
v=0 o=originator 2890844526 2890842808 IN IP4 controller.example.com s=- c=IN IP4 control-client.example.com m=application 49153 TCP cfw a=setup:active a=connection:new a=cfw-id:fndskuhHKsd783hjdla (2) Control Server-->Control Client (SIP): 200 OK
アクティブA =接続：新A = CFW-ID C = IN IP4 control-client.example.com M =アプリケーション49153 TCPのCFWのA =セットアップ - IP4 controller.example.com S = IN V = 0 0 =発信2890844526 2890842808 ：fndskuhHKsd783hjdla（2）制御サーバ - >コントロールクライアント（SIP）：200 OK
SIP/2.0 200 OK To: <sip:control-server@example.com>;tag=023983774 From: <sip:control-client@example.com>;tag=8937498 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5 CSeq: 1 INVITE Call-ID: 893jhoeihjr8392@example.com Contact: <sip:control-server@pc2.example.com> Content-Type: application/sdp Content-Length: 203
SIP / 2.0 200 OKに：<SIP：control-server@example.com>;タグ= 023983774から：<SIP：control-client@example.com>;タグ= 8937498経由：SIP / 2.0 / UDP client.example。 COM;ブランチ= z9hG4bK123;受け取ら= 192.0.2.5のCSeq：1 INVITEコールIDを：893jhoeihjr8392@example.com連絡先：<SIP：control-server@pc2.example.com>のContent-Type：アプリケーション/ SDPコンテンツの長さ： 203
v=0 o=responder 2890844600 2890842900 IN IP4 controller.example.com s=- c=IN IP4 control-server.example.com m=application 49153 TCP cfw a=setup:passive a=connection:new a=cfw-id:7JeDi23i7eiysi32
V = 0 0 =レスポンダ2890844600 2890842900 IN IP4 controller.example.com S = - C = IN IP4 control-server.example.com M =アプリケーション49153 TCPのCFWのA =セットアップ：受動A =接続：新しいA = CFW-ID ：7JeDi23i7eiysi32
(3) Control Client-->Control Server (SIP): ACK
（3）コントロールクライアント - >コントロールサーバ（SIP）：ACK
(4) Control Client opens a TCP connection to the Control Server. The connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): SYNC.
（4）コントロールクライアントは、管理サーバーへのTCP接続を開きます。接続は現在、コントロールフレームワークのメッセージを交換するために使用することができます。コントロールクライアント - >コントロールサーバー（コントロールフレームワークのメッセージ）：SYNC。
CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0
CFW 8djae7khauj SYNCダイアログ-ID：fndskuhHKsd783hjdlaは、キープアライブ：100のパッケージ：MSC-IVR-基本/ 1.0
(5) Control Server-->Control Client (Control Framework message): 200.
（5）制御サーバ - >コントロールクライアント（コントロールフレームワークのメッセージ）：200。
CFW 8djae7khauj 200 Keep-Alive: 100 Packages: msc-ivr-basic/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
CFWは8djae7khauj 200キープアライブ：100のパッケージ：MSC-IVR-基本/ 1.0サポート：MSC-IVR-VXML / 1.0、MSC-confのオーディオ/ 1.0
(6) Once the SYNC process has completed, the connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): CONTROL.
同期プロセスが完了すると（6）、接続は現在コントロールフレームワークメッセージを交換するために使用することができます。コントロールクライアント - >コントロールサーバー（コントロールフレームワークのメッセージ）：CONTROL。
CFW i387yeiqyiq CONTROL Control-Package: <package-name> Content-Type: example_content/example_content
CFW CONTROLコントロール・パッケージをi387yeiqyiq：<パッケージ名>のContent-Type：example_content / example_content
Content-Length: 11
コンテンツの長さ：11
<XML BLOB/>
<XML BLOB />
(7) Control Server-->Control Client (Control Framework message): 202.
（7）制御サーバ - >クライアントの制御（コントロールフレームワークのメッセージ）：202。
CFW i387yeiqyiq 202 Timeout: 10
10：CFWは202タイムアウトをi387yeiqyiq
(8) Control Server-->Control Client (Control Framework message): REPORT.
（8）制御サーバ - >コントロールクライアント（コントロールフレームワークのメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10
REPORT配列i387yeiqyiq CFW：1状態：更新タイムアウト：10
(9) Control Client-->Control Server (Control Framework message): 200.
（9）コントロールクライアント - >コントロールサーバー（コントロールフレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 1
CFWは200配列をi387yeiqyiq：1
(10) Control Server-->Control Client (Control Framework message): REPORT.
（10）コントロール・サーバー - >コントロールクライアント（コントロールフレームワークのメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFWは、REPORT配列をi387yeiqyiq：2つの状態：更新タイムアウト：10のContent-Type：example_content / example_contentのContent-Length：11
<XML BLOB/>
<XML BLOB />
(11) Control Client-->Control Server (Control Framework message): 200.
（11）コントロールクライアント - >コントロールサーバー（コントロールフレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 2
CFWは200配列をi387yeiqyiq：2
(12) Control Server-->Control Client (Control Framework message): REPORT.
（12）コントロール・サーバー - >コントロールクライアント（コントロールフレームワークのメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 3 Status: terminate
REPORT配列i387yeiqyiq CFW：3つのステータス：終了
Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
タイムアウト：10のContent-Type：example_content / example_contentのContent-Length：11
<XML BLOB/>
<XML BLOB />
(13) Control Client-->Control Server (Control Framework message): 200.
（13）コントロールクライアント - >コントロールサーバー（コントロールフレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 3
CFWは200配列をi387yeiqyiq：3
(14) Control Client-->Control Server (SIP): BYE
（14）コントロールクライアント - >コントロールサーバ（SIP）：BYE
BYE sip:control-server@pc2.example.com SIP/2.0 To: <sip:control-server@example.com>;tag=023983774 From: <sip:client@example.com>;tag=8937498 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234 CSeq: 2 BYE Max-Forwards: 70 Call-ID: 893jhoeihjr8392@example.com Contact: <sip:control-client@pc1.example.com> Content-Length: 0
BYEをSIP：control-server@pc2.example.com SIP / 2.0 <SIP：control-server@example.com>;タグ= 023983774から<SIP：client@example.com>;タグ= 8937498のVia：SIP /2.0/UDP client.example.com;ブランチ= z9hG4bK234のCSeq：2 BYEマックス - フォワード：70のCall-ID：893jhoeihjr8392@example.com連絡先：<SIP：control-client@pc1.example.com>のContent-Length： 0
(15) Control Server-->Control Client (SIP): 200 OK
（15）コントロール・サーバー - >コントロールクライアント（SIP）：200 OK
SIP/2.0 200 OK To: <sip:control-server@example.com>;tag=023983774 From: <sip:client@example.com>;tag=8937498 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5 CSeq: 2 BYE Call-ID: 893jhoeihjr8392@example.com Contact: <sip:control-server@pc1.example.com> Content-Length: 0
SIP / 2.0 200 OKに：<SIP：control-server@example.com>;タグ= 023983774から：<SIP：client@example.com>;タグ= 8937498経由：SIP / 2.0 / UDP client.example.com。 2 BYEコール-ID：893jhoeihjr8392@example.com連絡先：<SIP：control-server@pc1.example.com>のContent-Length：0;枝= z9hG4bK234は= 192.0.2.5のCSeqを受け
The Media Control Channel Framework was designed to be only minimally extensible. New methods, header fields, and status codes can be defined in Standards-Track RFCs. The Media Control Channel Framework does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and it MUST describe how its use will be signaled.
メディア制御チャネルフレームワークは、最小限しか拡張できるように設計されました。新しいメソッド、ヘッダフィールド、およびステータスコードは、標準トラックRFCで規定することができます。メディア制御チャネルフレームワークは、バージョン番号または必要とするか、または新しい機能を発見する任意の交渉メカニズムが含まれていません。拡張子が交渉を必要とし、将来的に指定されている場合は、仕様が拡張がカプセル化シグナリングプロトコルで交渉する方法を記述する必要があります。非相互運用可能な更新または拡張が将来発生した場合、それは新たなプロトコルとして扱われ、それはその使用が合図する方法を説明しなければなりません。
In order to allow extension header fields without breaking interoperability, if a Media Control Channel device receives a request or response containing a header field that it does not understand, it MUST ignore the header field and process the request or response as if the header field was not present. If a Media Control Channel device receives a request with an unknown method, it MUST return a 500 response.
メディア制御チャネルデバイスは、それが理解できないヘッダフィールドを含む要求または応答を受信した場合、ヘッダフィールドであるかのよう相互運用性を壊すことなく、拡張ヘッダフィールドを可能にするために、それはヘッダフィールドを無視し、要求または応答を処理しなければなりません現在ではない。メディア制御チャネルデバイスは、未知の方法で要求を受信した場合、それは500応答を返さなければなりません。
The Channel Framework provides confidentiality and integrity for the messages it transfers. It also provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked, as discussed in the remainder of this section.
チャンネルフレームワークは、それが転送メッセージの機密性と完全性を提供します。それはまた、接続されたホストは、それが、このセクションの残りの部分で説明したように、接続は、ハイジャックされていないことを接続することを意味し、宿主であることが保証を提供します。
In design, the Channel Framework complies with the security-related requirements documented in "Media Server Control Protocol Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12, REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by the Channel Framework are summarized in the following sub-sections.
より具体的には、REQ-MCP-11、REQ-MCP-12、REQ-MCP-13、およびREQ - デザインでは、チャネルのフレームワークは、 "メディアサーバー制御プロトコルの要件" に記載のセキュリティ関連の要件[RFC5167]に準拠しています-MCP-14。チャンネルフレームワークによって用いられる特定のセキュリティ対策は、以下のサブセクションにまとめられています。
Channel Framework sessions are established as media sessions described by SDP within the context of a SIP INVITE dialog. In order to ensure secure rendezvous between Control Framework clients and servers, the Media Channel Control Framework should make full use of mechanisms provided by SIP. The use of the 'cfw-id' SDP attribute results in important session information being carried across the SIP network. For this reason, SIP clients using this specification MUST use appropriate security mechanisms, such as TLS [RFC5246] and SMIME [RFC5751], when deployed in open networks.
チャネルFrameworkのセッションは、SIP INVITEダイアログのコンテキスト内でSDPによって記述されるメディアセッションとして確立されています。コントロールフレームワークのクライアントとサーバー間の安全なランデブーを確保するために、メディアチャンネルコントロールフレームワークは、SIPによって提供されるメカニズムをフルに活用する必要があります。 「CFW-ID」SDPの使用は、SIPネットワークを介して行われている重要なセッション情報で結果を属性。この理由のために、この仕様を使用してSIPクライアントは、TLS [RFC5246]及びオープンネットワークに配備SMIME [RFC5751]などの適切なセキュリティメカニズムを使用しなければなりません。
When using only TCP connections, the Channel Framework security is weak. Although the Channel Framework requires the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see data exchanges.
唯一のTCP接続を使用する場合は、チャンネルFrameworkのセキュリティが弱いです。チャンネルFrameworkはこの交換を保護する能力が必要であるが、保護はすべての時間を使用するという保証はありません。そのような保護を使用しない場合は、誰でもデータ交換を見ることができます。
Sensitive data, such as private and financial data, is carried over the Control Framework channel. Clients and servers must be properly authenticated/authorized and the Control Channel must permit the use of confidentiality, replay protection, and integrity protection for the data. To ensure Control Channel protection, Control Framework clients and servers MUST support TLS and SHOULD use it by default unless alternative Control Channel protection is used or a protected environment is guaranteed by the administrator of the network. Alternative Control Channel protection MAY be used if desired (e.g., IPsec [RFC5246]).
こうした民間や財務データなどの機密データは、コントロールフレームワークのチャネルを介して行われます。クライアントとサーバーは正常に/認証され承認され、制御チャネルには、データの機密性、再生保護、および完全性保護の使用を許可する必要がありますする必要があります。制御チャネルの保護を確保するために、コントロールフレームワークのクライアントとサーバはTLSをサポートしなければならないし、代替制御チャネル保護が使用されているか、保護された環境は、ネットワークの管理者によって保証されていない限り、デフォルトでそれを使用する必要があります。所望であれば、代替の制御チャネル保護が使用されてもよい（例えば、IPsecの[RFC5246]）。
TLS is used to authenticate devices and to provide integrity, replay protection, and confidentiality for the header fields being transported on the Control Channel. Channel Framework elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261] MUST be supported. Other cipher-suites MAY also be supported.
TLSは、デバイスを認証し、制御チャネル上で搬送されているヘッダフィールドのための完全性、再生保護、および機密性を提供するために使用されます。チャネルフレームワークエレメントは、TLSを実装しなければならないし、また、[RFC5246]に記載されているようにTLS ClientExtendedHelloサーバー名表示のhello拡張情報を実装しなければなりません。 TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261]のTLS暗号スイートをサポートしなければなりません。他の暗号スイートもサポートされるかもしれません。
When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922 [RFC5922].
TLSクライアントがサーバーとの接続を確立するときに、それはサーバのX.509証明書を提示しています。認証進むRFC 5922 [RFC5922]のセクション7.3（「クライアントの動作」）に記載されているように。
A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922 [RFC5922].
この仕様に準拠TLSサーバは、クライアント証明書を要求しなければなりません。クライアントが証明書を持っている場合は、RFC 5922 [RFC5922]のセクション7.4（「サーバービヘイビア」）で説明したように、それは、相互認証のためにサーバーに提示され、認証が進行されます。
This specification permits the establishment of a dedicated Control Channel using SIP. It is also permitted for entities to create multiple channels for the purpose of failover and redundancy. As a general solution, the ability for multiple entities to create connections and have access to resources could be the cause of potential conflict in shared environments. It should be noted that this document does not carry any specific mechanism to overcome such conflicts but will provide a summary of how to do so.
この仕様は、SIPを使用して専用制御チャネルの確立が可能になります。また、フェイルオーバーと冗長性の目的のために複数のチャネルを作成するエンティティのために許可されています。一般的な解決策として、接続を作成し、リソースへのアクセスを持っている複数のエンティティのための能力は、共有環境における潜在的な紛争の原因である可能性があります。この文書は、このような矛盾を克服するための任意の特定のメカニズムを運ぶことはありませんが、これを行う方法の概要を提供することに留意すべきです。
It can be determined that access to resources and use of Control Channels relate to policy. It can be considered implementation and deployment detail that dictates the level of policy that is adopted. The authorization and associated policy of a Control Channel can be linked to the authentication mechanisms described in this section. For example, strictly authenticating a Control Channel using TLS authentication allows entities to protect resources and ensure the required level of granularity. Such policy can be applied at the package level or even as low as a structure like a conference instance (Control Channel X is not permitted to issue commands for Control Package y OR Control Channel A is not permitted to issue commands for conference instance B). Systems should ensure that, if required, an appropriate policy framework is adopted to satisfy the requirements for implemented packages. The most robust form of policy can be achieved using a strong authentication mechanism such as mutual TLS authentication on the Control Channel. This specification provides a Control Channel response code (403) to indicate to the issuer of a command that it is not permitted. The 403 response MUST be issued to Control Framework requests that are not permitted under the implemented policy. If a 403 response is received, a Control Framework client MAY choose to re-submit the request with differing requirements or to abandon the request. The 403 response does not provide any additional information on the policy failure due to the generic nature of this specification. Individual Control Packages can supply additional information if required. The mechanism for providing such additional information is not mandated in this specification. It should be noted that additional policy requirements to those covered in this section might be defined and applied in individual packages that specify a finer granularity for access to resources, etc.
制御チャネルのリソースと使用へのアクセスは、ポリシーに関連していると判断することができます。それが採用されているポリシーのレベルを決定実装および展開詳細と考えることができます。制御チャネルの許可と関連するポリシーは、このセクションで説明する認証機構に連結することができます。例えば、厳密TLS認証を使用して制御チャネルは、エンティティが資源を保護し、必要な粒度レベルを確保することができます認証。そのようなポリシーは、パッケージレベルで適用されるか、会議インスタンスのような構造としても限り低くすることができる（制御チャネルXコントロールパッケージYまたは制御チャネルAは、会議インスタンスBのためのコマンドを発行することが許可されていないためのコマンドを発行することが許可されていません）。システムは、必要に応じて、適切なポリシーフレームワークが実装パッケージの要件を満たすために採用されている、ことを確実にすべきです。政策の最も堅牢な形態は、制御チャネル上の相互TLS認証などの強力な認証メカニズムを使用して達成することができます。この仕様は、それが許可されていないコマンドの発行者に示すために、制御チャネルの応答コード（403）を提供します。 403応答が実装ポリシーで許可されていないフレームワークの要求を制御するために発行する必要があります。 403応答が受信されている場合は、コントロールフレームワークのクライアントは、異なる要件に要求を再提出するか、要求を放棄することを選択するかもしれません。 403応答は、本明細書の一般的な性質のために政策の失敗についての追加情報を提供していません。必要に応じて個々の制御パッケージには、追加情報を提供することができます。このような追加情報を提供するためのメカニズムはこの仕様で義務付けられていません。このセクションで説明したものに、追加のポリシー要件は、リソースへのアクセスのためのより細かい粒度を指定し、個々のパッケージなどで定義され、適用される可能性があることに留意すべきです
IANA has created a new registry for SIP Control Framework parameters. The "Media Control Channel Framework Parameters" registry is a container for sub-registries. This section further introduces sub-registries for control packages, method names, status codes, header field names, and port and transport protocol.
IANAは、SIPコントロールフレームワークのパラメータのための新しいレジストリを作成しました。 「メディア制御チャネルフレームワークのパラメータ」レジストリは、サブレジストリのコンテナです。このセクションでは、さらに、制御パッケージ、メソッド名、ステータスコード、ヘッダフィールド名、ポートおよびトランスポートプロトコルのサブレジストリを導入します。
Additionally, Section 13.6 registers a new MIME type for use with SDP.
また、セクション13.6は、SDPで使用する新しいMIMEタイプを登録します。
For all registries and sub-registries created by this document, the policy applied when creating a new registration is also applied when changing an existing registration.
既存の登録を変更する場合、新規登録も適用される作成するときに、この文書によって作成されたすべてのレジストリとサブレジストリのために、ポリシーが適用されます。
This specification establishes the Control Packages sub-registry under Media Control Channel Framework Packages. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream), using the IANA policy [RFC5226] "RFC Required".
この仕様は、メディア制御チャネルフレームワークパッケージの下のコントロールパッケージサブレジストリを確立します。このサブレジストリ内の新しいパラメータは、IANAの方針[RFC5226]「RFC必須」を使用して、RFC（IETFのいずれかストリームまたは独立提出ストリーム内）に公開する必要があります。
As this document specifies no package or template-package names, the initial IANA registration for Control Packages will be empty. The remainder of the text in this section gives an example of the type of information to be maintained by the IANA.
この文書は何のパッケージまたはテンプレートパッケージ名を指定していないとして、制御パッケージの初期IANA登録は空になります。このセクション内のテキストの残りはIANAによって維持される情報の種類の例を示します。
The table below lists the Control Packages defined in the "Media Control Channel Framework".
以下の表は、「メディア制御チャネルフレームワーク」で定義された制御パッケージを示しています。
Package Name Reference
------------ ---------
example1 [RFCXXXX]
Package Name:
パッケージ名：
(Package names must conform to the syntax described in
Section 8.1.)
Published Specification(s):
公開明細書（S）：
(Control Packages require an RFC.)
（制御パッケージは、RFCが必要です。）
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
This specification establishes the Method Names sub-registry under Media Control Channel Framework Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream).
この仕様は、メディア制御チャネルフレームワークパラメータの下でメソッド名のサブレジストリを確立し、以下のようにその人口を開始します。このサブレジストリ内の新しいパラメータは、（どちらかIETFストリームまたは独立提出ストリームに）RFCで出版されている必要があります。
CONTROL - [RFC6230] REPORT - [RFC6230] SYNC - [RFC6230] K-ALIVE - [RFC6230]
CONTROL - [RFC 6230] REPORT - [RFC 6230] SYNC - [RFC 6230] K-ALIVE - [RFC 6230]
The following information MUST be provided in an RFC in order to register a new Control Framework method:
以下の情報は、新しいコントロールフレームワークのメソッドを登録するために、RFCに提供しなければなりません。
o The method name.
メソッド名O。
o The RFC number in which the method is registered.
Oメソッドが登録されているRFC番号。
This specification establishes the Status Code sub-registry under Media Control Channel Framework Parameters. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined in Section 9. It takes the following format:
この仕様は、メディア制御チャネルフレームワークパラメータの下のステータスコードのサブレジストリを確立します。このサブレジストリ内の新しいパラメータは、（どちらかIETFストリームまたは独立提出ストリームに）RFCで出版されている必要があります。その初期集団は、それは次の形式をとり、セクション9で定義されています。
Code Description Reference
コード説明リファレンス
The following information MUST be provided in an RFC in order to register a new Control Framework status code:
以下の情報は、新しいコントロールフレームワークのステータスコードを登録するために、RFCに提供しなければなりません。
o The status code number.
ステータスコード番号O。
o The RFC number in which the method is registered.
Oメソッドが登録されているRFC番号。
o A brief description of the status code.
Oステータスコードの簡単な説明。
This specification establishes the Header Field sub-registry under Media Control Channel Framework Parameters. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined as follows:
この仕様は、メディア制御チャネルフレームワークパラメータの下でヘッダーフィールドのサブレジストリを確立します。このサブレジストリ内の新しいパラメータは、（どちらかIETFストリームまたは独立提出ストリームに）RFCで出版されている必要があります。次のようにその初期集団が定義されています。
Control-Package - [RFC6230] Status - [RFC6230] Seq - [RFC6230] Timeout - [RFC6230] Dialog-ID - [RFC6230] Packages - [RFC6230] Supported - [RFC6230] Keep-Alive - [RFC6230] Content-Type - [RFC6230] Content-Length - [RFC6230]
コントロール - パッケージ - [RFC6230]ステータス - [RFC6230]配列 - [RFC6230]タイムアウト - [RFC6230]ダイアログ-ID - [RFC6230]パッケージ - [RFC6230]サポートされている - [RFC6230]キープアライブ - [RFC6230]のContent-Type - [RFC6230]のContent-Length - [RFC6230]
The following information MUST be provided in an RFC in order to register a new Channel Framework header field:
以下の情報は、新しいチャネルフレームワークヘッダフィールドを登録するためにRFCに提供しなければなりません。
o The header field name.
ヘッダフィールド名O。
o The RFC number in which the method is registered.
Oメソッドが登録されているRFC番号。
The Control Framework uses TCP port 7563, from the "registered" port range. Usage of this value is described in Section 4.1.
コントロールフレームワークは、「登録された」ポート範囲から、TCPポート7563を使用しています。この値の使用方法は、4.1節に記述されています。
This section describes the media types and names associated with payload formats used by the Control Framework. The registration uses the templates defined in [RFC4288]. It follows [RFC4855].
このセクションでは、コントロールフレームワークによって使用されるペイロードフォーマットに関連付けられたメディアタイプと名前を記載しています。登録は[RFC4288]で定義されたテンプレートを使用しています。これは、[RFC4855]に従います。
Type name: application
型名：アプリケーション
Subtype name: cfw
サブタイプ名：CFW
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Binary and see Section 4 of RFC 6230
エンコードの考慮事項：RFC 6230のバイナリおよび参照第4節
Security considerations: See Section 12 of RFC 6230
セキュリティの考慮事項：RFC 6230のセクション12を参照してください。
Interoperability considerations: Endpoints compliant to this specification must use this MIME type. Receivers who cannot support this specification will reject using appropriate protocol mechanism.
相互運用性に関する注意事項：この仕様に準拠したエンドポイントは、このMIMEタイプを使用する必要があります。この仕様をサポートすることはできませんレシーバは、適切なプロトコル・メカニズムを使用して拒否します。
Published specification: RFC 6230
公開された仕様：RFC 6230
Applications that use this media type: Applications compliant with Media Control Channels.
このメディアタイプを使用するアプリケーション：メディア制御チャネルに準拠したアプリケーション。
Additional Information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none)
追加情報：マジックナンバー（S）：（なし）ファイルの拡張子（S）：（なし）Macintoshファイルタイプコード（S）：（なし）
Person & email address to contact for further information: Chris Boulton <chris@ns-technologies.com>
人とEメールアドレスは、詳細のために連絡する：クリスボールトン<chris@ns-technologies.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: Should be used only in conjunction with this specification, RFC 6230.
使用に関する制限事項：これだけの仕様、RFC 6230と組み合わせて使用する必要があり。
Author: Chris Boulton
著者：クリスボールトン
Change controller: IETF MEDIACTRL working group, delegated from the IESG.
変更コントローラ：IETF MEDIACTRLワーキンググループ、IESGから委任。
13.6.2. Registration of MIME Media Type application/ framework-attributes+xml
13.6.2. MIMEメディアタイプアプリケーション/フレームワークの属性+ XMLの登録
Type name: application
型名：アプリケーション
Subtype name: framework-attributes+xml
サブタイプ名：フレームワークの属性+ xmlの
Required parameters: (none)
必須パラメータ：（なし）
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメータ：アプリケーション/ XMLのcharsetパラメータと同じRFC 3023 [RFC3023]で指定されています。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
符号化の考慮事項：RFC 3023で指定されたアプリケーション/ XMLの考察をコードするものと同じ[RFC3023]。
Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework.
セキュリティの考慮事項：コアメディア制御チャネルフレームワークによって提供されるものの外には知られていないセキュリティ上の考慮事項。
Interoperability considerations: This content type provides common constructs for related Media Control Channel packages.
相互運用性に関する注意事項：このコンテンツタイプは、関連するメディア制御チャネルのパッケージのための一般的な構築物を提供します。
Published specification: RFC 6230
公開された仕様：RFC 6230
Applications that use this media type: Implementations of appropriate Media Control Channel packages.
このメディアタイプを使用するアプリケーション：適切なメディア制御チャネルパッケージの実装。
Additional information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none)
追加情報：マジックナンバー（S）：（なし）ファイルの拡張子（S）：（なし）Macintoshファイルタイプコード（S）：（なし）
Person & email address to contact for further information: Chris Boulton <chris@ns-technologies.com>
人とEメールアドレスは、詳細のために連絡する：クリスボールトン<chris@ns-technologies.com>
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller: The IETF
著者/変更コントローラ：IETF
Other information: None.
その他の情報：なし。
Contact name: Chris Boulton <chris@ns-technologies.com>
担当者名：クリスボールトン<chris@ns-technologies.com>
Attribute name: "cfw-id".
"CFW-ID"：属性名。
Type of attribute Media level.
属性メディアレベルのタイプ。
Subject to charset: Not.
文字セットの件名：ありません。
Purpose of attribute: The 'cfw-id' attribute indicates an identifier that can be used to correlate the Control Channel with the SIP INVITE dialog used to negotiate it, when the attribute value is used within the Control Channel.
属性の目的：「CFW-ID」属性の属性値を制御チャネル内で使用される場合、それを交渉するために使用されるダイアログのINVITE SIPで制御チャネルを相関させるために使用することができる識別子を示します。
Allowed attribute values: A token.
許可された属性値：トークン。
13.8. URN Sub-Namespace for urn:ietf:params:xml:ns:control:framework-attributes
13.8. 骨壷のためのURNサブ名前空間：IETF：のparams：XML：NS：コントロール：フレームワークの属性
IANA has registered a new XML namespace, "urn:ietf:params:xml:ns:control:framework-attributes", per the guidelines in RFC 3688 [RFC3688].
RFC 3688 [RFC3688]のガイドラインごとに、 "フレームワーク - 属性：IETF：のparams：XML：NS：コントロール骨壷" IANAは、新しいXML名前空間を登録しています。
URI: urn:ietf:params:xml:ns:control:framework-attributes
URI：URN：IETF：のparams：XML：NS：コントロール：フレームワークの属性
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
登録者連絡先：IETF MEDIACTRLワーキンググループ<mediactrl@ietf.org>、クリスボールトン<chris@ns-technologies.com>。
XML:
XML：
BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Media Control Channel attributes</title> </head> <body> <h1>Namespace for Media Control Channel attributes</h1> <h2>urn:ietf:params:xml:ns:control:framework-attributes</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt"> RFC 6230</a>.</p> </body> </html> END
BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1- strict.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml」XML：LANG = "EN"> <HEAD> <TITLE>メディア制御チャネルは、</ TITLE> </ HEAD属性> <身体> <H1>メディア制御チャネルのための名前空間の属性</ H1> <H2> URN：IETF：のparams：XML：NS：コントロール：フレームワークの属性</ H2> <P>を参照してください。<HREF = "のhttp：/ /www.rfc-editor.org/rfc/rfc6230.txt "> RFC 6230 </a>にします。</ p> </ body> </ html>このEND
This section registers an XML schema as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:ns:control:framework-attributes
URI：URN：IETF：のparams：XML：NS：コントロール：フレームワークの属性
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
登録者連絡先：IETF MEDIACTRLワーキンググループ<mediactrl@ietf.org>、クリスボールトン<chris@ns-technologies.com>。
Schema: The XML for this schema can be found in Appendix A.1 of this document.
スキーマ：このスキーマのXMLは、このドキュメントの付録A.1で見つけることができます。
Asher Shiratzky from Radvision provided valuable support and contributions to the early versions of this document.
RADVISIONからアッシャーShiratzkyは、このドキュメントの初期のバージョンに貴重な支援と貢献を提供します。
The authors would like to thank Ian Evans of Avaya, Michael Bardzinski and John Dally of NS-Technologies, Adnan Saleem of Radisys, and Dave Morgan for useful review and input to this work. Eric Burger contributed to the early phases of this work.
作者はこの仕事に便利なレビューと入力のためのアバイアのイアン・エヴァンス、マイケルBardzinskiとNS-Technologies社のジョン・ダリー、ラディシスのアドナン・サリーム、とDaveモルガンに感謝したいと思います。エリックバーガーは、この作業の初期段階に貢献しました。
Expert review was also provided by Spencer Dawkins, Krishna Prasad Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided expert guidance on the dialog association mechanism. Lorenzo Miniero has constantly provided excellent feedback based on his work.
専門家のレビューはまたしてもスペンサードーキンスクリシュナプラサドKalluri、ロレンツォMiniero、およびロニによって提供されました。 Hadrielカプランは、ダイアログの関連機構に専門家の指導を提供します。ロレンツォMinieroは常に彼の作品に基づいた優れたフィードバックを提供してきました。
Ben Campbell carried out the RAI expert review on this document and provided a great deal of invaluable input. Brian Weis carried out a thorough security review. Jonathan Lennox carried out a thorough SDP review that provided some excellent modifications. Text from Eric Burger was used in the introduction in the explanation for using SIP.
ベン・キャンベルは、この文書にRAIの専門家のレビューを行い、非常に貴重な入力の多くを提供します。ブライアン・ワイスは、徹底したセキュリティレビューを実施しました。ジョナサン・レノックスは、いくつかの優れた修正を提供する徹底したSDPの見直しを行いました。エリック・バーガーからのテキストは、SIPを使用するための説明への導入に使用しました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[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月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[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）とのオファー/アンサーモデル"。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、RFC 4145、2005年9月。
[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月。
[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月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]レヴィン、O.およびG.キャマリロ、 "セッション記述プロトコル（SDP）label属性"、RFC 4574、2006年8月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、ローレンス、S.、およびA.ジェフリー、 "セッション開始プロトコル（SIP）にドメイン証明書"、RFC 5922、2010年6月。
[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.
[MSCL-THOUGHTS]バーガー、E.、 "メディアサーバ制御言語とプロトコル思考"、進歩、2006年6月での作業。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[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月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発信者が設定"、RFC 3841、2004年8月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]テイラー、T.、 "歴史的にRFC 3525の再分類"、RFC 5125、2008年2月。
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167]ドリー、M.とR.でも、 "メディアサーバー制御プロトコルの要件"、RFC 5167、2008年3月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
Appendix A. Common Package Components
付録A.一般的なパッケージのコンポーネント
During the creation of the Control Framework, it has become clear that there are a number of components that are common across multiple packages. It has become apparent that it would be useful to collect such reusable components in a central location. In the short term, this appendix provides the placeholder for the utilities, and it is the intention that this section will eventually form the basis of an initial 'Utilities Document' that can be used by Control Packages.
コントロールフレームワークの作成時に、それが複数のパッケージに共通するコンポーネントの数があることが明らかになりました。中央の場所でそのような再利用可能なコンポーネントを収集するために有用であることが明らかになりました。短期的には、この付録では、ユーティリティのためのプレースホルダを提供し、そしてこのセクションでは、最終的に制御パッケージで使用することができ、最初の「ユーティリティドキュメント」の基礎を形成することを意図しています。
A.1. Common Dialog/Multiparty Reference Schema
A.1。コモンダイアログ/マルチパーティリファレンススキーマ
The following schema provides some common attributes for allowing Control Packages to apply specific commands to a particular SIP media dialog (also referred to as "Connection") or conference. If used within a Control Package, the Connection and multiparty attributes will be imported and used appropriately to specifically identify either a SIP dialog or a conference instance. If used within a package, the value contained in the 'connectionid' attribute MUST be constructed by concatenating the 'Local' and 'Remote' SIP dialog identifier tags as defined in [RFC3261]. They MUST then be separated using the ':' character. So the format would be:
次のスキーマは、制御パッケージは、特定のSIPメディアダイアログ（また、「接続」とも呼ばれる）や会議に特定のコマンドを適用することを可能にするためのいくつかの共通の属性を提供します。制御パッケージ内で使用される場合は、接続とのマルチパーティの属性がインポートされ、特にSIPダイアログや会議のインスタンスのいずれかを識別するために適切に使用されます。パッケージ内で使用される場合、「connectionid」属性に含まれる値は、[RFC3261]で定義されるように「ローカル」と「リモート」SIPダイアログ識別子タグを連結することによって構築されなければなりません。 「：」文字次に、これらを用いて分離されなければなりません。だから、フォーマットは次のようになります。
'Local Dialog tag' + ':' + 'Remote Dialog tag'
「ローカルダイアログタグ」+「：」+「リモートダイアログのタグ」
As an example, for an entity that has a SIP Local dialog identifier of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 'connectionid' attribute for a Control Framework command would be:
例として、「7HDY839」のSIPローカルダイアログ識別子と「HJKSkyHS」のリモートダイアログ識別子を持つエンティティに対して、コントロールフレームワークのコマンドのための「connectionid」属性は次のようになります。
7HDY839:HJKSkyHS
Hadadas：Hjkskihs
It should be noted that Control Framework requests initiated in conjunction with a SIP dialog will produce a different 'connectionid' value depending on the directionality of the request; for example, Local and Remote tags are locally identifiable.
SIPダイアログと一緒に開始コントロールフレームワークの要求は、要求の方向に応じて、異なる「connectionid」の値が生成されることに留意すべきです。例えば、ローカルおよびリモートのタグが局部的に識別可能です。
As with the Connection attribute previously defined, it is useful to have the ability to apply specific Control Framework commands to a number of related dialogs, such as a multiparty call. This typically consists of a number of media dialogs that are logically bound by a single identifier. The following schema allows for Control Framework commands to explicitly reference such a grouping through a 'conferenceid' XML container. If used by a Control Package, any control XML referenced by the attribute applies to all related media dialogs. Unlike the dialog attribute, the 'conferenceid' attribute does not need to be constructed based on the overlying SIP dialog. The 'conferenceid' attribute value is system specific and should be selected with relevant context and uniqueness.
以前に定義された属性の接続と同様に、そのようなマルチパーティコールなどの特定のコントロールフレームワークは、関連するダイアログの数にコマンドを適用する機能があると便利です。これは、一般的に、論理的に単一の識別子により拘束されているメディア・ダイアログの数で構成されています。コントロールフレームワークは、明示的に「conferenceid」XML容器を通してそのようなグルーピングを参照するためにコマンドの次のスキーマを可能にします。制御パッケージで使用される場合は、属性によって参照される制御XMLは、関連するすべてのメディア・ダイアログに適用されます。ダイアログ属性とは異なり、「conferenceid」属性は、その上のSIPダイアログに基づいて構成されている必要はありません。 「conferenceid」属性値は、システム固有のものであり、関連するコンテキストとユニークさを選択する必要があります。
It should be noted that the values contained in both the 'connectionid' and 'conferenceid' identifiers MUST be compared in a case-sensitive manner.
connectionid 'と「conferenceid」識別子の両方に含まれる値は、大文字と小文字が区別方法で比較しなければならないことに留意すべきです。
The full schema follows:
完全なスキーマは次のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns::control:framework-attributes" elementFormDefault="qualified" attributeFormDefault="unqualified">
<XSD：スキーマのtargetNamespace = "URN：IETF：paramsは：XML：NS：コントロール：フレームワーク属性" のxmlns：のxsd = "http://www.w3.org/2001/XMLSchema" のxmlnsは=「URN：IETF：paramsは：XML：NS ::コントロール：フレームワークの属性」のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<XSD：属性名= "connectionid" タイプ= "のxsd：文字列" />
<xsd:attribute name="conferenceid" type="xsd:string"/>
<XSD：属性名= "conferenceid" タイプ= "のxsd：文字列" />
</xsd:attributeGroup> </xsd:schema>
</ XSD：attributeGroupの> </ XSD：スキーマ>
Authors' Addresses
著者のアドレス
Chris Boulton NS-Technologies
クリスボールトンNSテクノロジーズ
EMail: chris@ns-technologies.com
メールアドレス：chris@ns-technologies.com
Tim Melanchuk Rainwillow
ティムMelanchuk Rainwillow
EMail: timm@rainwillow.com
メールアドレス：timm@rainwillow.com
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
スコットMcGlashanヒューレット・パッカードグスタフIII大通り36 SE-16985ストックホルム、スウェーデン
EMail: smcg.stds01@mcglashan.org
メールアドレス：smcg.stds01@mcglashan.org