[要約] RFC 6230は、メディア制御チャネルフレームワークに関する標準化ドキュメントであり、メディアストリームの制御と管理を容易にするためのプロトコルを提供します。目的は、異なるメディア制御プロトコル間の相互運用性を確保し、効率的なメディア制御の実現を促進することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 [RFC5125]などの現在のIETFデバイス制御プロトコルは、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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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つのメソッドが定義されています：同期、制御、レポート、およびKアリーブ。
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] Exchangeを使用して、信頼できる輸送接続チャネルを確立、使用、および終了するメカニズムを詳述しています。確立された接続は、外部サーバーの制御に使用されます。次のテキストは、使用されるメカニズムの非規範的な概要を提供します。詳細な規範的なガイドラインは、文書の後半で提供されています。
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考え]で文書化されているように、制御フレームワークの初期分析が以下を確立しました。「メディアサーバーを制御するためのTCP接続を確立するだけなら、なぜSIPが必要なのか」と尋ねるかもしれません。これは合理的な質問です。重要なのは、メディアセッションの確立にSIPを使用することです。メディアセッションの確立にSIPを使用している場合、セッション設立に使用されるURIがセッション制御用のノードと同じノードに解決するようにする必要があります。SIPルーティングメカニズムを使用し、サーバーにTCP接続を開始させると、これが機能するようになります。たとえば、uri sip：myserver.example.comは、sip：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をセッション制御プロトコルとして使用することの主な利点の1つは、提供される「サービス場所」施設です。これは、[RFC3263]がデバイスの物理的位置を提供するルーティングレベルで、および発信者の設定[RFC3840]とCallee機能[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の接続を伝えています。必要に応じて、クライアントは、制御クライアントと制御サーバーエンティティ間の個別の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: [..]
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
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).
招待リクエストを受信すると、このメカニズムをサポートする外部サーバーは、適切なSDPを含む200 OK応答を生成し、このドキュメントで指定されたアプリケーション/CFW MIMEタイプを使用してフォーマットされます。サーバーは、独自の「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
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/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
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の招待ダイアログ使用のインタラクションと関連するメディアフローを表しています。ユーザーエージェントは、制御クライアントエンティティを使用したSIP Inviteダイアログ使用を作成します。Control Client Entityは、B2BUAタイプの機能を使用して、Control ServerにSIP Inviteダイアログ使用を作成します。（2）が示す相互作用を使用して、Controlクライアントは、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が制御チャネルの確立を希望する場合、コントロールチャネルセットアップの新しいSIP招待リクエストを構築および送信する必要があります。UACは、[RFC3261]で定義されているように招待要求を作成する必要があります。
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]で定義されている信頼できる応答が受信された場合、このドキュメントで定義されているメカニズムは、新しく作成されたSIP Inviteダイアログ使用に適用されます。
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]で定義されたセッション説明プロトコルを使用した招待リクエストに、有効なセッション説明（[RFC3264]で定義されている「オファー」）を含める必要がありますが、[RFC3261]に従ってオファーレスの招待状を選択する場合があります。SDPは、以下の手順に従ってフォーマットし、セクション13に登録されているMIMEタイプアプリケーション/ CFWを使用する必要があります。次の情報は、SIPで使用する場合に提供者が付着する必要があるSDPペイロードの特定の要素の構成を定義します。-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>
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番目のサブフィールドは<connection-address>です。これにより、DNS/IP表現など、SDPオリジネーターの住所の表現が提供されます。アドレスは、接続に使用されるアドレスです。
Example:
例：
c=IN IP4 controller.example.com
C = IP4 Controller.example.com
The SDP MUST contain a corresponding Media Description entry:
SDPには、対応するメディアの説明エントリを含める必要があります。
m=<media> <port> <proto> <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".
最初の「サブフィールド」、<media>は、値「アプリケーション」に等しくなければなりません。2番目のサブフィールド<port>は、必要に応じて、構築クライアントが着信接続を受信できるポートを表す必要があります。ポートは、接続の詳細を提供するために以前に定義された接続データ行で指定されたアドレスと組み合わせて使用されます。SDPを構築するエンティティが着信接続を受信できない場合、有効なポートエントリを入力する必要があります。ポート値「0」の使用は、SIPオファー/回答交換[RFC3264]で定義されているものと同じ意味を持っています。制御フレームワークには、セクション13.5で定義されたデフォルトのポートがあります。この値はデフォルトですが、クライアントは明示的なポート番号を自由に選択できます。ただし、SDPは、ローカルポリシーがその使用を禁止している場合を除き、デフォルトのポート番号を使用する必要があります。デフォルトのポート番号を使用すると、ネットワーク管理者は制御フレームワークの相互作用のためのファイアウォールポリシーを管理できます。この仕様に準拠した3番目のサブフィールド<proto>は、値「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メディア属性（a =）も含める必要があります。属性は、接続交渉とメンテナンスパラメーターを提供します。制御UACは外部サーバーへの接続を開始するが、ネットワークトポロジが特定の方向に接続を開始することを禁止する場合、外部サーバーがコメディアを使用して接続を交渉して開始することをお勧めします。コメディア属性の例は次のとおりです。
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ペイロードの完全な例は、セクション3で表示できます。SDPは、SIP招待リクエストの残り（[RFC3261]で定義）とともに構築されたら、適切な場所に送信できます。。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.
オファーを構築するSIP UACには、セクション9.2で定義されている「CFW-ID」SDP属性を含める必要があります。「CFW-ID」属性は、制御チャネル内で使用してコントロールチャネルをこのSIP Inviteダイアログ使用と相関させることができる識別子を示します。「CFW-ID」属性は、UACとUAS間の相互作用のコンテキストで一意でなければならず、他のSIPオファー/回答交換で使用されている「CFW-ID」のインスタンスと衝突してはなりません。「CFW-ID」属性に選択された値は、関連するSIP Inviteダイアログの使用の期間中に使用され、オファー/回答の交換の更新中に変更されない必要があります。これは、[RFC4145]で定義されている「接続」属性に特異的に適用されます。SIP UACがSDPの他の部分を変更したいが、すでに確立された接続を再利用する場合、「接続」属性（たとえば、a = connection：既存）で「既存」の値を使用します。接続が失敗し、接続を再確立したいことに留意した場合、「接続」属性（たとえば、a = connection：new）で「新しい」値を使用します。これを通して、「CFW-ID」SDPパラメーターで指定された接続識別子は変更してはなりません。1つは、エンドポイント間の基礎となるTCP接続を単純に交渉することですが、SIP Inviteダイアログ使用の寿命に1：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".
招待状リクエストで受信した非2xxクラスの最終SIP応答（3xx、4xx、5xx、および6xx）は、SIP Invite Invite Dialogの使用が作成されておらず、SIP [RFC3261]で指定されているように扱われていることを示しています。具体的には、この仕様のサポートは、この仕様で定義されているメディアタイプの存在を通じて交渉されます。「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オファーは最初の招待要求に限定されておらず、[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ペイロードは、有効なローカル設定を使用してセクション4.1で定義されたセマンティック（接続、メディア、および属性）を使用して構築する必要があります。たとえば、セクション4.1で提供されているサンプルオファー用に作成された回答に含まれるSDP属性は、次のように見えます。
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 Inviteダイアログの使用の期間中に使用され、オファー/回答の交換の更新中に変更されない必要があります。
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 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.
SDP回答が構築されると、標準のSIPメカニズムを使用して送信されます。オファー/回答の交換を使用して交渉されたSDPペイロードの内容に応じて、制御UACと外部サーバーUASエンティティの間に信頼できる接続が確立されます。新しく確立された接続は、コントロールコマンドプリミティブを交換するために利用できるようになりました。SIPの招待ダイアログの使用状況と関連する制御チャネルの状態は、暗黙的にリンクされました。いずれかの当事者がコントロールチャネルを終了することを希望する場合、SIP終了要求（たとえば、SIP Byeリクエストまたは早期SIP招待ダイアログの使用で適切な応答）を発行するだけです。したがって、コントロールチャネルは、SIP招待ダイアログの使用期間中に存在します。
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.
SIPオプション要求を受信するUASは、[RFC3261]で定義されているように適切に応答する必要があります。UASには、SIP 200 OK応答でサポートされているメディアタイプをSIP「Accept」ヘッダーに含めて、有効なメディアタイプを示す必要があります。
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に招待するダイアログは、複数のメディアの説明（SDPの「M =」で定義されている）を含むことができます。[RFC4574]で定義されているように、コントロールフレームワークを使用してエンティティに向けられる[M =]定義ごとに、[RFC4574]で定義されているメディアラベル属性を含める必要があります。これにより、制御クライアントは、特定のメディアライン（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.
同様に、関連するメディアダイアログのグループ（Multiparty）のグループにコマンドを識別して適用する機能も、定義および再利用できる共通構造として特定されています。たとえば、会議のすべての参加者にプロンプトを再生します。このような操作のスキーマは、付録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.
このドキュメントでは、Comedia仕様を使用することで、SIP Invite Transactionの結果として、制御チャネルをどちらの方向にも設定できます。SIPは、制御チャネルを確立するための柔軟なネゴシエーションメカニズムを提供しますが、制御チャネル内には、設立のために実装されたSIP Inviteダイアログ使用量と相関するメカニズムが必要です。着信接続を受信するコントロールクライアント（UACまたはUASの役割で行動するかどうか）は、特定のポートのすべての着信接続を聞くだけであるため、関連するSIP Invite Dialogの使用を識別する方法がありません。実装をサポートする必要がある次の手順では、UA（つまり、Comediaでアクティブな役割を持つUA）を接続することができ、関連するSIP Inviteダイアログの使用が接続をトリガーしたことを特定できます。使用される代替ダイアログ関連メカニズムがない限り、UASは、新しく作成された制御チャネルで他のシグナリングの前にこれらの手順を実行する必要があります。
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）で動作するUAは、制御フレームワーク同期要求を送信する必要があります。同期要求は、セクション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 「Dialog-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 同期要求を作成すると、アクティブ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 同期要求を作成すると、アクティブ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は、同期要求を送信する必要があります。接続作成のアクティブな役割のUAがSIP UASであり、2xxクラスのSIP応答でSDP応答を生成した場合、同期を発行する前に着信SIP ACKメッセージを待つ必要があります。接続作成のアクティブな役割のUAがSIP UASであり、信頼できる1XXクラスSIP応答でSDP応答を生成した場合、同期を発行する前に着信SIPプラックメッセージを待つ必要があります。
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である場合、制御チャネルの確立時に同期メッセージをすぐに送信する必要があります。その後、少なくとも2*'トランザクションタイムアウト'の期間が応答を受信するのを待つ必要があります。待つ時間が長くなるかもしれませんが、「トランザクションタイムアウト」よりも短くてはなりません。一般に、制御フレームワークトランザクションは20（2*'Transaction-Timeout'）秒以内に完了する必要があり、ドキュメント全体で「トランザクションタイムアウト」と参照されます。
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.
o 同期メッセージに対して応答がない場合、タイムアウトが発生し、コントロールチャネルは、関連するSIP Inviteダイアログの使用とともに終了します。Active UAは、SIP Inviteダイアログの使用を終了するために、さようならリクエストを発行する必要があります。
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.
o アクティブなUAがパッシブUAから481の応答を受信した場合、これは同期要求が受信されたことを意味しますが、同期メッセージで指定された関連する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.
o 同期要求に対して受信した他のすべてのエラー応答は、この仕様の詳細として扱われ、コントロールチャネルの終了と関連するSIP招待ダイアログの使用も行われます。Active UAは、SIP Inviteダイアログの使用を終了するために、さようならリクエストを発行する必要があります。
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 同期メッセージに対する200の応答の受領は、SIPがダイアログの使用と制御接続が正常に相関していることを意味します。コントロールチャネルをさらに相互作用するために使用できるようになりました。
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.
同期メッセージは、最初の交換が完了すると、どちらの側からも制御チャネルが開いている間、任意の時点で送信できます。存在する場合、「キープアライブ」と「ダイアログアイド」ヘッダーの内容が変更されてはなりません。「Keep-Alive」と「Dialog-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でネゴシエートされたコントロールパッケージによって定義された構文にも付着する必要があります。コントロールクライアントは、リクエストに挿入するための一意のトランザクションと関連する識別子を作成する必要があります。トランザクション識別子は、セクション9のABNFで定義されているように、メソッドタイプとともにコントロールフレームワークメッセージの最初の行に含まれます。最初の行は、トランザクション識別子を簡単に抽出する目的で「CFW」トークンで始まります。トランザクション識別子は、制御クライアントと制御サーバー間の相互作用のコンテキストで一意でなければなりません。このユニークなプロパティは、複数のクライアントエンティティが単一の受信サーバーで実行されるトランザクションを作成する可能性がある場合の衝突を回避するのに役立ちます。必要なすべて、必須、およびオプションの制御フレームワークヘッダーが、適切な値でリクエストに挿入されます（明示的な詳細については、関連する個別のヘッダー情報を参照してください）。「コントロールパッケージ」ヘッダーは、この特定の要求が適用される制御パッケージを示す値で挿入する必要があります。セクション6.3.4.2で説明した同期メッセージを使用して、制御チャネルごとに複数のパッケージをネゴシエートできます。
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タイプと、次のように表されるメッセージ本文のサイズを示す「コンテンツタイプ」および「コンテンツ長」メッセージヘッダーも含める必要があります。それぞれ10進数のオクテット数。関連するペイロードがメッセージに追加されない場合、「コンテンツ長」ヘッダーには「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.
コントロールサーバーとして機能するエンティティは、リクエストを受信すると、制御クライアントから測定された「トランザクションタイムアウト」内で応答を生成する必要があります。応答は、セクション9で定義されているABNFに準拠する必要があります。応答の最初の行には、セクション6.1で定義されているように、リクエストの最初の行で使用されるトランザクション識別子を含める必要があります。応答には、「ステータス」または「タイムアウト」メッセージヘッダーを含めるものではありません。これらは、クライアントが応答で受け取った場合は無視する必要があります。
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の応答には、メッセージ本文が含まれる場合があります。応答にペイロードが含まれている場合、メッセージには「コンテンツ長」と「コンテンツタイプ」ヘッダーを含める必要があります。制御クライアントが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.
コントロールサーバーがコントロールなどのリクエストを受信し、サーバーが理解しているが、サーバーがコマンドの処理が「トランザクションタイムアウト」を超えることを知っている場合、サーバーは応答の最初の行で202ステータスコードで応答する必要があります。最初の応答に続いて、サーバーはセクション6.3.2で説明されているように1つ以上のレポートメッセージを送信します。制御パッケージは、サーバーが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.
コントロールサーバーがコントロールフレームワークリクエスト（レポートやコントロールなど）で問題に遭遇する場合、セクション7にリストされているように、応答で適切なエラーコードを使用する必要があります。リクエスト（コントロールやレポートなど）は、トランザクションの障害を示し、関連するすべてのトランザクション状態とリソースを終了する必要があります。応答コードは、トランザクションが失敗した理由の明示的な指標を提供する場合があり、その結果、使用されている拡張機能パッケージに応じてリクエストが再提出される可能性があります。
The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods.
制御フレームワークは、4種類のリクエスト（メソッド）を定義します。コントロール、レポート、Kアリブ、および同期。実装は、これらの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で定義されている形式に準拠する必要があります。ペイロードを含むコントロールメッセージには、「コンテンツタイプ」ヘッダーを含める必要があります。ペイロードは、制御パッケージによって定義されたペイロードタイプの1つでなければなりません。個々のパッケージでは、ペイロードが含まれていないコントロールメッセージを許可する場合があります。これは実際、特定のパッケージ内の有効なメッセージ交換である可能性があります。そうでない場合は、適切なパッケージレベルのエラーメッセージを生成する必要があります。
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.
「レポート」メッセージは、クライアントから測定されたように、制御コマンドの処理が「トランザクションタイムアウト」を超えて拡張されるときに制御サーバーによって使用されます。この場合、サーバーは202の応答を返します。サーバーは、後続のレポートメッセージでステータスの更新とコマンドの最終結果を返します。
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.
すべてのレポートメッセージは、元の制御トランザクションに存在するリクエスト開始行に同じトランザクションIDを含める必要があります。これにより、拡張トランザクションは元の制御トランザクションと相関しています。ペイロードを含むレポートメッセージには、コントロールパッケージとペイロードの長さで定義されたペイロードMIMEタイプ[RFC2045]を示す「コンテンツタイプ」および「コンテンツ長」ヘッダーを含める必要があります。
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.
最初のレポートメッセージには、「1」に等しい値を持つ「seq」（sequence）メッセージヘッダーを含める必要があります。注：フレームワークメッセージのコントロールクライアントサーバーとコントロールサーバーの両方の「SEQ」番号は独立しています。
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.
拡張制御トランザクションのすべてのレポートメッセージには、「タイムアウト」メッセージヘッダーが含まれている必要があります。このヘッダーには、レポートメッセージの受信者が問題があると仮定し、延長トランザクションと関連状態を終了する前に待つ必要がある時間である秒単位で値が含まれます。「更新」の「ステータス」ヘッダーを使用してレポートメッセージを受信すると、コントロールクライアントは、関連する拡張制御トランザクションのタイマーを指定されたタイムアウト期間までリセットする必要があります。タイムアウト期間が近づき、意図されたレポートメッセージが生成されていない場合、相互作用の制御フレームワークUASとして機能するエンティティは、この段落で定義されているように、関連するNOが関連付けられていない「更新」の「ステータス」ヘッダーを含むレポートメッセージを生成する必要があります。ペイロード。このようなメッセージは、タイムアウトの更新として機能し、メッセージボディやセマンティクスが許可されていないため、拡張トランザクションに影響を与えません。「タイムアウト」メッセージヘッダーの値には、最小値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.
拡張制御トランザクションに関連する追加情報を提供する後続のレポートメッセージは、「seq」ヘッダー値を含む必要があります。1によって増分されていないレポートメッセージは、406応答で応答する必要があり、拡張トランザクションは終了したと見なされる必要があります。406の応答を受信すると、拡張トランザクションを終了する必要があります。レポートメッセージには、「更新」の値を持つ「ステータス」ヘッダーも含める必要があります。拡張制御トランザクションステータスを更新するために送信されたこれらのレポートメッセージには、個々の制御パッケージで定義され、セクション8.5で指定されているように、メッセージ本文が含まれている場合があります。このセクションで前述のように、拡張トランザクションを更新するレポートメッセージは、タイムアウトの更新としても機能します。これにより、「タイムアウト」メッセージヘッダーに含まれる間隔にリセットされる元の制御要求の開始者でのトランザクションタイムアウト期間が得られます。
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.
拡張制御トランザクションのすべての処理が行われた場合、制御サーバーとして機能するエンティティは終了レポートメッセージを送信する必要があります。終了レポートメッセージは、以前のレポートメッセージから「1」の値で「seq」メッセージヘッダーの値を増分する必要があります。また、「終了」の値を持つ「ステータス」ヘッダーを含める必要があり、メッセージ本文が含まれている場合があります。また、有効な値を持つ「タイムアウト」メッセージヘッダーを含める必要があります。「タイムアウト」ヘッダーを含めることは一貫性であり、その値は無視されます。制御フレームワーク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 Keep-Aliveメカニズムに関する詳細については、実装者は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 Invite Dialogの使用法が確立されると、セクション6で説明されている同期を使用した初期相関ハンドシェイクを含む基礎となる制御チャネルが設定されました。制御チャネル同期要求/応答交換中にネゴシエートされた値に等しいキープアライブタイマーを起動する必要があります。これは、数秒で「キープアライブ」ヘッダーからの値です。
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 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アライブメッセージを生成する必要があります。アクティブなエンティティは、選択するたびにKアライブメッセージを無料で送信できます。エンティティがローカルキープタイマーの80％の後にKアライブメッセージを発行することをお勧めします。Kアライブリクエストの200 OKコントロールフレームワークメッセージを受信すると、アクティブなエンティティはローカルキープアライブタイマーをリセットする必要があります。Kアライブメッセージへの200 OK応答がない場合、または地元のキープタイマー火災の前に、他の手段によってトランスポートレベルの問題が検出された場合、アクティブなエンティティはコメディアの再交渉手順を使用して接続を回復する場合があります。。それ以外の場合、アクティブなエンティティは、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アライブメッセージを受信する必要があります。Kアライブリクエストを受信すると、パッシブエンティティは200 OKコントロールフレームワーク応答を生成し、ローカルキープアライブタイマーをリセットする必要があります。他の制御フレームワーク応答は有効ではありません。ローカルキープアライブタイマー火災の前に、Kアライブメッセージが受信されない場合（または他の手段によって輸送レベルの問題が検出されます）、パッシブエンティティは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.
制御チャネルの初期同期要求は、制御チャネルのキープアライブメカニズムのタイムアウト期間をネゴシエートし、クライアントとサーバーが各サポートの制御パッケージを学習できるようにするために使用されます。後続の同期要求を使用して、制御チャネルで使用できる制御パッケージのセットを変更することができます。
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:
初期同期要求により、制御チャネルのキープアライブメカニズムのタイムアウト期間を交渉できます。最初の同期要求については、次のルールに従う必要があります。
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.
o SDPオファーを開始するクライアントがアクティブに等しいコメディア「セットアップ」属性を持っている場合、「キープアライブ」ヘッダーは、提供者によって生成された同期メッセージに含める必要があります。「キープアライブ」ヘッダーの値は、95〜120秒の範囲でなければなりません（これはSIPアウトバウンド[RFC5626]と一致しています）。「キープアライブ」ヘッダーの値は、600秒を超えてはなりません。SDPの「Answer」（パッシブクライアント）を生成したクライアントは、「Keep-Alive」ヘッダーを同じ値で同期メッセージに対する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 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.
o SDPオファーを開始するクライアントがパッシブに等しいコメディア「セットアップ」属性を持っている場合、「キープアライブ」ヘッダーパラメーターは、回答者によって生成された同期メッセージに含める必要があります。「キープアライブ」ヘッダーの値は、95〜120秒の範囲でなければなりません。SDPオファー（パッシブクライアント）を生成したクライアントは、「キープアライブ」ヘッダーを同じ値で同期メッセージに対する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.
o SDPオファーを開始するクライアントが「ActPass」に等しいコメディアの「セットアップ」属性を持っている場合、「Keep-Alive」ヘッダーパラメーターは、SDPセッションのアクティブな参加者であるエンティティの同期メッセージに含める必要があります。後続のSDP回答を生成するクライアントがComedia SDP 'Setup'属性に「アクティブ」の値を配置すると、同期要求が生成され、「キープアライブ」ヘッダーが含まれます。値は95〜120秒の範囲でなければなりません。後続のSDP回答を生成するクライアントがコメディア「セットアップ」属性に「パッシブ」の値を配置する場合、SDPを作成する元のUAが同期要求を生成し、「キープアライブ」ヘッダーを含めます。値は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.
o 最初の交渉されたオファー/回答がコメディア「セットアップ」属性が「HoldConn」に等しい属性をもたらす場合、オファー/回答の交換が更新され、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アライブメッセージを生成するのは、常に接続の開始者になります。
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.
交渉すると、Keep-Alive Timeoutは、コントロールフレームワークセッションの残りの部分に適用されます。コントロールチャネルで生成された後続の同期メッセージは、セッションの交渉されたキープアライブプロパティに影響を与えません。「Keep-Alive」ヘッダーは、後続の同期メッセージに含まれてはなりません。受信した場合は、無視する必要があります。
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.
同期メッセージ交換の一部として、リクエストを生成するクライアントには、セクション9で定義されている「パッケージ」ヘッダーを含める必要があります。「パッケージ」ヘッダーには、この制御セッション内でサポートできるすべての制御フレームワークパッケージのリストが含まれています。同期メッセージを作成するクライアントの視点。すべてのチャネルフレームワークパッケージ名は、セクション8に記載されているルールに付着するトークンでなければなりません。初期同期メッセージの「パッケージ」ヘッダーには、少なくとも1つの値を含める必要があります。
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.
初期同期要求を受信するサーバーは、「パッケージ」ヘッダーの内容を調べる必要があります。サーバーがリクエストにリストされているパッケージの少なくとも1つをサポートする場合、200の応答コードで応答する必要があります。応答には、リクエストの「パッケージ」ヘッダー（すべてまたはサブセット）からのサポートされているパッケージをリストする「パッケージ」ヘッダーを含める必要があります。このリストは、両当事者によってサポートされている共通の制御パッケージセットを形成します。同期要求の「パッケージ」ヘッダーにリストされていないサーバーでサポートされているコントロールパッケージは、応答の「サポートされている」ヘッダーに配置できます。これにより、サーバーがサポートする追加のパッケージに関する同期リクエストを生成したクライアントにヒントを提供します。
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].
同期メッセージを受信するサーバーによって一般的なパッケージがサポートされていない場合、422エラー応答コードで応答する必要があります。エラー応答には、サポートされているパッケージを示す「サポートされた」ヘッダーを含める必要があります。開始クライアントは、422の応答に基づいて新しい同期メッセージを再サブリットするか、相互作用を障害を考慮することを選択できます。これにより、[RFC3261]に従って、SIP Byeリクエストを送信することにより、関連するSIP Inviteダイアログの終了につながります。
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.
初期同期トランザクションが完了すると、いずれかのクライアントが、コントロールチャネル内でサポートされているパッケージを再交渉するために、後続の新しい同期メッセージを送信することを選択できます。「パッケージ」ヘッダーが以前の同期メッセージとは異なる値を持つ新しい同期メッセージは、制御チャネルで使用されるパッケージを効果的に追加および削除できます。後続の同期メッセージを受信しているクライアントがパッケージのセットを変更することを望まない場合、421 Control Framework Responseコードで応答する必要があります。後続の同期メッセージは、元の同期交渉に登場した「ダイアログアイド」および「キープアライブ」制御フレームワークヘッダーの値を変更してはなりません。
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を生成してはならないことを除き、コントロールメッセージとレポートメッセージの両方に応じて使用できます。
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.
これらの応答コードは、フレームワークトランザクションのみに適用されることに注意してください。制御コマンドの成功またはエラーの表示は、コントロールコマンドの結果として扱われ、200回の応答またはレポートメッセージのいずれかで返される必要があります。
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で定義されたレポートメカニズムを介して追加情報が後で提供されます。
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.
受信者は、同期メッセージにリストされている制御パッケージをサポートしていません。
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.
リクエストの取引は存在しません。同期要求に応じて、481応答コードは、対応するSIP招待ダイアログの使用が存在しないことを示します。
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.
制御パッケージこのドキュメントで定義されている機能を拡張する動作を指定します。制御パッケージは、このドキュメントの「必須」と「必要」のステートメントを弱めてはなりません。制御パッケージは、フレームワークの特定の使用法によって正当化された場合、「Suff」、「推奨」、および「可能性」を強化する場合があります。
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スキーマがサポートされる場合、強力なステートメント（RFC 2119 [RFC2119]の言語を使用）を作成します。スキーマの一部のみが必要な場合（たとえば、「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で定義されているように、コントロールコマンドリクエスト内に含めることができる、またはコントロールパッケージ本体が不要であることをコントロールボディを定義します。このセクションでは、コントロールコマンドリクエスト、およびオプションで関連する200応答に適用される適切なMIME [RFC2045]ボディタイプの詳細な構文定義とセマンティクスの位置を示す必要があります。コントロールパッケージ本体を持たないコントロールパッケージの場合、そのようなステートメントを作成すると、コントロールパッケージドキュメントのこのセクションの「必須」強度を満たします。
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で定義されているように、レポートコマンドリクエストに含めることができるレポート本文を定義します。このセクションでは、適切なMIME [RFC2045]ボディタイプの詳細な構文定義とセマンティクスの位置を示している必要があります。制御フレームワークの仕様では、コントロールメッセージに対する200の応答にペイロードが存在することができることに注意してください（このドキュメントで定義されています）。レポートメッセージでペイロードタイプを受信するために準備されたエンティティは、コントロールメッセージに対する200の応答で同じペイロードを受信するために準備する必要があります。コントロールパッケージ本体を持たないコントロールパッケージの場合、そのようなことは、コントロールパッケージドキュメントのこのセクションの「必須」強度を満たすことを述べています。
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).
o ペイロードの監査クエリと応答形式の場所（たとえば、それは別のXMLスキーマまたはより大きなXMLスキーマの一部である可能性があります）。
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変換形式を使用します。このセクションの構文では、[rfc5234]で定義されているように、「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
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
other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF
header-name = (Content-Length
/Content-Type
/Control-Package
/Status
/Seq
/Timeout
/Dialog-ID
/Packages
/Supported
/Keep-alive
/ext-header)
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
dialog-id-string = alpha-num-token package-name = alpha-num-token supprtd-alphanum = alpha-num-token kalive-seconds = 1*DIGIT
dialog-id-string = alpha-num-token package-name = alpha-num-token supprtd-alphanum = alpha-num-token kalive-seconds = 1*digit
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
control-content = *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
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 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
ext-header = hname ":" SP hval CRLF
ext-header = hname "：" sp hval crlf
hname = ALPHA *token hval = utf8text
hname = alpha *token hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From 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-name = token
token = 1*(token-char)
token-char = %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.
トークンcharおよびトークン要素は[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応答コードを返してトランザクションを拡張します。。その後、コントロールサーバーは、要求されたアクションが完了するまでレポートに従います。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
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
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
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
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
(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接続を開きます。接続を使用して、制御フレームワークメッセージを交換できるようになりました。制御クライアント - >コントロールサーバー（コントロールフレームワークメッセージ）：同期。
CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0
CFW 8DJAE7KHAUJ SYNC DIALOG-ID：FNDSKUHKSD783HJDLA KEEP-ALIVE：100パッケージ：MSC-IVR-Basic/1.0
(5) Control Server-->Control Client (Control Framework message): 200.
(5) コントロールサーバー - > Control Client（Control Frameworkメッセージ）：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 Keep-Alive：100パッケージ：MSC-IVR-Basic/1.0サポート：MSC-IVR-VXML/1.0、MSC-CONF-AUDIO/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) 同期プロセスが完了すると、接続を使用して制御フレームワークメッセージを交換できるようになりました。制御クライアント - >コントロールサーバー（制御フレームワークメッセージ）：コントロール。
CFW i387yeiqyiq CONTROL
Control-Package: <package-name>
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/>
<xml blob/>
(7) Control Server-->Control Client (Control Framework message): 202.
(7) 制御サーバー - > Control Client（Control Frameworkメッセージ）：202。
CFW i387yeiqyiq 202 Timeout: 10
CFW I387YEIQYIQ 202タイムアウト：10
(8) Control Server-->Control Client (Control Framework message): REPORT.
(8) 制御サーバー - > Control Client（Control Frameworkメッセージ）：レポート。
CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10
CFW i387yeiqyiqレポートseq：1ステータス：更新タイムアウト：10
(9) Control Client-->Control Server (Control Framework message): 200.
(9) 制御クライアント - >コントロールサーバー（コントロールフレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 1
CFW i387yeiqyiq 200 seq：1
(10) Control Server-->Control Client (Control Framework message): REPORT.
（10）制御サーバー - > Control Client（Control Frameworkメッセージ）：レポート。
CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFW I387YEIQYIQレポートSEQ：2ステータス：更新タイムアウト：10 Content-Type：Example_Content/Example_Contentコンテンツレングス：11
<XML BLOB/>
<xml blob/>
(11) Control Client-->Control Server (Control Framework message): 200.
（11）制御クライアント - >コントロールサーバー（制御フレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 2
CFW i387yeiqyiq 200 seq：2
(12) Control Server-->Control Client (Control Framework message): REPORT.
（12）制御サーバー - > Control Client（Control Frameworkメッセージ）：レポート。
CFW i387yeiqyiq REPORT Seq: 3 Status: terminate Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFW i387yeiqyiqレポートseq：3ステータス：終了タイムアウト：10コンテンツタイプ：example_content/example_contentコンテンツレングス：11
<XML BLOB/>
<xml blob/>
(13) Control Client-->Control Server (Control Framework message): 200.
（13）制御クライアント - >コントロールサーバー（制御フレームワークメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 3
CFW i387yeiqyiq 200 seq：3
(14) Control Client-->Control Server (SIP): BYE
（14）コントロールクライアント - >コントロールサーバー（SIP）：さようなら
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
(15) Control Server-->Control Client (SIP): 200 OK
（15）制御サーバー - > Control Client（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
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.
Media Control Channel Frameworkは、最小限の拡張のみになるように設計されています。新しい方法、ヘッダーフィールド、およびステータスコードは、標準トラック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.
設計では、チャネルフレームワークは、「メディアサーバー制御プロトコル要件」[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.
チャネルフレームワークセッションは、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接続のみを使用する場合、チャネルフレームワークのセキュリティは弱いです。チャネルフレームワークにはこの交換を保護する能力が必要ですが、保護が常に使用されるという保証はありません。そのような保護が使用されない場合、誰でもデータ交換を見ることができます。
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 clientextededhello拡張ハロー情報も実装する必要があります。TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261]のTLS cipher-suiteをサポートする必要があります。他の暗号スイーツもサポートされる場合があります。
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のコマンドを発行することは許可されていません。システムは、必要に応じて、実装されたパッケージの要件を満たすために適切なポリシーフレームワークが採用されるようにする必要があります。最も堅牢な形式のポリシーは、制御チャネル上の相互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.)
（パッケージ名は、セクション8.1で説明した構文に準拠する必要があります。）
Published Specification(s):
公開された仕様：
(Control Packages require an RFC.)
（コントロールパッケージにはRFCが必要です。）
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
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).
この仕様は、メディア制御チャネルフレームワークパラメーターの下でサブレジストリ名をメソッド名を確立し、次のようにその母集団を開始します。このサブレジストリの新しいパラメーターは、RFC（IETFストリームまたは独立した提出ストリームのいずれか）で公開する必要があります。
CONTROL - [RFC6230]
REPORT - [RFC6230]
SYNC - [RFC6230]
K-ALIVE - [RFC6230]
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:
この仕様は、メディア制御チャネルフレームワークパラメーターの下でステータスコードサブレジストリを確立します。このサブレジストリの新しいパラメーターは、RFC（IETFストリームまたは独立した提出ストリームのいずれか）で公開する必要があります。その初期母集団はセクション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:
この仕様は、メディア制御チャネルフレームワークパラメーターの下でヘッダーフィールドサブレジストリを確立します。このサブレジストリの新しいパラメーターは、RFC（IETFストリームまたは独立した提出ストリームのいずれか）で公開する必要があります。その初期母集団は次のように定義されています。
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]
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)
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Intended usage: 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.
Change Controller：IESGから委任されたIETF Mediactrlワーキンググループ。
Type name: application
タイプ名：アプリケーション
Subtype name: framework-attributes+xml
サブタイプ名：Framework-Attributes XML
Required parameters: (none)
必要なパラメーター：（なし）
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメーター：RFC 3023 [RFC3023]で指定されているアプリケーション/XMLのcharsetパラメーターと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
考慮事項のエンコード：RFC 3023 [RFC3023]で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ。
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)
Person & email address to contact for further information:
Chris Boulton <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>
Attribute name: "cfw-id".
属性名：「CFW-ID」。
Type of attribute Media level.
属性メディアレベルのタイプ。
Subject to charset: Not.
charsetの対象：そうではありません。
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」属性は、コントロールチャネルをコントロールチャネル内で使用する場合、コントロールチャネルをSIP Inviteダイアログと交渉するために使用するダイアログと相関させるために使用できる識別子を示します。
Allowed attribute values: A token.
許可された属性値：トークン。
IANA has registered a new XML namespace, "urn:ietf:params:xml:ns:control:framework-attributes", per the guidelines in RFC 3688 [RFC3688].
IANAは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXMLネームスペース「urn：ietf：xml：xml：ns：control：framework-attributes」を登録しています。
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
登録者の連絡先：IETF Mediactrlワーキンググループ<Mediactrl@ietf.org>、Chris Boulton <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
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 Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
uri：urn：ietf：params：xml：ns：control：control：framework-attributes登録者連絡先：ietf mediactrlワーキンググループ<mediactrl@ietf.org>、chris boulton <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のAsher 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.
著者は、AvayaのIan Evans、Michael Bardzinski、NS-TechnologiesのJohn Dally、RadisysのAdnan Saleem、およびDave Morganに、この作業の有用なレビューと入力をしてくれたことに感謝します。エリックバーガーは、この作業の初期段階に貢献しました。
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.
エキスパートレビューは、スペンサードーキンス、クリシュナプラサドカルリ、ロレンツォミニエロ、ロニの偶数によっても提供されました。ハドリエル・カプランは、ダイアログアソシエーションメカニズムに関する専門家のガイダンスを提供しました。Lorenzo 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レビューを実施しました。Eric Burgerのテキストは、SIPを使用するための説明の紹介で使用されました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、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] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574] Levin、O。およびG. Camarillo、「セッション説明プロトコル（SDP）ラベル属性」、RFC 4574、2006年8月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[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] Crocker、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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. Turner、「Secure/Multipurpose Internet Mail Extensions（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.、Lawrence、S。、およびA. Jeffrey、「セッション開始プロトコル（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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.、Frederick、R。、およびV. Jacobson、「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] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、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] Dolly、M。and R. Even、「メディアサーバー制御プロトコル要件」、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] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
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.
制御フレームワークの作成中、複数のパッケージで一般的なコンポーネントが多数あることが明らかになりました。中央の場所にそのような再利用可能なコンポーネントを収集することが有用であることが明らかになりました。短期的には、この付録はユーティリティのプレースホルダーを提供し、このセクションが最終的に制御パッケージで使用できる最初の「ユーティリティドキュメント」の基礎を形成することを意図しています。
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ダイアログまたはカンファレンスインスタンスのいずれかを具体的に識別します。パッケージ内で使用する場合、[rfc3261]で定義されているように、「connectionId」属性に含まれる値を「ローカル」および「リモート」ダイアログ識別子タグを連結することにより構築する必要があります。次に、 '：'文字を使用して分離する必要があります。したがって、形式は次のとおりです。
'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
7hdy839：hjkskyhs
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.
以前に定義されたConnection属性と同様に、Multiparty Callなど、特定のコントロールフレームワークコマンドを多くの関連するダイアログに適用することができます。これは通常、単一の識別子に論理的にバインドされている多くのメディアダイアログで構成されています。次のスキーマを使用すると、制御フレームワークコマンドが「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"?>
<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: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:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>
Authors' Addresses
著者のアドレス
Chris Boulton NS-Technologies
クリス・ボールトンNS-Technologies
EMail: chris@ns-technologies.com
Tim Melanchuk Rainwillow
ティム・メランキュク・レインウィロー
EMail: timm@rainwillow.com
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
スコット・マクグラシャン・ヒューレット・パッカード・グスタフIII：S大通り36 SE-16985ストックホルム、スウェーデン
EMail: smcg.stds01@mcglashan.org