[要約] RFC 6230は、アプリケーションサーバーからメディアサーバー（音声・映像処理ノード）を遠隔制御するための汎用的な通信枠組み「メディア制御チャネルフレームワーク」を定義しています。TCPまたはTLS接続をベースに、制御コマンドとレスポンスを確実にやり取りするためのプロトコル構造を規定し、特定のメディア操作（IVR、会議等）を記述する「制御パッケージ」を運ぶための共通の基盤を提供します（RFC 5567の要件に基づく仕様）。
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.
この文書では、アプリケーションのプログラムロジックとメディア処理を分散して配置するためのフレームワークおよびプロトコルを説明します。これにより、アプリケーションのプログラムロジックは、同じ物理ネットワークエンティティ上に配置されていない適切なリソースにもシームレスにアクセスできます。このフレームワークはSession Initiation Protocol（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.
この文書はInternet Engineering Task Force（IETF）の成果であり、IETFコミュニティの合意を反映しています。公開レビューを経て、Internet Engineering Steering Group（IESG）が発行を承認しました。インターネット標準に関する詳しい情報は、RFC 5741のSection 2に記載されています。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6230.
この文書の現在の状態、正誤表、およびフィードバックの送付方法に関する情報は、http://www.rfc-editor.org/info/rfc6230で確認できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2011 IETF Trustおよび文書の著者として記載された人々。All rights reserved.
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文書に関するIETF Trustの法的条項（http://trustee.ietf.org/license-info）が適用されます。これらの条項には本書に関する権利と制限が記載されているため、内容をよく確認してください。本書から抽出したCode Componentには、Trust Legal ProvisionsのSection 4.eで定めるSimplified BSD Licenseの文言を含める必要があります。また、Simplified BSD Licenseに記載のとおり、保証なしで提供されます。
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. はじめに .......................................................4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2. 慣習と用語 .....................................................4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. 概要 ...........................................................6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4. 制御チャネルのセットアップ ....................................10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.1. Control ClientのSIP UAC動作 ...............................10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
4.2. 制御サーバーSIP UAS動作 ...................................13
5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. メディアストリームの確立 - Control ClientのSIP UAC動作 ........14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6. Control Frameworkのやり取り ...................................15
6.1. General Behavior for Constructing Requests . . . . . . . . 17
6.1. リクエストを作成するための一般的な動作 ....................17
6.2. General Behavior for Constructing Responses . . . . . . . 17
6.2. 応答構築の一般的な動作 ....................................17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3. トランザクション処理 ......................................18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROLトランザクション ...............................18
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.2. REPORTトランザクション ................................19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.3. K-ALIVEトランザクション ...............................21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
6.3.4. SYNCトランザクション ..................................22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7. 応答コードの説明 ..............................................24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.1. 200の応答コード ...........................................25
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.2. 202応答コード .............................................25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400応答コード .............................................25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403応答コード .............................................25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405応答コード .............................................25
7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 406応答コード .............................................25
7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 420応答コード .............................................25
7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 421応答コード .............................................25
7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 422応答コード .............................................25
7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 423応答コード .............................................25
7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.11. 481応答コード .............................................26
7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.12. 500応答コード .............................................26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8. 制御パッケージ ................................................26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26
8.1. コントロールパッケージ名 ..................................26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.2. フレームワークメッセージの使用 ............................26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27
8.3. 一般的なXMLサポート .......................................27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
8.4. CONTROLメッセージ本文 .....................................27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.5. REPORTメッセージ本文 ......................................27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.6. 監査 ......................................................27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.7. 例 ........................................................28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9. 正式な構文 ....................................................28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.1. 制御フレームワークの正式な構文 ............................28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
9.2. 制御フレームワークダイアログ識別子SDP属性 .................31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. 例 ............................................................31
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 35
11. 拡張性 ........................................................35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. セキュリティに関する考慮事項 ..................................36
12.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
12.1. セッションの確立 ..........................................36
12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
12.2. 輸送レベルの保護 ..........................................36
12.3. Control Channel Policy Management . . . . . . . . . . . . 37
12.3. 制御チャネルポリシー管理 ..................................37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13. IANAの考慮事項 ................................................38
13.1. Control Packages Registration Information . . . . . . . . 38
13.1. Control Packageの登録情報 .................................38
13.1.1. Control Package Registration Template . . . . . . . . 39
13.1.1. Control Package登録テンプレート .......................39
13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
13.2. 制御フレームワークメソッド名 ..............................39
13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
13.3. Control Frameworkステータスコード .........................39
13.4. Control Framework Header Fields . . . . . . . . . . . . . 40
13.4. Control Frameworkヘッダーフィールド .......................40
13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
13.5. 制御フレームワークポート ..................................40
13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
13.6. メディアタイプの登録 ......................................40
13.6.1. Registration of MIME Media Type application/cfw . . . 41
13.6.1. MIMEメディアタイプapplication/cfwの登録 ...............41
13.6.2. Registration of MIME Media Type
application/framework-attributes+xml . . . . . . . . . 42
13.6.2. MIMEメディアタイプapplication/framework-attributes+xmlの登録 ..42
13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
13.7. 'cfw-id' SDP属性 ..........................................42
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 43
13.8. urn:ietf:params:xml:ns:control:framework-attributesのURNサブ名前空間 ..43
13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 43
13.9. XMLスキーマ登録 ...........................................43
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
14. 貢献者 ........................................................44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
15. 謝辞 ..........................................................44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
16. 参考文献 ......................................................44
16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
16.1. 引用文献 ..................................................44
16.2. Informative References . . . . . . . . . . . . . . . . . . 46
16.2. Informative References ....................................46
Appendix A. Common Package Components . . . . . . . . . . . . . . 47
Appendix A. 一般的なパッケージコンポーネント .....................47
A.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 47
A.1. 一般的なダイアログ/マルチパーティリファレンススキーマ .....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]「Media Server Control Protocol Requirements」に記載されたメディアサーバー制御の一連の要件です。フレームワークはメディアサーバー制御だけを対象とするものではありませんが、これが本作業の主な推進要因であり、主要なユースケースです。本書のフレームワークは、会議制御など、さまざまなデバイス制御の用途に使用できることを意図しています。
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本来の機能の多くを重複して提供するためです。セッション確立とアプリケーションのメディア処理に1つのプロトコルを使う代わりに、アプリケーション開発者は別々の2つの機構を変換しながら扱う必要があります。さらに、ここで示すフレームワークはSIPを使うため、そのモデルはMegacoよりもアプリケーションプログラミングモデルによく適合します。
SIP [RFC3261] provides the ideal rendezvous mechanism for establishing and maintaining control connections to external server components. The control connections can then be used to exchange explicit command/response interactions that allow for media control and associated command response results.
SIP [RFC3261]は、外部サーバーコンポーネントへの制御接続を確立し、維持するための適切なランデブー機構を提供します。確立した制御接続を使うと、メディア制御や、それに対応するコマンド応答結果を扱う明示的なコマンド/応答のやり取りを行えます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.
本書で使うキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、適合性の対象に応じて、BCP 14および[RFC2119]に記載された意味で解釈します。
The following additional terms are defined for use in this document:
このドキュメントで使用するために、次の追加項が定義されています。
B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
B2BUA：B2BUAは、Back-to-Back SIP User Agentです。
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".
Control Server：Control Serverは、Control Clientに代わってメディア処理などのサービスを実行するエンティティです。たとえばメディアサーバーは、ミキシング、アナウンス、トーンの検出と生成、再生、録音のサービスを提供します。Control Serverは、メディアフローの送信元または受信先とReal-Time Transport Protocol（RTP）[RFC3550]で直接関係します。本書では、Control Serverを単に「Server」と呼ぶことがあります。
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".
Control Client：Control Clientは、Control Serverに処理を要求するエンティティです。Control Clientは処理能力をまったく持たない場合もあります。たとえば、Control Clientは、Control Serverとして動作するメディアサーバーで終端する第三者のメディアストリームの操作を要求するアプリケーションサーバー（B2BUA）や、その他のエンドポイントである場合があります。本書では、Control Clientを単に「Client」と呼ぶことがあります。
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.
Control Channel：Control Channelは、Frameworkメッセージの交換に使う、ClientとServer間の信頼性の高い接続です。本書では「Connection」も同じ意味で使います。
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".
Framework Message：Framework Messageは、本書で定義するいずれかのMethodに対応する型を持つ、Control Channel上のメッセージです。たとえば「CONTROL message」のように、Method名で呼ばれることもよくあります。
Method: A Method is the type of a Framework message. Four Methods are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
Method：MethodはFramework Messageの型です。本書では、SYNC、CONTROL、REPORT、K-ALIVEの4つのMethodを定義します。
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'.
Framework Transaction：Framework Transactionは、Control ClientまたはControl Serverのいずれかが開始したControl Frameworkメッセージと、それに対するControl Framework応答コードメッセージから成る一連のやり取りです。Control Frameworkには「暫定」応答がありません。本書では、このトランザクションを'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.
Transaction-Timeout：Control ClientまたはServerがFrameworkメッセージを送信してから、そのメッセージが宛先に到着するまでに許される最大時間です。'Transaction-Timeout'の値は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とSession Description Protocol（SDP）のオファー/アンサー交換[RFC3264]を使って、信頼性の高いトランスポート接続チャネルを確立、使用、終了するための機構を説明します。確立した接続は外部サーバーの制御に使います。以下では使用する機構の非規範的な概要を示し、規範的な詳細ガイドラインは後のセクションで説明します。
Control Channels are negotiated using standard SIP mechanisms that would be used in a similar manner to creating a SIP multimedia session. Figure 1 illustrates a simplified view of the mechanism. It highlights a separation of the SIP signaling traffic and the associated Control Channel that is established as a result of the SIP interactions.
制御チャネルは、SIPマルチメディアセッションの作成と同様の方法で使用される標準的なSIPメカニズムを使用してネゴシエートされます。図1は、メカニズムの単純化されたビューを示しています。SIPシグナリングトラフィックと、SIPの相互作用の結果として確立された関連する制御チャネルの分離を強調しています。
Initial analysis into the Control Framework, as documented in [MSCL-THOUGHTS], established the following. One might ask, "If all we are doing is establishing a TCP connection to control the media server, why do we need SIP?" This is a reasonable question. The key is that we use SIP for media session establishment. If we are using SIP for media session establishment, then we need to ensure the URI used for session establishment resolves to the same node as the node for session control. Using the SIP routing mechanism, and having the server initiate the TCP connection back, ensures this works. For example, the URI sip:myserver.example.com may resolve to sip: server21.farm12.northeast.example.net, whereas the URI http://myserver.example.com may resolve to http://server41.httpfarm.central.example.net. That is, the host part is not necessarily unambiguous.
[MSCL-THOUGHTS]に記録されたControl Frameworkの初期検討では、次の点が示されました。「メディアサーバーを制御するために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:
Control ChannelのネゴシエーションにSIPを使うと、次のような多くの機能を利用できます。
o Service location - Use SIP Proxies and Back-to-Back User Agents for locating Control Servers.
o サービスの場所特定 - SIP ProxyおよびBack-to-Back User Agentを使ってControl Serverを特定します。
o Security mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication.
o セキュリティ機構 - Transport Layer Security（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つは、「Service Location」機能です。この機能は、[RFC3263]がデバイスの物理的な位置を特定するルーティング層と、Caller Preferences [RFC3840]およびCallee Capabilities [RFC3841]を使うサービス層の両方で利用できます。サービス層の機能に基づいてControl Serverを選択できることは、音声、ビデオ、IMなど多様なサービスを提供する分散クラスタアーキテクチャにおいて非常に有用です。これらの手法によるControl Serverリソースの特定については、本書のSection 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の例は、Control ClientとControl Serverの間に1:1の接続があることを示しています。必要であれば、ClientはControl ClientとControl Serverの各エンティティ間で別々のSIP INVITEダイアログを使い、複数のControl Channelを要求できます。2つのエンティティ間に確立された接続は、いずれもServerの制御に使えます。これらの制御接続は、個々のメディアセッションとは独立しています。個別のメディアセッション情報は、Appendix Aで定義するXMLスキーマを使い、外部のControl Packageで定義する制御コマンドに含めます。複数のControl Channelを使うことで冗長性が高まり、負荷の高いシステムで大量のトラフィックを処理できます。
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.
ClientとServer間でセッションを確立する次の簡単な例を見てください。（注：例を明確かつ簡潔にするため、一部の行を省略しています。）ここで説明する役割は論理的なものであり、Control Packageが許せばセッション中に変わることがあります。
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.
Clientは、[RFC3261]で定義された標準的なSIP INVITEリクエストを構築し、外部Serverに送信します。Session Description Protocol（SDP）ペイロードには、Control Channelのネゴシエーションに必要な情報が含まれ、この仕様のサポートを示す主要な手段となります。本書では、仕様に準拠するSDP形式を示すためのMIMEタイプapplication/cfwを定義します。信頼性の高い接続を確立し維持するため、ネゴシエーション機構の一部としてConnection-Oriented Media（COMEDIA）[RFC4145]を使います（詳細は後続のセクションで説明します）。Clientはさらに、本仕様で定義するSDP属性'cfw-id'を含めます。これは、基礎となるMedia Control Channelをオファー/アンサー交換に対応付ける一意の識別子です。
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).
この機構をサポートする外部Serverは、INVITEリクエストを受信すると、適切なSDPを含む200 OK応答を生成し、本書で指定するMIMEタイプapplication/cfwを使って書式化します。Serverは、INVITE（オファー）で受信した値とは異なる、一意な値を持つSDP属性'cfw-id'を挿入します。
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.
Control ClientはSIP 200 OK応答を受信して関連情報を取り出し、SIP ACKも送信します。続いて、SDPの'setup'属性がactiveを指定しているため、Control Serverへの発信TCP接続を作成します。新しい接続では、接続先アドレス（'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ダイアログの使用と専用Control Channelを表します。図2のリンク（2）は、User AgentのSIP INVITEダイアログの使用に伴うやり取りとメディアフローを表します。User AgentはControl ClientエンティティとのSIP INVITEダイアログの使用を作成します。次にControl Clientエンティティは、B2BUA機能を使ってControl ServerとのSIP INVITEダイアログの使用を作成します。図の（2）に示すやり取りでは、Control ClientがSIP 3PCC [RFC3725]を使い、User Agentに代わってControl Serverとメディア機能をネゴシエーションします。
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 INVITEリクエストを構築および送信しなければなりません (MUST)。UACは、[RFC3261]で定義されているようにINVITE要求を作成しなければなりません (MUST)。
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]で定義されたセッション記述プロトコル（SDP）を使用するINVITEリクエストに、有効なセッション記述（[RFC3264]で定義された「オファー」）を含めるべきです (SHOULD)。ただし、[RFC3261]に従い、オファーを含まないINVITEを選択してもよい (MAY) です。SDPは以下の手順に従って書式化し、セクション13に登録されたMIMEタイプapplication/cfwを使用すべきです (SHOULD)。以下では、SDPとapplication/cfw MIMEタイプを使用するSIPベースのオファー/アンサー交換において、オファー側が従わなければならない (MUST) SDPペイロードの特定要素の構成を定めます。構築するSDPには、この仕様で定義するControl Channelを1つだけ含めなければなりません (MUST)。必要であれば、ほかのメディア行を含めることもできます。
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でなければなりません (MUST)。2番目のサブフィールド<addrtype>はIP4またはIP6のいずれかでなければなりません (MUST)。Connection Dataの3番目のサブフィールドは<connection-address>です。これはSDPの送信元アドレスを表し、たとえばDNS名やIPアドレスで記述されます。このアドレスを接続に使用します。
Example:
例：
c=IN IP4 controller.example.com
c=IN IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry:
SDPには、対応するメディアの説明エントリを含めなければなりません (MUST)。
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>は、値applicationでなければなりません (MUST)。2番目のサブフィールド<port>は、必要に応じて構築側クライアントが着信接続を受け付けられるポートを表さなければなりません (MUST)。接続の詳細を示すため、このポートは前述のConnection Data行で指定されたアドレスと組み合わせて使用します。SDPを構築するエンティティが着信接続を受け付けられない場合も、有効なポート値を設定する必要があります。ポート値0は、SIPのオファー/アンサー交換[RFC3264]で定義されているのと同じ意味を持ちます。Control Frameworkのデフォルトポートはセクション13.5で定義されています。これはデフォルト値ですが、クライアントは明示的なポート番号を選択できます。ただし、ローカルポリシーで禁止されていない限り、SDPではデフォルトのポート番号を使用すべきです (SHOULD)。デフォルトポートを使うと、ネットワーク管理者はControl Frameworkの通信に対するファイアウォールポリシーを管理できます。この仕様に準拠する3番目のサブフィールド<proto>は、値TCPおよびTCP/TLSをサポートしなければなりません (MUST)。実装は、Control Channelのトランスポート層セキュリティ機構としてTLSをサポートしなければなりません (MUST)。ただし、個々の配備でTLSを使用するかどうかは任意です。Control Frameworkの実装は、トランスポートプロトコルとしてTCPをサポートしなければなりません (MUST)。エンティティがトランスポート値を識別してもセッションを確立する意思がない場合は、適切なSIP機構を使って応答しなければなりません (MUST)。<fmt>サブフィールドには値cfwを含めなければなりません (MUST)。
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=）も複数含めなければなりません (MUST)。これらの属性は、接続のネゴシエーションおよび維持に関するパラメーターを提供します。ネットワークトポロジーにより特定方向への接続開始が禁止されている場合は、外部ServerがCOMEDIAを使って接続をネゴシエーションし、開始してもよい (MAY) ですが、通常はControlling UACが外部Serverへの接続を開始することが推奨されます (SHOULD)。COMEDIA属性の例を次に示します。
a=setup:active
a=connection:new
This example demonstrates a new connection that will be initiated from the owner of the SDP payload. The connection details are contained in the SDP answer received from the UAS. A full example of an SDP payload compliant to this specification can be viewed in Section 3. Once the SDP has been constructed along with the remainder of the SIP INVITE request (as defined in [RFC3261]), it can be sent to the appropriate location. The SIP INVITE dialog usage and appropriate control connection is then established.
この例は、SDPペイロードの送信側が開始する新しい接続を示しています。接続の詳細は、UASから受信するSDPアンサーに含まれます。この仕様に準拠するSDPペイロード全体の例はSection 3にあります。SDPをSIP INVITEリクエストの残りの部分とともに構築した後（リクエストの形式は[RFC3261]で定義されています）、適切な宛先へ送信できます。その後、SIP INVITEダイアログの使用と対応する制御接続が確立されます。
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で定義されたSDP属性cfw-idを含めなければなりません (MUST)。cfw-id属性は、このSIP INVITEダイアログの使用とControl Channelを対応付けるために使用できる識別子を示します。cfw-id属性は、UACとUAS間のやり取りにおいて一意でなければならず (MUST)、ほかのSIPオファー/アンサー交換で使われるcfw-idと競合してはなりません (MUST NOT)。選択したcfw-idの値は、関連するSIP INVITEダイアログの使用期間全体にわたって使い続け、オファー/アンサー交換の更新時にも変更してはなりません (MUST)。これは特に[RFC4145]で定義されたconnection属性に当てはまります。SIP UACがSDPのほかの部分を変更しつつ確立済みの接続を再利用する場合は、connection属性にexistingを指定します（例：a=connection:existing）。接続が失敗したことを検知し、再確立する場合は、connection属性にnewを指定します（例：a=connection:new）。この場合も、cfw-id SDPパラメーターで指定する接続識別子を変更してはなりません (MUST NOT)。ここでネゴシエーションするのはエンドポイント間の基礎となるTCP接続だけです。SIP INVITEダイアログの使用期間中は、常に同じControl Frameworkセッションを使います。この対応関係は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".
INVITEリクエストに対して非2xxクラスの最終SIP応答（3xx、4xx、5xx、6xx）を受信した場合、SIP INVITEダイアログの使用は作成されていません。この場合はSIP [RFC3261]の規定に従って処理します。この仕様への対応は、本仕様で定義するメディアタイプが含まれているかどうかによってネゴシエーションします。「488」などのSIPエラー応答は、リクエスト内のオファーが受け入れられないことを示します。この仕様に関連するメディア行を含むオファーが拒否された場合、受信側のClientが本仕様をサポートしていないことが原因の可能性があると、オファーを生成したClientに伝わります。オファーを生成したClientは、この応答を受信したとき、[RFC3261]に従って通常どおり動作しなければなりません (MUST)。[RFC3264]で定義されているように、セッション記述のm=行でポートを0に設定してメディアストリームを拒否することもできます。本仕様を使うClientは、Control Framework用に挿入したm=行のポートが0に設定されたアンサーを受信することに備えなければなりません (MUST)。
In this situation, the client will act as it would for any other media type with a port set to "0".
この場合、Clientはポートが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リクエストを受信した外部Server（SIP UAS）は、この仕様で定義する機構がサポートされているかをメッセージから確認します。具体的には、オファーメッセージのセッション記述を調べ、SDPでapplication/cfw MIMEタイプがサポートされているかを確認します。拡張をサポートすることを示す信頼できる応答を作成する場合、SIP UASは[RFC3261]で定義された機構に従わなければなりません (MUST)。信頼できるSIP暫定応答でサポートを示す場合は、[RFC3262]の機構も使用しなければなりません (MUST)。SDPオファーは最初のINVITEリクエストに限られず、[RFC3261]、[RFC3262]、[RFC3311]、[RFC3264]に準拠する一連のメッセージのいずれに含まれてもよい (MAY) です。
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:
アンサーを構築する場合は、有効なローカル設定を使い、Section 4.1で定義された接続、メディア、属性のセマンティクスに従ってSDPペイロードを構築するとともに、COMEDIA [RFC4145]仕様に完全に準拠させなければなりません (MUST)。たとえば、Section 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で定義されたSDP属性cfw-idを含めなければなりません (MUST)。この属性は、UACとUAS間のやり取りにおいて一意でなければならず (MUST)、ほかのSIPオファー/アンサー交換で使われるcfw-idと競合してはなりません (MUST NOT)。SDPアンサーを生成する複数のエンドポイントを一意に識別して区別するため、アンサーのcfw-idはオファーで受信したcfw-idとは異ならなければなりません (MUST)。選択したcfw-idの値は、関連するSIP INVITEダイアログの使用期間全体にわたって使い続け、オファー/アンサー交換の更新時にも変更してはなりません (MUST)。
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ペイロードの内容に応じて、Controlling UACと外部ServerのUASとの間に信頼性の高い接続が確立されます。この接続を使ってControl Commandのプリミティブを交換できます。SIP INVITEダイアログの使用状態と関連するControl Channelは暗黙に結び付いています。いずれかの当事者がControl Channelを終了する場合は、SIPの終了リクエスト（たとえばSIP BYEリクエスト）を発行するか、初期段階のSIP INVITEダイアログの使用中であれば適切な応答を返します。したがって、Control ChannelはSIP INVITEダイアログの使用期間中存続します。
A UAS receiving a SIP OPTIONS request MUST respond appropriately as defined in [RFC3261]. The UAS MUST include the media types supported in the SIP 200 OK response in a SIP 'Accept' header to indicate the valid media types.
SIP OPTIONSリクエストを受信したUASは、[RFC3261]で定義されたとおりに適切な応答を返さなければなりません (MUST)。有効なメディアタイプを示すため、UASはサポートするメディアタイプをSIP 200 OK応答のSIP 'Accept'ヘッダーに含めなければなりません (MUST)。
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.
Control Frameworkは、幅広い機能を実現するさまざまなアーキテクチャで使用することを想定しています。主な用途の1つは、Control Channelを使って、対象のリモートServerとのSIP INVITEダイアログ（メディアダイアログ）で確立したメディアセッションに、複数のControl Package固有のコマンドを適用することです。たとえばControl Serverは、User Agentとメディアサーバーの間の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=).
User Agentに代わってメディアセッションを確立するSIP INVITEダイアログ（図2参照）には、複数のMedia Description（SDPのm=で定義）が含まれてもよい (MAY) です。Control Frameworkを使うエンティティ宛てのm=定義ごとに、Control Clientは[RFC4574]で定義されたメディアラベル属性を含めなければなりません (MUST)。これにより、Control Clientは後から特定のメディア行（m=）を指定して、Control Channel上でコマンドを明示的に送れます。
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.
このフレームワークでは、関連するメディアダイアログを参照できることが非常に重要です。そのため、任意のControl Packageに取り込める接続参照属性を定義しています。これにより、各パッケージでダイアログ参照の記述を繰り返す必要を減らすことを意図しています。スキーマはAppendix 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.
同様に、Conferenceの全参加者にプロンプトを再生する場合など、関連するメディアダイアログのグループ（マルチパーティ）に対してコマンドを適用する機能も、定義して再利用できる共通構造として扱います。このような操作のスキーマもAppendix A.1にあります。
Support for both the common attributes described here is specified as part of each Control Package definition, as detailed in Section 8.
ここで説明した2つの共通属性をサポートするかどうかは、Section 8で詳述する各Control Packageの定義で指定します。
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トランザクションの結果としてControl Channelをどちらの方向にも確立できます。SIPはControl Channelを確立するための柔軟なネゴシエーション機構を提供しますが、Control Channel内には、確立に使われたSIP INVITEダイアログの使用と対応付ける機構が必要です。着信接続を受けるControl Clientは、UACとUASのどちらの役割で動作していても、特定ポートですべての着信接続を待ち受けているだけの場合、対応するSIP INVITEダイアログの使用を識別できません。次の手順を実装でサポートしなければなりません (MUST)。この手順により、接続するUA（COMEDIAでactive役割を持つUA）は、その接続を開始させたSIP INVITEダイアログの使用を識別できます。別のダイアログ対応付け機構を使わない限り、UAは、新たに作成したControl Channelでほかのシグナリングを行う前に、これらの手順を実行しなければなりません (MUST)。
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 接続が確立したら、接続を開始したactive役割のUA（active UA）は、Control FrameworkのSYNCリクエストを送信しなければなりません (MUST)。SYNCリクエストはSection 9.1で定義された形式に従って構築しなければならず (MUST)、'Dialog-ID'メッセージヘッダーを含めなければなりません (MUST)。
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'メッセージヘッダーには、Control Channel確立用のSDPオファー/アンサー交換で同じClientが挿入した、ローカルのメディアレベル属性'cfw-id'の値を設定します。これによりControl Channelを対応するSIP INVITEダイアログの使用に関連付けられます。
o On creating the SYNC request, the active UA MUST follow the procedures outlined in Section 6.3.3. This provides details of connection keep-alive messages.
o SYNCリクエストを作成するとき、active UAはSection 6.3.3に記載された手順にも従わなければなりません (MUST)。この手順では接続のキープアライブメッセージについて説明します。
o On creating the SYNC request, the active UA MUST also follow the procedures outlined in Section 6.3.4.2. This provides details of the negotiation mechanism used to determine the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection.
o SYNCリクエストを作成するとき、active UAはSection 6.3.4.2に記載された手順にも従わなければなりません (MUST)。この手順では、確立したControl Channel接続上で交換できるProtocol Data Unit（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 接続確立でactive役割を担うUAは、続いてSYNCリクエストを送信しなければなりません (MUST)。そのUAがSIP UASで、2xxクラスのSIP応答にSDPアンサーを含めた場合、SYNCを送信する前にSIP ACKメッセージを受信するまで待たなければなりません (MUST)。信頼できる1XXクラスのSIP応答にSDPアンサーを含めた場合は、SYNCを送信する前にSIP PRACKメッセージを受信するまで待たなければなりません (MUST)。
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'.
接続確立でactive役割を担うUAがSIP UACである場合、Control Channelの確立直後にSYNCメッセージを送信しなければなりません (MUST)。その後、応答を受信するため、少なくとも2*'Transaction-Timeout'の期間は待たなければなりません (MUST)。さらに長く待ってもよい (MAY) ですが、待機時間を'Transaction-Timeout'より短くしてはなりません (MUST NOT)。一般に、Control Frameworkのトランザクションは20秒（2*'Transaction-Timeout'）以内に完了しなければなりません (MUST)。本書では、この時間を'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 SYNCメッセージへの応答がない場合はタイムアウトとなり、Control Channelと関連するSIP INVITEダイアログの使用を終了します。active UAはSIP INVITEダイアログの使用を終了するため、BYEリクエストを送信しなければなりません (MUST)。
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 active UAがpassive UAから481応答を受信した場合、SYNCリクエストは受信されていますが、SYNCメッセージで指定されたSIP INVITEダイアログの使用が存在しないことを意味します。active ClientはControl Channelを終了しなければなりません (MUST)。active UAはSIP INVITEダイアログの使用を終了するため、SIP BYEリクエストを送信しなければなりません (MUST)。
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 SYNCリクエストに対して受信したほかのすべてのエラー応答も、本仕様の規定に従って処理し、Control Channelと関連するSIP INVITEダイアログの使用を終了させます。active UAはSIP INVITEダイアログの使用を終了するため、BYEリクエストを送信しなければなりません (MUST)。
o The receipt of a 200 response to a SYNC message implies that the SIP INVITE dialog usage and control connection have been successfully correlated. The Control Channel can now be used for further interactions.
o SYNCメッセージに対する200応答を受信した場合、SIP INVITEダイアログの使用と制御接続の対応付けが成功したことを意味します。以降、Control Channelを使ってやり取りできます。
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.
最初の交換が完了した後は、Control Channelが開いている間、どちら側からでも任意の時点でSYNCメッセージを送信できます。'Keep-Alive'ヘッダーまたは'Dialog-ID'ヘッダーが存在する場合、その値を変更してはなりません (MUST NOT)。これらのヘッダーの値はMedia Control Channel Frameworkセッションの存続期間にわたってネゴシエーションされるため、新しい値を設定しても意味がありません。
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.
Section 4.1および4.2で定義されたControl Channelが正常に確立され、前述の段落で説明したように接続が対応付けられると、2つのエンティティはControl Frameworkメッセージを交換できるようになります。以下の各節では、Control Frameworkのリクエストと応答を構築する一般的な動作を定めます。Section 6.3では、Control Frameworkの基本Methodとトランザクション処理を定めます。
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.
Control Channel上でリクエストを構築して送信するControl Clientは、Section 9で定義された構文に従わなければなりません (MUST)。個々のControl Packageの要件によっては、どちらのエンティティもControl Clientとして動作できます。Control Commandも、本書のSection 4.1および4.2でネゴシエーションしたControl Packageが定義する構文に従わなければなりません (MUST)。Control Clientは、リクエストに含める一意なトランザクション識別子を作成しなければなりません (MUST)。Section 9のABNFに定義されているとおり、トランザクション識別子はMethodの型とともにControl Frameworkメッセージの先頭行に含めます。識別子を容易に抽出できるよう、先頭行はトークンCFWで始まります。トランザクション識別子は、Control ClientとControl Server間のやり取りにおいて一意でなければなりません (MUST)。これにより、複数のClientが単一の受信Serverで処理されるトランザクションを作成する場合の衝突を避けられます。次に、必要、必須、任意の各Control Frameworkヘッダーを適切な値とともにリクエストへ挿入します（詳細は各ヘッダーの説明を参照）。'Control-Package'ヘッダーも、そのリクエストが適用されるControl Packageを示す値で挿入しなければなりません (MUST)。Section 6.3.4.2で説明するSYNCメッセージを使い、1つのControl Channelで複数のパッケージをネゴシエーションできます。
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'.
ペイロードを伴うFrameworkメッセージには、'Content-Type'および'Content-Length'メッセージヘッダーも含めなければなりません (MUST)。これらのヘッダーは、それぞれ個々のControl Frameworkパッケージが指定するペイロードのMIMEタイプと、メッセージ本文全体のサイズをオクテット数の10進整数で示します。メッセージにペイロードを追加しない場合、'Content-Length'ヘッダーの値は0でなければなりません (MUST)。
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.
Frameworkメッセージリクエストを受信したServerは、Section 6.2で定義する適切な応答を返さなければなりません (MUST)。Control Clientは、応答がないことを理由にトランザクションを失敗と判断して状態を適切に整理する前に、少なくとも2*'Transaction-Timeout'の期間、応答を待たなければなりません (MUST)。状態の整理方法は使用中の拡張パッケージによって異なります。
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.
Control Serverとして動作するエンティティは、リクエストを受信した場合、Control Client側で計測した'Transaction-Timeout'以内に応答を生成しなければなりません (MUST)。応答は、セクション9で定義されたABNFに準拠しなければなりません (MUST)。応答の先頭行には、セクション6.1で定義されたとおり、リクエストの先頭行で使われたトランザクション識別子を含めなければなりません (MUST)。応答に'Status'または'Timeout'メッセージヘッダーを含めてはなりません (MUST NOT)。クライアントは、応答でこれらのヘッダーを受信した場合、無視しなければなりません (MUST)。
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.
Control Serverは、応答の先頭行にステータスコードを含めなければなりません (MUST)。エラーがない場合、Section 7.1で定義する200 Control Frameworkステータスコードを返します。200応答にはメッセージ本文を含めてもよい (MAY) です。応答にペイロードが含まれる場合、メッセージには'Content-Length'および'Content-Type'ヘッダーを含めなければなりません (MUST)。Control Clientが2xxクラスの応答を受信すると、Control Commandのトランザクションは完了です。
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.
Control ServerがCONTROLなどのリクエストを受信し、その内容を理解していても、コマンドの処理に'Transaction-Timeout'を超える時間がかかると判断した場合、応答の先頭行に202ステータスコードを含めて返さなければなりません (MUST)。最初の応答の後、ServerはSection 6.3.2で説明するREPORTメッセージを1つ以上送信します。Control Packageは、Serverが200メッセージと202メッセージのどちらを送るかを明示的に定めなければなりません (MUST)。
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.
Control ServerがCONTROLやREPORTなどのControl Frameworkリクエストの処理中に問題に遭遇した場合、Section 7に示す適切なエラーコードを応答で使わなければなりません (MUST)。CONTROLやREPORTなどのリクエストに対して非2xxクラスの応答コードを返すと、そのトランザクションは失敗したことになり、関連するすべてのトランザクション状態とリソースを終了しなければなりません (MUST)。応答コードは失敗理由を明示することがあり、使用する拡張パッケージによっては、その理由に応じてリクエストを再送する場合があります。
The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods.
Control Frameworkでは、CONTROL、REPORT、K-ALIVE、SYNCの4種類のリクエスト（Method）を定義します。実装は、これら4つのMethodを送受信できなければなりません (MUST)。
The following sub-sections specify each Control Framework method and its associated transaction processing.
以下の各節では、Control Frameworkの各Methodと、それに関連するトランザクション処理を定めます。
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.
CONTROLメッセージは、Control ClientからControl Serverへ制御関連情報を渡すために使います。また、Control Frameworkでイベントを報告する仕組みとしても使います。イベント報告はCONTROLメッセージのもう1つの用途です。セッション参加者間でどちらの方向にも送信でき、イベントに応じたペイロードを運びます。メッセージは、セクション6.1で説明し、セクション9で定義する標準的なControl Frameworkメッセージと同じ方法で構築します。CONTROLメッセージにはメッセージ本文を含めてもよい (MAY) です。CONTROLメッセージのペイロードに含める明示的なControl Commandは、個別のControl Package仕様で定めます。個別のControl Package仕様は、セクション8.4で定義された形式に準拠しなければなりません (MUST)。ペイロードを含むCONTROLメッセージには'Content-Type'ヘッダーを含めなければなりません (MUST)。ペイロードは、そのControl Packageで定義されたペイロード型のいずれかでなければなりません (MUST)。個々のパッケージでは、ペイロードを含まないCONTROLメッセージを許可してもよい (MAY) です。これは特定のパッケージ内で有効なメッセージ交換の場合があります。有効でない場合は、適切なパッケージレベルのエラーメッセージを生成しなければなりません (MUST)。
A 'REPORT' message is used by a Control Server when processing of a CONTROL command extends beyond the 'Transaction-Timeout', as measured from the Client. In this case, the Server returns a 202 response. The Server returns status updates and the final results of the command in subsequent REPORT messages.
Control Serverは、CONTROLコマンドの処理がClient側で計測した'Transaction-Timeout'を超える場合に'REPORT'メッセージを使います。この場合、Serverは202応答を返します。その後のREPORTメッセージで、コマンドの状態更新と最終結果を返します。
All REPORT messages MUST contain the same transaction ID in the request start line that was present in the original CONTROL transaction. This correlates extended transactions with the original CONTROL transaction. A REPORT message containing a payload MUST include the 'Content-Type' and 'Content-Length' headers indicating the payload MIME type [RFC2045] defined by the Control Package and the length of the payload, respectively.
すべてのREPORTメッセージは、元のCONTROLトランザクションに含まれていたものと同じトランザクションIDを、リクエスト開始行に含めなければなりません (MUST)。これにより、延長されたトランザクションを元のCONTROLトランザクションに対応付けます。ペイロードを含むREPORTメッセージには、Control Packageが定義するペイロードのMIMEタイプ[RFC2045]とペイロード長をそれぞれ示す'Content-Type'および'Content-Length'ヘッダーを含めなければなりません (MUST)。
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.
CONTROLメッセージを受信したControl Serverは、Section 6.2の規定に従い、'Transaction-Timeout'以内にリクエストのステータスコードを返さなければなりません (MUST)。コマンドの処理がその時間内に完了する場合は、200応答コードを送信しなければなりません (MUST)。完了しない場合は、要求されたコマンドの処理が継続中で、CONTROLトランザクションが延長されることを示す202応答コードを送信しなければなりません (MUST)。その後、REPORT Methodで延長されたトランザクションの状態を更新し、終了させます。Control Serverは202応答コードを送る判断をぎりぎりまで遅らせず、応答がControl Clientに届くまで十分な時間を確保する必要があります。時間が足りないと、完了前にControl Client側でトランザクションがタイムアウトし、終了します。
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応答を送信するControl Serverは、メッセージに'Timeout'メッセージヘッダーを含めなければなりません (MUST)。このヘッダーには秒単位の値を設定しなければなりません (MUST)。202メッセージの受信側は、その秒数が経過するまで待ち、問題が発生したと判断した場合に延長されたトランザクションと関連状態を終了しなければなりません (MUST)。
The initial REPORT message MUST contain a 'Seq' (Sequence) message header with a value equal to '1'. Note: the 'Seq' numbers at both Control Client and Control Server for Framework messages are independent.
最初のREPORTメッセージには、値が1の'Seq'（Sequence）メッセージヘッダーを含めなければなりません (MUST)。注：Control ClientとControl ServerがFrameworkメッセージで使う'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.
拡張CONTROLトランザクションのすべてのREPORTメッセージには、'Timeout'メッセージヘッダーを含めなければなりません (MUST)。このヘッダーには秒単位の値を設定します。REPORTメッセージの受信側は、その値の秒数だけ待ち、問題が発生したと判断した場合に拡張トランザクションと関連状態を終了しなければなりません (MUST)。'Status'ヘッダーの値がupdateであるREPORTメッセージを受信したControl Clientは、該当する拡張CONTROLトランザクションのタイマーを、指定されたタイムアウト期間にリセットしなければなりません (MUST)。タイムアウト期間が近づいても予定されたREPORTメッセージが生成されていない場合、そのやり取りでControl Framework UASとして動作するエンティティは、この段落で定義するとおり、ペイロードを伴わない'Status: update'ヘッダーを含むREPORTメッセージを生成しなければなりません (MUST)。このメッセージはタイムアウトを延長します。メッセージ本文やセマンティクスは許可されないため、拡張トランザクションには影響しません。'Timeout'メッセージヘッダーの値には、最小10秒、最大15秒を使うことが推奨されます (SHOULD)。また、Control Serverは、期限切れに近すぎない間隔でCONTROLトランザクションのタイムアウト期間を更新することが推奨されます (SHOULD)。タイムアウト期間の80%を更新間隔として使えます。たとえばタイムアウト期間が10秒なら、Serverは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.
延長されたCONTROLトランザクションに関する後続のREPORTメッセージにも'Seq'ヘッダーを含め、その値を1ずつ増やさなければなりません (MUST)。値が1ずつ増加していないREPORTメッセージには406応答を返さなければなりません (MUST)。また、延長されたトランザクションを終了したものと見なさなければなりません (MUST)。406応答を受信した場合も、延長されたトランザクションを終了しなければなりません (MUST)。REPORTメッセージには値がupdateの'Status'ヘッダーも含めなければなりません (MUST)。延長されたCONTROLトランザクションの状態を更新するこれらのREPORTメッセージには、個々のControl Packageが定義しSection 8.5で指定するメッセージ本文を含めてもよい (MAY) です。この節で前述したとおり、延長されたトランザクションを更新するREPORTメッセージはタイムアウトを更新する役割も持ちます。その結果、元のCONTROLリクエストの開始側では、'Timeout'メッセージヘッダーに指定された期間にトランザクションのタイムアウトがリセットされます。
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.
延長されたCONTROLトランザクションの処理がすべて完了したら、Control Serverとして動作するエンティティは終了REPORTメッセージを送信しなければなりません (MUST)。終了REPORTメッセージの'Seq'メッセージヘッダーの値は、前のREPORTメッセージの値より1増やさなければなりません (MUST)。また、値がterminateの'Status'ヘッダーを含めなければならず (MUST)、メッセージ本文を含めてもよい (MAY) です。さらに、有効な値を持つ'Timeout'メッセージヘッダーも含めなければなりません (MUST)。'Timeout'ヘッダーを含めるのは一貫性を保つためであり、その値は無視されます。Control Framework UACは、元のCONTROLトランザクションに関連する保留状態を整理できます。
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].
本書で定義するプロトコルは、さまざまなネットワークアーキテクチャで使用できます。Clientが保護されたプライベートドメイン内に配置される構成から、Network Address Translator（NAT）やファイアウォールなどを経由する必要がある、別々のドメインに分散した構成まで、幅広い配備形態があります。キープアライブ機構を使うと、通信がない間もControl Channelを維持できます。多くのファイアウォールは一定時間経過後に接続を閉じるためです。この機構は、アプリケーション層で障害を検出する手段にもなります。以下の手順は、作成対象のControl Channelだけに適用されます。SIPのキープアライブ機構については、実装者はSIP Outbound [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.
以下のキープアライブ手順を実装しなければなりません (MUST)。両方のエンティティが同じドメイン内に配置されている場合、個々の配備ではキープアライブ機構を使わなくてもよい (MAY) です。ただし、この節で定義するキープアライブ機構を使わないと、同じ場所に配置された構成であっても、特に長時間通信がない場合に、アプリケーション層のエラーを検出する能力が低下します。
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.
Section 6で説明したSYNCによる最初の対応付けハンドシェイクを含め、SIP INVITEダイアログの使用と基礎となるControl Channelが確立された後、COMEDIA [RFC4145]で定義されるactive役割とpassive役割の両方のエンティティは、Control ChannelのSYNCリクエスト/応答交換でネゴシエーションした値に等しいキープアライブタイマーを開始しなければなりません (MUST)。この値は'Keep-Alive'ヘッダーで指定する秒数です。
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.
active役割のエンティティは、ローカルのキープアライブタイマーが満了する前にK-ALIVEメッセージを生成しなければなりません (MUST)。activeエンティティは、任意のタイミングでK-ALIVEメッセージを送信できます。ローカルのキープアライブタイマーの80%が経過した時点でK-ALIVEメッセージを送信することが推奨されます (SHOULD)。K-ALIVEリクエストに対する200 OK Control Frameworkメッセージを受信すると、activeエンティティはローカルのキープアライブタイマーをリセットしなければなりません (MUST)。タイマーが満了する前にK-ALIVEメッセージへの200 OK応答を受信できない場合、または別の方法でトランスポート層の問題を検出した場合、activeエンティティはCOMEDIAの再ネゴシエーション手順を使って接続を回復してもよい (MAY) です。それ以外の場合は、activeエンティティはSIP INVITEダイアログを終了し、関連するControl Channelのリソースを解放しなければなりません (MUST)。
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.
passiveエンティティは、ローカルのキープアライブタイマーが満了する前にK-ALIVEメッセージを受信しなければなりません。K-ALIVEリクエストを受信した場合、passiveエンティティは200 OK Control Framework応答を生成し、ローカルのキープアライブタイマーをリセットしなければなりません (MUST)。ほかのControl Framework応答は有効ではありません。タイマーが満了する前にK-ALIVEメッセージを受信できない場合、または別の方法でトランスポート層の問題を検出した場合、passiveエンティティはSIP INVITEダイアログを終了し、関連するControl Channelのリソースを解放しなければなりません (MUST)。
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.
Control Channel上で最初に送信するSYNCリクエストは、Control Channelのキープアライブ機構に用いるタイムアウト期間をネゴシエーションするとともに、クライアントとサーバーがそれぞれサポートするControl Packageを把握できるようにします。後続のSYNCリクエストを使って、Control Channelで使用可能なControl Packageの集合を変更してもよい (MAY) です。
The initial SYNC request allows the timeout period for the Control Channel keep-alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request:
最初のSYNCリクエストでは、Control Channelのキープアライブ機構に使うタイムアウト期間をネゴシエーションします。この最初のSYNCリクエストでは、次の規則に従わなければなりません (MUST)。
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オファーを開始するClientのCOMEDIA 'setup'属性がactiveの場合、オファー側が生成するSYNCメッセージに'Keep-Alive'ヘッダーを含めなければなりません (MUST)。'Keep-Alive'ヘッダーの値は95～120秒の範囲にすべきです (SHOULD)（SIP Outbound [RFC5626]と整合します）。'Keep-Alive'ヘッダーの値は600秒を超えてはなりません (MUST NOT)。SDPのAnswerを生成したClient（passive側）は、同じ値の'Keep-Alive'ヘッダーをSYNCメッセージへの200応答にコピーしなければなりません (MUST)。
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オファーを開始するClientのCOMEDIA 'setup'属性がpassiveの場合、アンサー側が生成するSYNCメッセージに'Keep-Alive'ヘッダーパラメーターを含めなければなりません (MUST)。'Keep-Alive'ヘッダーの値は95～120秒の範囲にすべきです (SHOULD)。SDPオファーを生成したClient（passive側）は、同じ値の'Keep-Alive'ヘッダーをSYNCメッセージへの200応答にコピーしなければなりません (MUST)。
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オファーを開始するClientのCOMEDIA 'setup'属性がactpassの場合、SDPセッションでactive参加者となるエンティティのSYNCメッセージに'Keep-Alive'ヘッダーパラメーターを含めなければなりません (MUST)。後続のSDPアンサーを生成するClientがCOMEDIA SDP 'setup'属性にactiveを設定した場合、そのClientがSYNCリクエストを生成し、'Keep-Alive'ヘッダーを含めます。この値は95～120秒の範囲にすべきです (SHOULD)。後続のSDPアンサーを生成するClientがCOMEDIA 'setup'属性にpassiveを設定した場合、SDPを作成した元のUAがSYNCリクエストを生成し、'Keep-Alive'ヘッダーを含めます。この値も95～120秒の範囲にすべきです (SHOULD)。
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 最初のオファー/アンサーのネゴシエーション結果でCOMEDIAの'setup'属性がholdconnとなった場合、オファー/アンサー交換を更新し、COMEDIAによってactive/passiveの役割が決まった時点で最初のSYNCを行います。
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.
前述の手順により、Control Channel接続を開始するエンティティが常にキープアライブのタイムアウト期間を指定します。K-ALIVEメッセージを生成するのも、常に接続を開始したエンティティです。
Once negotiated, the keep-alive timeout applies for the remainder of the Control Framework session. Any subsequent SYNC messages generated in the Control Channel do not impact the negotiated keep-alive property of the session. The 'Keep-Alive' header MUST NOT be included in subsequent SYNC messages, and if it is received, it MUST be ignored.
一度ネゴシエーションしたキープアライブのタイムアウトは、その後のControl Frameworkセッション期間中に適用されます。Control Channelで後から生成するSYNCメッセージによって、セッションでネゴシエーションしたキープアライブ設定が変わることはありません。後続のSYNCメッセージに'Keep-Alive'ヘッダーを含めてはならず (MUST NOT)、受信した場合は無視しなければなりません (MUST)。
As part of the SYNC message exchange, a client generating the request MUST include a 'Packages' header, as defined in Section 9. The 'Packages' header contains a list of all Control Framework packages that can be supported within this control session, from the perspective of the client creating the SYNC message. All Channel Framework package names MUST be tokens that adhere to the rules set out in Section 8. The 'Packages' header of the initial SYNC message MUST contain at least one value.
SYNCメッセージ交換の一環として、リクエストを生成するClientは、Section 9で定義する'Packages'ヘッダーを含めなければなりません (MUST)。'Packages'ヘッダーには、そのClientの観点から、このControl Sessionでサポート可能なすべてのControl Frameworkパッケージの一覧を記載します。すべてのChannel Frameworkパッケージ名は、Section 8の規則に従うトークンでなければなりません (MUST)。最初のSYNCメッセージの'Packages'ヘッダーには、少なくとも1つの値を含めなければなりません (MUST)。
A server receiving the initial SYNC request MUST examine the contents of the 'Packages' header. If the server supports at least one of the packages listed in the request, it MUST respond with a 200 response code. The response MUST contain a 'Packages' header that lists the supported packages that are in common with those from the 'Packages' header of the request (either all or a subset). This list forms a common set of Control Packages that are supported by both parties. Any Control Packages supported by the server that are not listed in the 'Packages' header of the SYNC request MAY be placed in the 'Supported' header of the response. This provides a hint to the client that generated the SYNC request about additional packages supported by the server.
最初のSYNCリクエストを受信したServerは、'Packages'ヘッダーの内容を確認しなければなりません (MUST)。リクエストに記載されたパッケージを1つ以上サポートする場合、Serverは200応答コードを返さなければなりません (MUST)。応答には'Packages'ヘッダーを含め、リクエストの'Packages'ヘッダーにあるパッケージのうち、Serverもサポートするものをすべて、またはその一部を記載しなければなりません (MUST)。その一覧は、両者が共通してサポートするControl Packageの集合です。SYNCリクエストの'Packages'ヘッダーに記載されていないものの、ServerがサポートするControl Packageは、応答の'Supported'ヘッダーに記載してもよい (MAY) です。これにより、Serverが追加でサポートするパッケージを、SYNCリクエストを生成したClientに知らせます。
If no common packages are supported by the server receiving the SYNC message, it MUST respond with a 422 error response code. The error response MUST contain a 'Supported' header indicating the packages that are supported. The initiating client can then choose to either re-submit a new SYNC message based on the 422 response or consider the interaction a failure. This would lead to termination of the associated SIP INVITE dialog by sending a SIP BYE request, as per [RFC3261].
SYNCメッセージを受信したServerが共通のパッケージを1つもサポートしていない場合、422エラー応答コードを返さなければなりません (MUST)。エラー応答には、サポートするパッケージを示す'Supported'ヘッダーを含めなければなりません (MUST)。開始側のClientは、422応答に基づいて新しいSYNCメッセージを再送するか、このやり取りを失敗として扱うかを選べます。後者の場合、[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.
最初のSYNCトランザクションが完了した後、いずれかのClientは、Control Channelでサポートするパッケージを再ネゴシエーションするため、新しいSYNCメッセージを送信してもよい (MAY) です。'Packages'ヘッダーの値が前のSYNCメッセージと異なる新しいSYNCメッセージにより、Control Channelで使用するパッケージを追加または削除できます。後続のSYNCメッセージを受信したClientがパッケージ集合の変更を望まない場合、421 Control Framework応答コードを返さなければなりません (MUST)。後続のSYNCメッセージは、最初のSYNCネゴシエーションで使われた'Dialog-ID'および'Keep-Alive' Control Frameworkヘッダーの値を変更してはなりません (MUST NOT)。
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.
パッケージを再ネゴシエーションした後、エンティティは、サポートしなくなったControl Packageに関するControl Frameworkコマンドを受け入れてもよい (MAY) です。そのようなコマンドを受け入れない場合、エンティティは420応答でリクエストに応答しなければなりません (MUST)。
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で定義されたメソッドに対するトランザクション応答用です。このセクションのすべての応答コードはサポートしなければなりません (MUST)。REPORTメッセージへの応答として202を生成してはならない (MUST NOT) 点を除き、CONTROLメッセージとREPORTメッセージのどちらへの応答にも使用できます。
Note that these response codes apply to Framework Transactions only. Success or error indications for Control Commands MUST be treated as the result of a Control Command and returned in either a 200 response or REPORT message.
これらの応答コードはFramework Transactionだけに適用されます。Control Commandの成功またはエラーは、そのControl Commandの結果として扱い、200応答またはREPORTメッセージのいずれかで返さなければなりません (MUST)。
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.
Serverはリクエストを理解していますが、実行を拒否しています。Clientはリクエストを再送すべきではありません (SHOULD NOT)。
Method not allowed. The primitive is not supported.
Methodは許可されていません。このプリミティブはサポートされていません。
Message out of sequence.
メッセージの順序が不正です。
Intended target of the request is for a Control Package that is not valid for the current session.
リクエストが対象とするControl Packageは、現在のセッションでは有効ではありません。
Recipient does not wish to re-negotiate Control Packages at this moment in time.
受信側は、現時点ではControl Packageの再ネゴシエーションを望んでいません。
Recipient does not support any Control Packages listed in the SYNC message.
受信側は、SYNCメッセージに列挙されたControl Packageを1つもサポートしていません。
Recipient has an existing transaction with the same transaction ID.
受信側には、同じトランザクションIDを持つトランザクションがすでに存在します。
The transaction of the request does not exist. In response to a SYNC request, the 481 response code indicates that the corresponding SIP INVITE dialog usage does not exist.
リクエストのトランザクションが存在しません。SYNCリクエストへの481応答コードは、対応するSIP INVITEダイアログの使用が存在しないことを示します。
The recipient does not understand the request.
受信者はリクエストを理解していません。
Control Packages specify behavior that extends the capability defined in this document. Control Packages MUST NOT weaken statements of "MUST" and "SHOULD" strength in this document. A Control Package MAY strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified by the specific usage of the framework.
Control Packageは、この文書で定義された機能を拡張する動作を定めます。Control Packageは、この文書にある「MUST」および「SHOULD」の強度の規定を弱めてはなりません (MUST NOT)。フレームワークの具体的な用途に照らして正当化できる場合、Control Packageは「SHOULD」「RECOMMENDED」「MAY」を「MUST」に強めてもよい (MAY) です。
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.
Standards Track RFCやSIP拡張文書に通常含めるセクションに加えて、Control Packageの著者は、以下の各節で詳述する項目を扱う必要があります。以下の各節をテンプレートとして使い、すべてのControl Package仕様に適宜含めなければなりません (MUST)。これらの節だけでControl Package仕様のすべてが構成されるわけではありませんが、パッケージに不可欠な情報を最低限示すためのものです。この節に列挙した情報を少なくとも含んでいれば、Control Package仕様は適切な形式で作成できます。
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.
この節は、本書を拡張するすべての文書に含めなければなりません (MUST)。Control Packageのトークン名を定め、トークンのIANA登録に記載する情報を含めなければなりません (MUST)。Control Packageトークンの登録についてはSection 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.
Control Frameworkは、コマンドや情報の交換に使える複数のメッセージプリミティブを定義します。Control Channel上を流れるメッセージの方向に制限はありません。Control Package文書のこの節では、使用できるFramework Message（Method）の種類と、エンティティ間のメッセージの方向を明記しなければなりません (MUST)。どの役割のエンティティが各リクエストを開始できるかも示します。
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]).
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.
Control Packageのこの必須節では、Section 6で定義するCONTROLコマンドリクエストに含める本文を定義するか、Control Package本文が不要であることを明記します。この節では、CONTROLコマンドリクエストと、任意でその200応答に適用するMIME [RFC2045]本文型について、詳細な構文定義とセマンティクスの所在を示さなければなりません (MUST)。Control Package本文を持たない場合、その旨を明記すれば、Control Package文書におけるこの節の「MUST」要件を満たします。
This mandatory section of a Control Package defines the REPORT body that can be contained within a REPORT command request, as defined in Section 6, or that no report package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type. It should be noted that the Control Framework specification does allow for payloads to exist in 200 responses to CONTROL messages (as defined in this document). An entity that is prepared to receive a payload type in a REPORT message MUST also be prepared to receive the same payload in a 200 response to a CONTROL message. For Control Packages that do not have a Control Package body, stating such satisfies the "MUST" strength of this section in the Control Package document.
Control Packageのこの必須節では、Section 6で定義するREPORTコマンドリクエストに含める本文を定義するか、REPORT用の本文が不要であることを明記します。この節では、適切なMIME [RFC2045]本文型の詳細な構文定義とセマンティクスの所在を示さなければなりません (MUST)。本書で定義するControl Framework仕様では、CONTROLメッセージへの200応答にもペイロードを含められます。REPORTメッセージで特定のペイロード型を受信するエンティティは、CONTROLメッセージへの200応答でも同じペイロードを受信できるようにしなければなりません (MUST)。Control Package本文を持たない場合、その旨を明記すれば、Control Package文書におけるこの節の「MUST」要件を満たします。
Auditing of various Control Package properties such as capabilities and resources (package-level meta-information) is extremely useful. Such meta-data usually has no direct impact on Control Framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information.
機能やリソースなど、Control Packageのさまざまな特性（パッケージレベルのメタ情報）を監査できると非常に便利です。このようなメタデータは通常、Control Frameworkのやり取りに直接影響しませんが、文脈を把握するための情報になります。関連するパッケージ監査情報を提供するため、Control PackageではControl Frameworkのやり取りを利用することが推奨されます。
This section SHOULD include the following information:
この節には、次の情報を含めるべきです (SHOULD)。
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 監査情報をどのように要求し（たとえばControl FrameworkのCONTROLメッセージを使う）、どのように返すか（たとえばControl Frameworkの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.
Control Packageでは、そのパッケージと本フレームワーク文書を使う一般的なメッセージフローを複数提示することが強く推奨されます (SHOULD)。
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
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
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.
次の表に、Control Frameworkのやり取りに含めることができるヘッダーの概要を示します。
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.
token-char要素とtoken要素は[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.
次の例では、Control Channelの確立とControl Frameworkメッセージの交換の流れを抽象化して示します。SIPシグナリングにはトークン'SIP'を付けます。それ以外のメッセージはすべて、本書で定義するControl Frameworkのやり取りです。
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.
この例では、Control ClientがControl Channelを確立してControl ServerとSYNCを行い、'Transaction-Timeout'以内に完了できないCONTROLリクエストを発行します。そのためControl Serverは202応答コードを返し、トランザクションを延長します。その後、Control Serverは要求された処理が完了するまでREPORTメッセージを送信します。最後に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) Control Client-->Control Server（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) Control ClientはControl ServerへのTCP接続を開きます。この接続を使ってControl Frameworkメッセージを交換できます。Control Client-->Control Server（Control Frameworkメッセージ）：SYNC。
CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0
CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0
(5) Control Server-->Control Client (Control Framework message): 200.
(5) Control Server-->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 Packages: msc-ivr-basic/1.0 Supported: 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) SYNC手順が完了すると、この接続を使ってControl Frameworkメッセージを交換できます。Control Client-->Control Server（Control Frameworkメッセージ）：CONTROL。
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 Server-->Control Client（Control Frameworkメッセージ）：202。
CFW i387yeiqyiq 202 Timeout: 10
CFW i387yeiqyiq 202 Timeout: 10
(8) Control Server-->Control Client (Control Framework message): REPORT.
(8) Control Server-->Control Client（Control Frameworkメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10
CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10
(9) Control Client-->Control Server (Control Framework message): 200.
(9) Control Client-->Control Server（Control Frameworkメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 1
CFW i387yeiqyiq 200 Seq: 1
(10) Control Server-->Control Client (Control Framework message): REPORT.
(10) Control Server-->Control Client（Control Frameworkメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
<XML BLOB/>
<XML BLOB/>
(11) Control Client-->Control Server (Control Framework message): 200.
(11) Control Client-->Control Server（Control Frameworkメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 2
CFW i387yeiqyiq 200 Seq: 2
(12) Control Server-->Control Client (Control Framework message): REPORT.
(12) Control Server-->Control Client（Control Frameworkメッセージ）：REPORT。
CFW i387yeiqyiq REPORT Seq: 3 Status: terminate Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFW i387yeiqyiq REPORT Seq: 3 Status: terminate Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
<XML BLOB/>
<XML BLOB/>
(13) Control Client-->Control Server (Control Framework message): 200.
(13) Control Client-->Control Server（Control Frameworkメッセージ）：200。
CFW i387yeiqyiq 200 Seq: 3
CFW i387yeiqyiq 200 Seq: 3
(14) Control Client-->Control Server (SIP): BYE
(14) Control Client-->Control Server（SIP）：BYE
BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Length: 0
(15) Control Server-->Control Client (SIP): 200 OK
(15) Control Server-->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は、拡張を最小限に抑える設計です。新しいMethod、ヘッダーフィールド、ステータスコードは、Standards Track RFCで定義できます。Media Control Channel Frameworkには、新機能を要求または検出するためのバージョン番号やネゴシエーション機構がありません。今後、ネゴシエーションを必要とする拡張が定義される場合、その拡張をどのようにネゴシエーションするかを、カプセル化するシグナリングプロトコル内で説明する必要があります。将来、相互運用性のない更新や拡張が行われた場合、それは新しいプロトコルとして扱われ、その使用をどのように通知するかを記述しなければなりません (MUST)。
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.
相互運用性を損なわずにヘッダーフィールドを拡張できるよう、Media Control Channelの装置が理解できないヘッダーフィールドを含むリクエストまたは応答を受信した場合、その装置は当該ヘッダーフィールドを無視し、ヘッダーフィールドが存在しなかったかのようにリクエストまたは応答を処理しなければなりません (MUST)。未知のMethodを含むリクエストを受信した場合は、500応答を返さなければなりません (MUST)。
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.
Channel Frameworkは、転送するメッセージの機密性と完全性を保護します。また、接続先のホストが意図したホストであることや、接続が乗っ取られていないことも保証します。この節の後半で詳しく説明します。
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.
設計上、Channel Frameworkは「Media Server Control Protocol Requirements」[RFC5167]に記載されたセキュリティ要件、特にREQ-MCP-11、REQ-MCP-12、REQ-MCP-13、REQ-MCP-14に準拠しています。Channel Frameworkが採用する具体的なセキュリティ対策を、以下の各節にまとめます。
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.
Channel Frameworkのセッションは、SIP INVITEダイアログ内でSDPに記述するメディアセッションとして確立されます。Control FrameworkのClientとServer間で安全に相手を特定できるよう、Media Channel Control FrameworkではSIPが提供する機構を十分に活用すべきです。SDP属性'cfw-id'を使うと、重要なセッション情報がSIPネットワークを通じて伝達されます。このため、本仕様を使うSIP Clientは、オープンネットワークに配置する場合、TLS [RFC5246]やS/MIME [RFC5751]など適切なセキュリティ機構を使わなければなりません (MUST)。
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]).
プライベート情報や金融情報などの機密データは、Control Frameworkのチャネルを通じて送信されます。ClientとServerを適切に認証・認可し、Control Channelではデータの機密性、リプレイ防止、完全性を保護できるようにする必要があります。Control Channelを保護するため、Control FrameworkのClientとServerはTLSをサポートしなければならず (MUST)、代替のControl Channel保護を使う場合、またはネットワーク管理者が保護された環境を保証する場合を除き、TLSを既定で使うべきです (SHOULD)。必要であれば、代替のControl Channel保護を使ってもよい (MAY) です（例：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.
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 ClientがServerとの接続を確立すると、ServerのX.509証明書が提示されます。認証はRFC 5922 [RFC5922]のSection 7.3（「Client Behavior」）で説明されるとおりに進めます。
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 Serverは、Client証明書を要求しなければなりません (MUST)。Clientが証明書を持っている場合は相互認証のためにServerへ提示され、認証はRFC 5922 [RFC5922]のSection 7.4（「Server Behavior」）で説明されるとおりに進めます。
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を使った専用Control Channelの確立を認めています。また、フェールオーバーと冗長化のためにエンティティが複数のチャネルを作成することも認めています。一般に、複数のエンティティが接続を作成してリソースにアクセスできると、共有環境で競合が発生する可能性があります。本書ではそのような競合を解消する具体的な機構を定めませんが、対処方法の概要を示します。
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.
リソースへのアクセスとControl Channelの使用にはポリシーが関係します。どのレベルのポリシーを採用するかは、実装と配備の詳細によって決まります。Control Channelの認可と関連ポリシーは、この節で説明する認証機構に結び付けられます。たとえば、TLS認証によってControl Channelを厳格に認証すると、エンティティはリソースを保護し、必要な粒度でアクセスを制御できます。このようなポリシーは、パッケージ単位でも、Conferenceインスタンスのような細かい単位でも適用できます（例：Control Channel XはControl Package yのコマンドを発行できない、またはControl Channel AはConferenceインスタンスBのコマンドを発行できない）。必要な場合、実装システムは実装するパッケージの要件を満たす適切なポリシーフレームワークを採用すべきです。最も堅牢なポリシーは、Control Channel上で相互TLS認証など強力な認証機構を使うことで実現できます。本仕様では、コマンドの発行者に実行が許可されていないことを示すControl Channel応答コード403を定めています。実装ポリシーで許可されないControl Frameworkリクエストには、403応答を返さなければなりません (MUST)。403応答を受信した場合、Control Framework Clientは要件を変えてリクエストを再送するか、リクエストを取り下げてもよい (MAY) です。本仕様は汎用的なため、403応答はポリシー違反の理由を詳しく示しません。必要に応じて、個々のControl Packageが追加情報を提供できますが、その提供方法は本仕様では義務付けません。この節で扱うもの以外にも、リソースアクセスをさらに細かく制御するポリシー要件を個々のControl Packageで定義し、適用する場合があります。
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 Control Frameworkパラメーター用の新しいレジストリを作成しました。「Media Control Channel Framework Parameters」レジストリは、複数のサブレジストリをまとめるものです。この節ではさらに、Control Package、Method名、ステータスコード、ヘッダーフィールド名、ポート、トランスポートプロトコルの各サブレジストリを導入します。
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".
本仕様では、「Media Control Channel Framework Packages」の下にControl Packagesサブレジストリを設けます。このサブレジストリに新しいパラメーターを登録するには、IANAポリシー[RFC5226]の「RFC Required」に従い、RFC（IETFストリームまたはIndependent Submissionストリーム）として公開する必要があります。
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.
本書ではPackage名もTemplate-Package名も指定しないため、Control Packageの初期IANA登録は空です。この節の残りでは、IANAが管理する情報の例を示します。
The table below lists the Control Packages defined in the "Media Control Channel Framework".
次の表に、「Media Control Channel Framework」で定義するControl Packageを示します。
Package Name Reference
------------ ---------
example1 [RFCXXXX]
Package Name:
パッケージ名：
(Package names must conform to the syntax described in Section 8.1.)
（Package名はSection 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).
この仕様では、Media Control Channel Framework Parametersの下にMethod Namesサブレジストリを設け、次の内容で初期登録します。このサブレジストリに新しいパラメーターを追加する場合は、RFC（IETFストリームまたはIndependent Submissionストリーム）として公開する必要があります。
The following information MUST be provided in an RFC in order to register a new Control Framework method:
新しいControl Framework Methodを登録するRFCには、次の情報を記載しなければなりません (MUST)。
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:
この仕様では、Media Control Channel Framework Parametersの下にStatus Codeサブレジストリを設けます。このサブレジストリに新しいパラメーターを追加する場合は、RFC（IETFストリームまたはIndependent Submissionストリーム）として公開する必要があります。初期登録の内容はSection 9で定めます。形式は次のとおりです。
Code Description Reference
コード 説明 参照
The following information MUST be provided in an RFC in order to register a new Control Framework status code:
新しいControl Frameworkステータスコードを登録するRFCには、次の情報を記載しなければなりません (MUST)。
o The status code number.
o ステータスコード番号。
o The RFC number in which the method is registered.
o Methodが登録された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:
この仕様では、Media Control Channel Framework Parametersの下にHeader Fieldサブレジストリを設けます。このサブレジストリに新しいパラメーターを追加する場合は、RFC（IETFストリームまたはIndependent Submissionストリーム）として公開する必要があります。初期登録の内容を以下に示します。
The following information MUST be provided in an RFC in order to register a new Channel Framework header field:
新しいChannel Frameworkヘッダーフィールドを登録するRFCには、次の情報を記載しなければなりません (MUST)。
o The header field name.
o ヘッダーフィールド名。
o The RFC number in which the method is registered.
o Methodが登録されたRFC番号。
The Control Framework uses TCP port 7563, from the "registered" port range. Usage of this value is described in Section 4.1.
Control Frameworkは、登録済みポート範囲のTCPポート7563を使用します。このポートの使用方法はSection 4.1で説明します。
Type name: application
タイプ名：application
Subtype name: cfw
サブタイプ名：cfw
Required parameters: None
必須パラメーター：なし
Optional parameters: None
任意パラメーター：なし
Encoding considerations: Binary and see Section 4 of RFC 6230
エンコーディングに関する考慮事項：バイナリ。RFC 6230のSection 4を参照してください。
Security considerations: See Section 12 of RFC 6230
セキュリティに関する考慮事項：RFC 6230のSection 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.
このメディアタイプを使用するアプリケーション：Media Control Channelに準拠するアプリケーション。
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
想定用途：COMMON（一般用途）
Restrictions on usage: Should be used only in conjunction with this specification, RFC 6230.
使用制限：RFC 6230の本仕様と組み合わせてのみ使用することが推奨されます。
Author: Chris Boulton
著者：Chris Boulton
Change controller: IETF MEDIACTRL working group, delegated from the IESG.
変更管理者：IESGから委任されたIETF MEDIACTRL working group。
Type name: application
タイプ名：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]で定義されたapplication/xmlのcharsetパラメーターと同じです。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
エンコーディングに関する考慮事項：RFC 3023 [RFC3023]で定義されたapplication/xmlのエンコーディングに関する考慮事項と同じです。
Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework.
セキュリティに関する考慮事項：Media Control Channel Frameworkのコア仕様で扱うもの以外に、既知のセキュリティ上の考慮事項はありません。
Interoperability considerations: This content type provides common constructs for related Media Control Channel packages.
相互運用性に関する考慮事項：このコンテンツタイプは、関連するMedia Control Channelパッケージで共通して使う構成要素を提供します。
Published specification: RFC 6230
公開仕様：RFC 6230
Applications that use this media type: Implementations of appropriate Media Control Channel packages.
このメディアタイプを使用するアプリケーション：適切なMedia Control Channelパッケージの実装。
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
想定用途：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.
属性の目的：属性値をControl Channel内で使用する場合、'cfw-id'属性は、そのネゴシエーションに使用したSIP INVITEダイアログとControl Channelを対応付けるための識別子を示します。
Allowed attribute values: A token.
許可される属性値：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:params: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 working group <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:framework-attributes 登録者の連絡先：IETF MEDIACTRL working group <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、NS-TechnologiesのMichael BardzinskiおよびJohn Dally、RadisysのAdnan Saleem、Dave Morganに感謝します。Eric Burgerは、この作業の初期段階に貢献しました。
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.
Spencer Dawkins、Krishna Prasad Kalluri、Lorenzo Miniero、Roni Evenも専門家レビューを提供しました。Hadriel Kaplanは、ダイアログ対応付け機構について専門的な助言を提供しました。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.
Ben Campbellは本書のRAI専門家レビューを行い、多くの貴重な意見を寄せました。Brian Weisは綿密なセキュリティレビューを行いました。Jonathan Lennoxは、優れた修正につながる綿密なSDPレビューを行いました。SIPを使う理由の説明には、Eric Burgerが作成した文章を序論で使用しました。
[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. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[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., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.
[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., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[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., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[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., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[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., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[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., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
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メディアダイアログ（「Connection」とも呼ばれる）または会議に対して特定のコマンドを適用できるようにするための、いくつかの共通属性を提供します。コントロールパッケージ内で使用される場合、Connectionおよびmultiparty属性がインポートされ、SIPダイアログまたは会議インスタンスのいずれかを具体的に識別するために適切に使用されます。パッケージ内で使用される場合、'connectionid' 属性に含まれる値は、[RFC3261]で定義されている 'Local' および 'Remote' のSIPダイアログ識別子タグを連結して構築しなければなりません (MUST)。これらは ':' 文字を使用して区切られなければなりません (MUST)。したがって、その形式は以下のようになります。
'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:
例として、SIPローカルダイアログ識別子が'7HDY839'で、リモートダイアログ識別子が'HJKSkyHS'のエンティティでは、Control Frameworkコマンドの'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ダイアログに関連付けて開始するControl Frameworkリクエストでは、リクエストの方向によって'connectionid'の値が異なる点に注意してください。たとえば、LocalタグとRemoteタグは、それぞれローカル側から識別できます。
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など、関連する複数のダイアログに特定のControl Frameworkコマンドを適用できると便利です。通常、これらは1つの識別子で論理的に結び付けられた複数のメディアダイアログから成ります。次のスキーマでは、'conferenceid' XMLコンテナを使って、そのようなグループをControl Frameworkコマンドから明示的に参照できます。Control Packageで使う場合、この属性が参照する制御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'識別子の値は、大文字と小文字を区別して比較しなければなりません (MUST)。
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
Chris Boulton NS-Technologies
EMail: chris@ns-technologies.com
Tim Melanchuk Rainwillow
Tim Melanchuk Rainwillow
EMail: timm@rainwillow.com
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
EMail: smcg.stds01@mcglashan.org