Internet Engineering Task Force (IETF)                        C. Boulton
Request for Comments: 6230                               NS-Technologies
Category: Standards Track                                   T. Melanchuk
ISSN: 2070-1721                                               Rainwillow
                                                            S. McGlashan
                                                                May 2011
                    Media Control Channel Framework



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.


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.


Status of This Memo


This is an Internet Standards Track document.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Control Channel Setup  . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Control Client SIP UAC Behavior  . . . . . . . . . . . . . 10
     4.2.  Control Server SIP UAS Behavior  . . . . . . . . . . . . . 13
   5.  Establishing Media Streams - Control Client SIP UAC
       Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Control Framework Interactions . . . . . . . . . . . . . . . . 15
     6.1.  General Behavior for Constructing Requests . . . . . . . . 17
     6.2.  General Behavior for Constructing Responses  . . . . . . . 17
     6.3.  Transaction Processing . . . . . . . . . . . . . . . . . . 18
       6.3.1.  CONTROL Transactions . . . . . . . . . . . . . . . . . 18
       6.3.2.  REPORT Transactions  . . . . . . . . . . . . . . . . . 19
       6.3.3.  K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
       6.3.4.  SYNC Transactions  . . . . . . . . . . . . . . . . . . 22
   7.  Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
     7.1.  200 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.2.  202 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.3.  400 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.4.  403 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.5.  405 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.6.  406 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.7.  420 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.8.  421 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.9.  422 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.10. 423 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.11. 481 Response Code  . . . . . . . . . . . . . . . . . . . . 26
     7.12. 500 Response Code  . . . . . . . . . . . . . . . . . . . . 26
   8.  Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Control Package Name . . . . . . . . . . . . . . . . . . . 26
     8.2.  Framework Message Usage  . . . . . . . . . . . . . . . . . 26
     8.3.  Common XML Support . . . . . . . . . . . . . . . . . . . . 27
     8.4.  CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
     8.5.  REPORT Message Bodies  . . . . . . . . . . . . . . . . . . 27
     8.6.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 28
     9.1.  Control Framework Formal Syntax  . . . . . . . . . . . . . 28
     9.2.  Control Framework Dialog Identifier SDP Attribute  . . . . 31
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   11. Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 35
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
     12.1. Session Establishment  . . . . . . . . . . . . . . . . . . 36
     12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
     12.3. Control Channel Policy Management  . . . . . . . . . . . . 37
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
     13.1. Control Packages Registration Information  . . . . . . . . 38
       13.1.1. Control Package Registration Template  . . . . . . . . 39
     13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
     13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
     13.4. Control Framework Header Fields  . . . . . . . . . . . . . 40
     13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
     13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
       13.6.1. Registration of MIME Media Type application/cfw  . . . 41
       13.6.2. Registration of MIME Media Type
               application/framework-attributes+xml . . . . . . . . . 42
     13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
     13.8. URN Sub-Namespace for
           urn:ietf:params:xml:ns:control:framework-attributes  . . . 43
     13.9. XML Schema Registration  . . . . . . . . . . . . . . . . . 43
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 44
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     16.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Appendix A.  Common Package Components . . . . . . . . . . . . . . 47
     A.1.  Common Dialog/Multiparty Reference Schema  . . . . . . . . 47
1. Introduction
1. はじめに

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).


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.


Current IETF device control protocols, such as Megaco [RFC5125], while excellent for controlling media gateways that bridge separate networks, are troublesome for supporting media-rich applications in SIP networks. This is because Megaco duplicates many of the functions inherent in SIP. Rather than using a single protocol for session establishment and application media processing, application developers need to translate between two separate mechanisms. Moreover, the model provided by the framework presented here, using SIP, better matches the application programming model than does Megaco.

例えばMegacoのような現在のIETFデバイス制御プロトコル、[RFC5125]は、別々のネットワークをブリッジメディアゲートウェイを制御するための優れながら、SIPネットワークにおけるメディアリッチアプリケーションをサポートするため煩雑です。 Megacoのは、SIPに固有の機能の多くを複製するためです。むしろセッション確立およびアプリケーションメディア処理のための単一のプロトコルを使用するよりも、アプリケーション開発者は、2つの別個の機構の間で変換する必要があります。また、フレームワークによって提供されるモデルは、SIP、よりよいマッチのMegacoの場合よりも、アプリケーション・プログラミング・モデルを使用して、ここに提示しました。

SIP [RFC3261] provides the ideal rendezvous mechanism for establishing and maintaining control connections to external server components. The control connections can then be used to exchange explicit command/response interactions that allow for media control and associated command response results.

SIP [RFC3261]は、外部サーバコンポーネントへの制御接続を確立し、維持するための理想的なランデブーメカニズムを提供します。制御接続は、メディア制御及び関連コマンド応答の結果を可能にする明示的なコマンド/レスポンス相互作用を交換するために使用することができます。

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように、それらの適合性ターゲットを対象として、解釈されます。

The following additional terms are defined for use in this document:


User Agent Client (UAC): As specified in [RFC3261].


User Agent Server (UAS): As specified in [RFC3261].


B2BUA: A B2BUA is a 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 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 Channel: A Control Channel is a reliable connection between a Client and Server that is used to exchange Framework messages. The term "Connection" is used synonymously within this document.


Framework Message: A Framework message is a message on a Control Channel that has a type corresponding to one of the Methods defined in this document. A Framework message is often referred to by its method, such as a "CONTROL message".


Method: A Method is the type of a Framework message. Four Methods are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.

方法:この方法は、フレームワークメッセージのタイプです。 4つの方法は、この文書で定義されています:SYNC、CONTROL、REPORT、およびK-ALIVEを。

Control Command: A Control Command is an application-level request from a Client to a Server. Control Commands are carried in the body of CONTROL messages. Control Commands are defined in separate specifications known as "Control Packages".


Framework Transaction: A Framework Transaction is defined as a sequence composed of a Control Framework message originated by either a Control Client or Control Server and responded to with a Control Framework response code message. Note that the Control Framework has no "provisional" responses. A Control Framework transaction is referenced throughout the document as a 'Transaction-Timeout'.


Transaction-Timeout: The maximum allowed time between a Control Client or Server issuing a Framework message and it arriving at the destination. The value for 'Transaction-Timeout' is 10 seconds.

トランザクション・タイムアウト:コントロールクライアントまたはサーバがフレームワークのメッセージを発行し、それが目的地に到着する間の最大許容時間。 「トランザクション・タイムアウト」の値は10秒です。

3. Overview

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.


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.


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 may resolve to sip:, whereas the URI may resolve to That is, the host part is not necessarily unambiguous.

コントロールフレームワークへの初期分析は、[MSCL-THOUGHTS]に記載されているように、次のように確立しました。一つは、「私たちはSIP必要か、なぜ、我々がやっているすべてのメディアサーバーを制御するために、TCPコネクションを確立している場合は?」と尋ねるかもしれませんこれは、合理的な質問です。キーは、私たちがメディアセッション確立のためのSIPを使用することです。私たちは、メディアセッション確立のためのSIPを使用している場合は、次に我々は、セッション制御用ノードと同じノードに解決URIは、セッション確立のために使用を確認する必要があります。 SIPルーティング機構を使用して、サーバを有するバックTCP接続を開始し、この動作を確実にします。例えば、URIのSIP:myserver.example.comは一口に解決されることがあります。、URI http://myserver.example.comがHTTPに解決する場合がある://server41.httpfarm。。つまり、ホスト部分は、必ずしも明確なではありません。

The use of SIP to negotiate the Control Channel provides many inherent capabilities, which include:


o Service location - Use SIP Proxies and Back-to-Back User Agents for locating Control Servers.

Oサービスの場所 - 使用SIPプロキシおよびコントロール・サーバーを見つけるためのバックツーバックユーザエージェント。

o Security mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication.

Oセキュリティ・メカニズム - などトランスポート層セキュリティ(TLS)およびクライアント認証として活用確立されたセキュリティ・メカニズム。

o Connection maintenance - The ability to re-negotiate a connection, ensure it is active, and so forth.

O接続メンテナンス - 、接続を再ネゴシエート等がアクティブであることを確認し、そしてする能力。

o Application agnostic - Generic protocol allows for easy extension.

Oとらわれないアプリケーション - 一般的なプロトコルは、簡単に拡張することができます。

As mentioned in the previous list, one of the main benefits of using SIP as the session control protocol is the "Service Location" facilities provided. This applies both at a routing level, where [RFC3263] provides the physical location of devices, and at the service level, using Caller Preferences [RFC3840] and Callee Capabilities [RFC3841]. The ability to select a Control Server based on service-level capabilities is extremely powerful when considering a distributed, clustered architecture containing varying services (for example, voice, video, IM). More detail on locating Control Server resources using these techniques is outlined in Section 4.1 of this document.


           +--------------SIP Traffic--------------+
          |                                       |
          v                                       v
       +-----+                                 +--+--+
       | SIP |                                 | SIP |
       |Stack|                                 |Stack|
   +---+-----+---+                         +---+-----+---+
   |   Control   |                         |   Control   |
   |   Client    |<----Control Channel---->|   Server    |
   +-------------+                         +-------------+

Figure 1: Basic Architecture


The example from Figure 1 conveys a 1:1 connection between the Control Client and the Control Server. It is possible, if required, for the client to request multiple Control Channels using separate SIP INVITE dialogs between the Control Client and the Control Server entities. Any of the connections created between the two entities can then be used for Server control interactions. The control connections are orthogonal to any given media session. Specific media session information is incorporated in control interaction commands, which themselves are defined in external packages, using the XML schema defined in Appendix A. The ability to have multiple Control Channels allows for stronger redundancy and the ability to manage high volumes of traffic in busy systems.

コントロールクライアントと制御サーバーとの間の1接続:図1の例では、1を搬送します。必要であれば、クライアントはコントロールクライアントおよびコントロール・サーバー・エンティティ間のダイアログをINVITE別のSIPを使用して、複数の制御チャネルを要求することは、可能です。 2つのエンティティ間で作成された接続のいずれかが、[サーバーコントロールの相互作用のために使用することができます。制御接続は、任意のメディアセッションに直交しています。特定のメディアセッション情報は、複数の制御チャネルを有する能力が強く、冗長性と忙しい中で大量のトラフィックを管理する能力を可能にし、付録Aで定義されたXMLスキーマを使用して、自分自身が外部のパッケージで定義されているコントロールの対話コマンド、中に組み込まれていますシステム。

Consider the following simple example for session establishment between a Client and a Server. (Note: Some lines in the examples are removed for clarity and brevity.) Note that the roles discussed are logical and can change during a session, if the Control Package allows.

クライアントとサーバーの間のセッションを確立するため、次の簡単な例を考えてみましょう。 (注:例のいくつかのラインは明瞭かつ簡潔にするために除去される。)で考察ロールは論理的制御パッケージが許可されている場合、セッション中に変更することができることに留意されたいです。

The Client constructs and sends a standard SIP INVITE request, as defined in [RFC3261], to the external Server. The Session Description Protocol (SDP) payload includes the required information for Control Channel negotiation and is the primary mechanism for conveying support for this specification. The application/cfw MIME type is defined in this document to convey the appropriate SDP format for compliance to this specification. The Connection-Oriented Media (COMEDIA) [RFC4145] specification for setting up and maintaining reliable connections is used as part of the negotiation mechanism (more detail available in later sections). The Client also includes the 'cfw-id' SDP attribute, as defined in this specification, which is a unique identifier used to correlate the underlying Media Control Channel with the offer/answer exchange.

クライアントの構築と外部サーバに、[RFC3261]で定義されるような標準的なSIPは、INVITE要求を送信します。セッション記述プロトコル(SDP)ペイロードは、制御チャネルのネゴシエーションのために必要な情報が含まれており、本明細書のサポートを搬送するための主要なメカニズムです。アプリケーション/ CFWのMIMEタイプはこの仕様に準拠するために適切なSDPフォーマットを伝達するために、この文書で定義されています。セットアップおよび信頼性のある接続を維持する接続指向メディア(COMEDIA)[RFC4145]仕様は、ネゴシエーションメカニズム(後のセクションで利用可能詳細)の一部として使用されます。オファー/アンサー交換で基本となるメディア制御チャネルを相関させるために使用される一意の識別子であり、この仕様で定義されているクライアントはまた、「CFW-ID」SDP属性を含んでいます。

Client Sends to External Server:


INVITE SIP/2.0 To: <> From: <>;tag=64823746 Via: SIP/2.0/UDP;branch=z9hG4bK72d Call-ID: 7823987HJHG6 Max-Forwards: 70 CSeq: 1 INVITE Contact: <> Content-Type: application/sdp Content-Length: [..]

:< SIP:>:に SIP / 2.0:SIPのINVITE <一口>;タグ= 64823746経由:SIP / 2.0 / UDPクライアント。;ブランチ= z9hG4bK72dのCall-ID:7823987HJHG6マックス・フォワード:70のCSeq:1連絡先をINVITE:<>のContent-Type:アプリケーション/ SDPのContent-Length:[..]

v=0 o=originator 2890844526 2890842808 IN IP4 s=- c=IN IP4 m=application 49153 TCP cfw a=setup:active a=connection:new a=cfw-id:H839quwhjdhegvdga

アクティブA =接続:新A = CFW-ID:H839quwhjdhegvdga =セットアップC = IN IP4 M =アプリケーション49153 TCPのCFWのA - IP4 S = IN V = 0 0 =発信2890844526 2890842808

On receiving the INVITE request, an external Server supporting this mechanism generates a 200 OK response containing appropriate SDP and formatted using the application/cfw MIME type specified in this document. The Server inserts its own unique 'cfw-id' SDP attribute, which differs from the one received in the INVITE (offer).

INVITE要求を受信すると、このメカニズムをサポートする外部サーバは、適切なSDPこの文書で指定されたアプリケーション/ CFWのMIMEタイプを使用してフォーマットを含む200 OK応答を生成します。サーバーは、INVITE(申し出)で受信されたものとは異なる独自の「CFW-ID」SDP属性を、挿入されます。

External Server Sends to Client:


SIP/2.0 200 OK To: <>;tag=28943879 From: <>;tag=64823746 Via: SIP/2.0/UDP;branch=z9hG4bK72d;received=

SIP / 2.0 200 OKに:<>;タグ= 28943879から:<>;タグ= 64823746経由:SIP / 2.0 / UDP。ブランチ= z9hG4bK72d;受け取ら=

Call-ID: 7823987HJHG6 CSeq: 1 INVITE Contact: <> Content-Type: application/sdp Content-Length: [..]

コールIDを:7823987HJHG6のCSeq:1連絡先をINVITE:<>のContent-Type:アプリケーション/ SDPのContent-Length:[..]

v=0 o=responder 2890844526 2890842808 IN IP4 s=- c=IN IP4 m=application 7563 TCP cfw a=setup:passive a=connection:new a=cfw-id:U8dh7UHDushsdu32uha

V = 0 0 =レスポンダ2890844526 2890842808 IN IP4 S = - C = IN IP4 M =アプリケーション7563 TCPのCFWのA =セットアップ:受動A =接続:新しいA = CFW-ID:U8dh7UHDushsdu32uha

The Control Client receives the SIP 200 OK response and extracts the relevant information (also sending a SIP ACK). It creates an outgoing (as specified by the SDP 'setup' attribute of 'active') TCP connection to the Control Server. The connection address (taken from 'c=') and port (taken from 'm=') are used to identify the remote port in the new connection.

コントロールクライアントは、SIP 200 OK応答を受信し(またSIP ACKを送信する)関連情報を抽出します。これは、コントロール・サーバーへのTCP接続の発信(「アクティブ」のSDP「セットアップ」で指定された属性)を作成します。接続(「C =」から採取)アドレス及び(M「=」から取った)ポートは、新しい接続のリモートポートを識別するために使用されます。

Once established, the newly created connection can be used to exchange requests and responses as defined in this document. If required, after the Control Channel has been set up, media sessions can be established using standard SIP Third Party Call Control (3PCC) [RFC3725].


Figure 2 provides a simplified example where the framework is used to control a User Agent's RTP session.


                         +--------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


The link (1) represents the SIP INVITE dialog usage and dedicated Control Channel previously described in this overview section. The link (2) from Figure 2 represents the User Agent SIP INVITE dialog usage interactions and associated media flow. A User Agent creates a SIP INVITE dialog usage with the Control Client entity. The Control Client entity then creates a SIP INVITE dialog usage to the Control Server, using B2BUA type functionality. Using the interaction illustrated by (2), the Control Client negotiates media capabilities with the Control Server, on behalf of the User Agent, using SIP 3PCC. [RFC3725].

リンクは、(1)ダイアログ使用と以前にこの概要のセクションで説明した専用制御チャネルを、SIP INVITEを表します。図2からのリンク(2)は、ユーザエージェントSIPダイアログ使用の相互作用と関連するメディアフローをINVITE表します。ユーザエージェントは、SIPは、コントロールクライアントエンティティとの対話の使用をINVITE作成します。コントロールクライアントエンティティは、B2BUAタイプの機能を使用して、SIPは、制御サーバへのダイアログの使用をINVITE作成します。 (2)で示される相互作用を使用して、コントロールクライアントは、SIP 3PCCを使用して、ユーザーエージェントに代わって、制御サーバとメディア機能をネゴシエートします。 [RFC3725]。

4. Control Channel Setup

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).


4.1. Control Client SIP UAC Behavior
4.1. コントロールクライアントSIP UACの動作

When a UAC wishes to establish a Control Channel, it MUST construct and transmit a new SIP INVITE request for Control Channel setup. The UAC MUST construct the INVITE request as defined in [RFC3261].

UACは、制御チャネルを確立しようとするとき、それは、制御チャネルのセットアップのためのINVITEリクエストを新しいSIPを構築し、伝えなければなりません。 [RFC3261]で定義されるようにUACは、INVITE要求を構築しなければなりません。

If a reliable response is received (as defined in [RFC3261] and [RFC3262]), the mechanisms defined in this document are applicable to the newly created SIP INVITE dialog usage.


The UAC SHOULD include a valid session description (an 'offer' as defined in [RFC3264]) in an INVITE request using the Session Description Protocol defined in [RFC4566] but MAY choose an offer-less INVITE as per [RFC3261]. The SDP SHOULD be formatted in accordance with the steps below and using the MIME type application/ cfw, which is registered in Section 13. The following information defines the composition of specific elements of the SDP payload the offerer MUST adhere to when used in a SIP-based offer/answer exchange using SDP and the application/cfw MIME type. The SDP being constructed MUST contain only a single occurrence of a Control Channel definition outlined in this specification but can contain other media lines if required.

UACは、[RFC4566]で定義されたセッション記述プロトコルを使用してINVITE要求に有効なセッション記述([RFC3264]で定義されたとして「提供」)を含むべきであるが、[RFC3261]に従ってINVITEのオファーレスを選ぶかもしれません。 SDPは、以下の手順に従ってフォーマットし、以下の情報がSIPで使用する場合申出がに従う必要がありSDPペイロードの特定元素の組成を定義するセクション13に登録されたMIMEタイプapplication / CFWを使用する必要がありSDPおよびアプリケーション/ CFWのMIMEタイプを使用してベースのオファー/アンサー交換。 SDPは、本明細書で概説制御チャネル定義の単一の発生を含まなければなりませんが、必要に応じて他のメディア行を含むことができる構築されます。

The Connection Data line in the SDP payload is constructed as specified in [RFC4566]:


c=<nettype> <addrtype> <connection-address>

C = <NETTYPE> <ADDRTYPE> <接続アドレス>

The first sub-field, <nettype>, MUST equal the value "IN". The second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The third sub-field for Connection Data is <connection-address>. This supplies a representation of the SDP originator's address, for example, DNS/IP representation. The address is the address used for connections.

最初のサブフィールドは、<NETTYPE>、値「IN」と等しくなければなりません。第2サブフィールド、<ADDRTYPE>、「IP4」または「IP6」のいずれかを等しくなければなりません。接続データの第3のサブフィールドは、<接続アドレス>です。これは、例えば、DNS / IPの表現のために、SDP発信者のアドレスの表現を提供します。アドレスは、接続に使用されるアドレスです。



c=IN IP4

C IN = IP4

The SDP MUST contain a corresponding Media Description entry:


m=<media> <port> <proto> <fmt>

M = <メディア> <ポート> <プロト> <FMT>

The first "sub-field", <media>, MUST equal the value "application". The second sub-field, <port>, MUST represent a port on which the constructing client can receive an incoming connection if required. The port is used in combination with the address specified in the Connection Data line defined previously to supply connection details. If the entity constructing the SDP can't receive incoming connections, it must still enter a valid port entry. The use of the port value '0' has the same meaning as defined in a SIP offer/answer exchange [RFC3264]. The Control Framework has a default port defined in Section 13.5. This value is default, although a client is free to choose explicit port numbers. However, SDP SHOULD use the default port number, unless local policy prohibits its use. Using the default port number allows network administrators to manage firewall policy for Control Framework interactions. The third sub-field, <proto>, compliant to this specification, MUST support the values "TCP" and "TCP/TLS". Implementations MUST support TLS as a transport-level security mechanism for the Control Channel, although use of TLS in specific deployments is optional. Control Framework implementations MUST support TCP as a transport protocol. When an entity identifies a transport value but is not willing to establish the session, it MUST respond using the appropriate SIP mechanism. The <fmt> sub-field MUST contain the value "cfw".

最初の「サブフィールド」、<メディア>は、値「アプリケーション」に等しくなければなりません。第2サブフィールド、<ポート>は、必要に応じて構成するクライアントが着信接続を受信できるポートを表現しなければなりません。ポートは、接続の詳細を供給するために、以前に定義された接続データラインで指定されたアドレスと組み合わせて使用​​されます。 SDPを構築するエンティティが着信接続を受信できない場合、それはまだ有効なポートエントリを入力する必要があります。ポート値の使用は「0」SIPのオファー/アンサー交換[RFC3264]で定義されたものと同じ意味を持ちます。コントロールフレームワークは、13.5節で定義されたデフォルトのポートを持っています。クライアントは、明示的なポート番号を選択する自由があるが、この値は、デフォルトです。ローカルポリシーは、その使用を禁止している場合を除きしかし、SDPは、デフォルトのポート番号を使用する必要があります。デフォルトのポート番号を使用すると、ネットワーク管理者がコントロールフレームワークの相互作用のためのファイアウォールポリシーを管理することができます。第3サブフィールド、<プロト>、この仕様に準拠するには、値「TCP」および「TCP / TLS」をサポートしなければなりません。具体的な展開でTLSの使用は任意ですが、実装は、制御チャネルのためのトランスポート・レベルのセキュリティメカニズムとして、TLSをサポートしなければなりません。コントロールフレームワークの実装は、トランスポートプロトコルとしてTCPをサポートしなければなりません。エンティティは、トランスポート値を識別しますが、セッションを確立することを望んでいない場合は、適切なSIPメカニズムを使用して応答しなければなりません。 <FMT>サブフィールドは値「CFW」を含まなければなりません。

The SDP MUST also contain a number of SDP media attributes (a=) that are specifically defined in the COMEDIA [RFC4145] specification. The attributes provide connection negotiation and maintenance parameters. It is RECOMMENDED that a Controlling UAC initiate a connection to an external Server but that an external Server MAY negotiate and initiate a connection using COMEDIA, if network topology prohibits initiating connections in a certain direction. An example of the COMEDIA attributes is:

SDPはまた、具体的COMEDIA [RFC4145]仕様で定義されたSDPメディア属性(=)の数を含まなければなりません。属性は、接続ネゴシエーションと保守パラメータを提供します。制御UACが外部サーバーへの接続を開始することなく、ネットワークトポロジが特定の方向に接続を開始禁止した場合、外部サーバは、交渉とCOMEDIAを使用して接続を開始することができることが推奨されます。 COMEDIAの例がある属性:


This example demonstrates a new connection that will be initiated from the owner of the SDP payload. The connection details are contained in the SDP answer received from the UAS. A full example of an SDP payload compliant to this specification can be viewed in Section 3. Once the SDP has been constructed along with the remainder of the SIP INVITE request (as defined in [RFC3261]), it can be sent to the appropriate location. The SIP INVITE dialog usage and appropriate control connection is then established.

この例では、SDPペイロードの所有者から開始される新しい接続を示しています。接続の詳細は、UASから受信したSDPアンサーに含まれています。 SDPは、それが適切な場所に送信することができる([RFC3261]で定義されるように)SIP INVITE要求の残りの部分と一緒に構築された後、この仕様に準拠SDPペイロードの完全な例は、セクション3に見ることができます。 SIPは、ダイアログの使用を招待し、適切な制御接続はその後、確立されています。

A SIP UAC constructing an offer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. The 'cfw-id' attribute indicates an identifier that can be used within the Control Channel to correlate the Control Channel with this SIP INVITE dialog usage. The 'cfw-id' attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/answer exchanges. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange. This applies specifically to the 'connection' attribute as defined in [RFC4145]. If a SIP UAC wants to change some other parts of the SDP but reuse the already established connection, it uses the value of 'existing' in the 'connection' attribute (for example, a=connection:existing). If it has noted that a connection has failed and wants to re-establish the connection, it uses the value of 'new' in the 'connection' attribute (for example, a=connection:new). Throughout this, the connection identifier specified in the 'cfw-id' SDP parameter MUST NOT change. One is simply negotiating the underlying TCP connection between endpoints but always using the same Control Framework session, which is 1:1 for the lifetime of the SIP INVITE dialog usage.

セクション9.2で定義されるようにオファーを構築するSIP UACは、「CFW-ID」SDP属性を含まなければなりません。 「CFW-ID」属性は、ダイアログの使用をINVITEこのSIPで制御チャネルを相関させるために制御チャネル内で使用可能な識別子を示します。 「CFW-ID」属性は、UACとUAS間の相互作用のコンテキスト内で一意である必要があり、他のSIPオファー/アンサー交換に使用される「CFW-ID」のインスタンスと衝突してはなりません。 「CFW-ID」属性のために選択された値は、ダイアログ使用を招待オファー/アンサー交換の更新時に変更されていない関連するSIPの全期間のために使用されなければなりません。 [RFC4145]で定義されたように、これは「接続」属性に特異的に適用されます。 SIP UACは、SDPのいくつかの他の部分を変更するが、すでに確立された接続を再利用したい場合は、「接続」属性での既存の '(:既存例えば、A =接続)の値を使用しています。それは、接続が失敗し、接続を再確立したいと考えていたことを指摘している場合、それは(:新たとえば、A =接続のために)「接続」属性で「新しい」の値を使用しています。このを通じて、「CFW-ID」で指定された接続識別子は、SDPパラメータが変化してはいけません。一つは、単にエンドポイント間の基本的なTCPコネクションを交渉するが、常に1で同じコントロールフレームワークセッション、使用している:ダイアログの使用を、SIP INVITEの存続期間1。

A non-2xx-class final SIP response (3xx, 4xx, 5xx, and 6xx) received for the INVITE request indicates that no SIP INVITE dialog usage has been created and is treated as specified by SIP [RFC3261]. Specifically, support of this specification is negotiated through the presence of the media type defined in this specification. The receipt of a SIP error response such as "488" indicates that the offer contained in a request is not acceptable. The inclusion of the media line associated with this specification in such a rejected offer indicates to the client generating the offer that this could be due to the receiving client not supporting this specification. The client generating the offer MUST act as it would normally on receiving this response, as per [RFC3261]. Media streams can also be rejected by setting the port to "0" in the "m=" line of the session description, as defined in [RFC3264]. A client using this specification MUST be prepared to receive an answer where the "m=" line it inserted for using the Control Framework has been set to "0".

INVITE要求は全くSIPダイアログ使用が作成され、SIP [RFC3261]によって指定されるように処理されたINVITEないことを示すための非2xxのクラスの最終SIP応答(3XX、4XX、5xxの、および6xxの)を受け取りました。具体的には、本明細書のサポートは、本明細書で定義されているメディアタイプの存在を介して交渉されます。例えば、「488」のようなSIPエラー応答の受信は、要求に含まれるオファーが受け入れられないことを示しています。そのような拒否オファーに本明細書に関連付けられたメディア行を含めることがこの仕様をサポートしていない受信クライアントに起因することができると提案を生成するクライアントに指示します。プランを生成するクライアントは[RFC3261]に従って、この応答を受けた上で通常と同じように行動しなければなりません。 [RFC3264]で定義されるようにメディアストリームは、セッション記述の「M =」の行に「0」のポートを設定することによって排除することができます。この仕様を使用して、クライアントは、それがコントロールフレームワークを使用するための挿入「M =」行「0」に設定された回答を受信するように準備しなければなりません。

In this situation, the client will act as it would for any other media type with a port set to "0".


4.2. Control Server SIP UAS Behavior
4.2. コントロールサーバSIP UASの動作

On receiving a SIP INVITE request, an external Server (SIP UAS) inspects the message for indications of support for the mechanisms defined in this specification. This is achieved through inspection of the session description of the offer message and identifying support for the application/cfw MIME type in the SDP. If the SIP UAS wishes to construct a reliable response that conveys support for the extension, it MUST follow the mechanisms defined in [RFC3261]. If support is conveyed in a reliable SIP provisional response, the mechanisms in [RFC3262] MUST also be used. It should be noted that the SDP offer is not restricted to the initial INVITE request and MAY appear in any series of messages that are compliant to [RFC3261], [RFC3262], [RFC3311], and [RFC3264].

SIP INVITEリクエストを受信すると、外部サーバ(SIP UAS)は、本明細書で定義されたメカニズムのためのサポートの表示のためにメッセージを検査します。これは、SDP内のアプリケーション/ CFWのMIMEタイプのオファーメッセージのセッション記述の検査および識別のサポートによって達成されます。 SIP UASは、拡張のサポートを伝える信頼できる応答を構築したい場合は、[RFC3261]で定義されたメカニズムに従わなければなりません。サポートが信頼SIP暫定応答で搬送されている場合は、[RFC3262]での機構も使用しなければなりません。 SDPオファーがINVITEリクエストを初期に限定されるものではなく、[RFC3261]、[RFC3262]、[RFC3311]、および[RFC3264]に準拠しているメッセージのいずれかのシリーズに現れることに留意すべきです。

When constructing an answer, the SDP payload MUST be constructed using the semantic (connection, media, and attribute) defined in Section 4.1 using valid local settings and also with full compliance to the COMEDIA [RFC4145] specification. For example, the SDP attributes included in the answer constructed for the example offer provided in Section 4.1 would look as follows:

答えを構築する場合、SDPペイロードはCOMEDIA [RFC4145]仕様に完全に準拠しても有効なローカル設定を使用して、セクション4.1で定義されたセマンティック(接続、メディア、および属性)を使用して構築されなければなりません。例えば、SDPの属性は次のようになります4.1で提供される例の提供のために構築の答えに含ま:


A client constructing an answer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. This attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/ answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id' value received in the offer as it is used to uniquely identify and distinguish between multiple endpoints that generate SDP answers. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange.

セクション9.2で定義されているような答えを構築し、クライアントは「CFW-ID」SDP属性を含まなければなりません。この属性は、UACとUAS間の相互作用の文脈の中で一意である必要があり、他のSIPオファー/アンサー交換に使用される「CFW-ID」のインスタンスと衝突してはなりません。 「CFW-ID」は、それを一意に識別し、SDP回答を生成する複数のエンドポイントを区別するために使用されるオファーで受信した「CFW-ID」値異なっていなければなりません。 「CFW-ID」属性のために選択された値は、ダイアログ使用を招待オファー/アンサー交換の更新時に変更されていない関連するSIPの全期間のために使用されなければなりません。

Once the SDP answer has been constructed, it is sent using standard SIP mechanisms. Depending on the contents of the SDP payloads that were negotiated using the offer/answer exchange, a reliable connection will be established between the Controlling UAC and External Server UAS entities. The newly established connection is now available to exchange Control Command primitives. The state of the SIP INVITE dialog usage and the associated Control Channel are now implicitly linked. If either party wishes to terminate a Control Channel, it simply issues a SIP termination request (for example, a

SDP答えが構築されたら、それは標準のSIPメカニズムを使用して送信されます。オファー/アンサー交換を使用して交渉されたSDPペイロードの内容によっては、信頼性の高い接続は、制御UACとUAS外部サーバーのエンティティ間で確立されます。新しく確立された接続は現在、制御コマンドプリミティブを交換するために利用可能です。 SIPの状態は今、暗黙的にリンクされているダイアログの使用とそれに関連する制御チャネルを招待します。いずれかの当事者が制御チャネルを終了しようとする場合、それは単に、例えば(SIP終了要求を発行します

SIP BYE request or appropriate response in an early SIP INVITE dialog usage). The Control Channel therefore lives for the duration of the SIP INVITE dialog usage.

SIPのBYE要求または早期SIPにおける適切な応答ダイアログの使用をINVITE)。制御チャネルは、そのためのダイアログの使用を、SIP INVITEの期間中に住んでいます。

A UAS receiving a SIP OPTIONS request MUST respond appropriately as defined in [RFC3261]. The UAS MUST include the media types supported in the SIP 200 OK response in a SIP 'Accept' header to indicate the valid media types.

[RFC3261]で定義されるようにSIP OPTIONS要求を受信するUASは、適切に応答しなければなりません。 UASは、有効なメディアの種類を示すために、ヘッダ」を受け入れる] SIPにSIP 200 OK応答でサポートされているメディアタイプを含まなければなりません。

5. Establishing Media Streams - Control Client SIP UAC Behavior
5.メディアストリームの確立 - コントロールクライアントSIP UACの動作を

It is intended that the Control Framework will be used within a variety of architectures for a wide range of functions. One of the primary functions will be the use of the Control Channel to apply multiple specific Control Package commands to media sessions established by SIP INVITE dialogs (media dialogs) with a given remote server. For example, the Control Server might send a command to generate audio media (such as an announcement) on an RTP stream between a User Agent and a media server.

コントロールフレームワークは、機能の広い範囲のためのアーキテクチャの様々な内で使用されることが意図されます。主な機能の1つは、複数の特定の制御パッケージを適用するための制御チャネルの使用は、特定のリモートサーバーとの対話(メディア・ダイアログ)を、SIP INVITEによって確立されたメディアセッションにコマンドになります。例えば、制御サーバはユーザエージェントとメディアサーバー間のRTPストリーム上で(例えば告知など)オーディオメディアを生成するためのコマンドを送信することがあります。

SIP INVITE dialogs used to establish media sessions (see Figure 2) on behalf of User Agents MAY contain more than one Media Description (as defined by "m=" in the SDP). The Control Client MUST include a media label attribute, as defined in [RFC4574], for each "m=" definition received that is to be directed to an entity using the Control Framework. This allows the Control Client to later explicitly direct commands on the Control Channel at a specific media line (m=).

メディアセッションを確立するために使用されるダイアログを、SIP INVITE(SDPにおけるによって定義されるような「M =」)以上のメディア記述を含むかもしれユーザエージェントに代わって(図2参照)。 [RFC4574]で定義されるようにコントロールクライアントは、メディアラベル属性を含まなければなりません、それぞれについて「M =」の定義は、それがコントロールフレームワークを使用してエンティティに向けられることである受信しました。これは、特定のメディア行(M =)で制御チャネル上で、後に明示的にダイレクトコマンドにコントロールクライアントを可能にします。

This framework identifies the referencing of such associated media dialogs as extremely important. A connection reference attribute has been specified that can optionally be imported into any Control Package. It is intended that this will reduce the repetitive specifying of dialog reference language. The schema can be found in Appendix A.1.


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.


Support for both the common attributes described here is specified as part of each Control Package definition, as detailed in Section 8.


6. Control Framework Interactions

In this document, the use of the COMEDIA specification allows for a Control Channel to be set up in either direction as a result of a SIP INVITE transaction. SIP provides a flexible negotiation mechanism to establish the Control Channel, but there needs to be a mechanism within the Control Channel to correlate it with the SIP INVITE dialog usage implemented for its establishment. A Control Client receiving an incoming connection (whether it be acting in the role of UAC or UAS) has no way of identifying the associated SIP INVITE dialog usage as it could be simply listening for all incoming connections on a specific port. The following steps, which implementations MUST support, allow a connecting UA (that is, the UA with the active role in COMEDIA) to identify the associated SIP INVITE dialog usage that triggered the connection. Unless there is an alternative dialog association mechanism used, the UAs MUST carry out these steps before any other signaling on the newly created Control Channel.

制御チャネルは、SIP INVITE取引の結果として、どちらの方向に設定されるため、このドキュメントでは、COMEDIA仕様の使用ができます。 SIPは、制御チャネルを確立するための柔軟な交渉メカニズムを提供していますが、その設立のために実装ダイアログの使用を、SIP INVITEとそれを相関させる制御チャネル内のメカニズムが必要です。 (それは、UACまたはUASの役割で作用するかどうか)の着信接続を受信制御クライアントは、単に特定のポート上のすべての着信接続をリスンすることができるように関連付けられたSIPダイアログ使用をINVITE識別する方法がありません。実装がサポートしなければならない次のステップは、接続をトリガダイアログ使用をINVITE関連したSIPを識別するために(すなわち、COMEDIAにおいて積極的な役割を持つUA)と接続UAを可能にします。使用される代替ダイアログ・アソシエーション・メカニズムがない限り、UAは、新しく作成された制御チャネル上の他のシグナリング前に、次の手順を実行しなければなりません。

o Once the connection has been established, the UA acting in the active role (active UA) to initiate the connection MUST send a Control Framework SYNC request. The SYNC request MUST be constructed as defined in Section 9.1 and MUST contain the 'Dialog-ID' message header.

接続が確立されたらO、UAは、コントロールフレームワークSYNC要求を送らなければなりません接続を開始するために積極的な役割(アクティブUA)に作用します。 SYNC要求は、セクション9.1で定義されるように構成されなければならなくて、「ダイアログID」メッセージヘッダを含まなければなりません。

o The 'Dialog-ID' message header is populated with the value of the local 'cfw-id' media-level attribute that was inserted by the same client in the SDP offer/answer exchange to establish the Control Channel. This allows for a correlation between the Control Channel and its associated SIP INVITE dialog usage.


o On creating the SYNC request, the active UA MUST follow the procedures outlined in Section 6.3.3. This provides details of connection keep-alive messages.

O SYNC要求を作成する、アクティブUAは、セクション6.3.3に概説された手順に従わなければなりません。これは、接続キープアライブメッセージの詳細を提供します。

o On creating the SYNC request, the active UA MUST also follow the procedures outlined in Section This provides details of the negotiation mechanism used to determine the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection.

O SYNC要求を作成する、アクティブUAはまた、セクション6.3.4.2に概説された手順に従わなければなりません。これは、確立された制御チャネル接続で交換することができるプロトコルデータユニット(PDU)を決定するために使用する交渉メカニズムの詳細を提供します。

o The UA in the active role for the connection creation MUST then send the SYNC request. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a 2xx-class SIP response, it MUST wait for an incoming SIP ACK message before issuing the SYNC. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a reliable 1XX class SIP response, it MUST wait for an incoming SIP PRACK message before issuing the SYNC.

O接続を作成するための積極的な役割でUAは、SYNC要求を送らなければなりません。 UAは、接続を作成するための積極的な役割にSIP UASであるとの2xxクラスのSIP応答でのSDP応答を生成した場合には、SYNCを発行する前に、着信SIP ACKメッセージを待たなければなりません。 UAは、接続を作成するための積極的な役割にSIP UASで、信頼性の高い1XXクラスSIP応答のSDPその応答を生成した場合には、SYNCを発行する前に、着信SIP PRACKメッセージを待たなければなりません。

If the UA in the active role for the connection creation is a SIP UAC, it MUST send the SYNC message immediately on establishment of the Control Channel. It MUST then wait for a period of at least 2*'Transaction-Timeout' to receive a response. It MAY choose a longer time to wait, but it MUST NOT be shorter than 'Transaction-Timeout'. In general, a Control Framework transaction MUST complete within 20 (2*'Transaction-Timeout') seconds and is referenced throughout the document as 'Transaction-Timeout'.

接続の作成のための積極的な役割でUAがSIP UACであれば、それは制御チャネルの確立にすぐにSYNCメッセージを送らなければなりません。その後、応答を受信するために、少なくとも2 *「トランザクション・タイムアウト」の期間を待つ必要があります。それは待つ長い時間を選ぶかもしれないが、それは、「トランザクション・タイムアウト」より短くてはなりません。一般的には、コントロールフレームワークのトランザクションは、20(2 *「トランザクション・タイムアウト」)秒以内に完了しなければならないと「トランザクションタイムアウト」などの文書全体で参照されます。

o If no response is received for the SYNC message, a timeout occurs and the Control Channel is terminated along with the associated SIP INVITE dialog usage. The active UA MUST issue a BYE request to terminate the SIP INVITE dialog usage.

応答がSYNCメッセージを受信されない場合、O、タイムアウトが発生し、制御チャネルは、ダイアログを使用INVITE関連SIPと共に終了します。アクティブUAは、ダイアログの使用を、SIP INVITEを終了するBYEリクエストを発行しなければなりません。

o If the active UA receives a 481 response from the passive UA, this means the SYNC request was received, but the associated SIP INVITE dialog usage specified in the SYNC message does not exist. The active client MUST terminate the Control Channel. The active UA MUST issue a SIP BYE request to terminate the SIP INVITE dialog usage.

アクティブUAは受動UAからの481応答を受信した場合、O、これはSYNC要求が受信されたことを意味するが、SYNCメッセージで指定された関連したSIP INVITEダイアログ使用法は存在しません。アクティブなクライアントは、制御チャネルを終えなければなりません。アクティブUAは、ダイアログの使用を、SIP INVITEを終了させるSIP BYEリクエストを発行しなければなりません。

o All other error responses received for the SYNC request are treated as detailed in this specification and also result in the termination of the Control Channel and the associated SIP INVITE dialog usage. The active UA MUST issue a BYE request to terminate the SIP INVITE dialog usage.

制御チャネルの終了と関連したSIPダイアログを使用INVITEをもたらし、また、本明細書に詳述としてO SYNC要求を受信した他のすべてのエラー応答が処理されます。アクティブUAは、ダイアログの使用を、SIP INVITEを終了するBYEリクエストを発行しなければなりません。

o The receipt of a 200 response to a SYNC message implies that the SIP INVITE dialog usage and control connection have been successfully correlated. The Control Channel can now be used for further interactions.

O SYNCメッセージに対する200応答の受信は、SIPが正常に相関しているダイアログ使用および制御接続をINVITEことを意味します。制御チャネルは、ここでさらに相互作用のために使用することができます。

SYNC messages can be sent at any point while the Control Channel is open from either side, once the initial exchange is complete. If present, the contents of the 'Keep-Alive' and 'Dialog-ID' headers MUST NOT change. New values of the 'Keep-Alive' and 'Dialog-ID' headers have no relevance as they are negotiated for the lifetime of the Media Control Channel Framework session.


Once a successful Control Channel has been established, as defined in Sections 4.1 and 4.2, and the connection has been correlated, as described in previous paragraphs, the two entities are now in a position to exchange Control Framework messages. The following sub-sections specify the general behavior for constructing Control Framework requests and responses. Section 6.3 specifies the core Control Framework methods and their transaction processing.

セクション4.1と4.2で定義されて成功した制御チャネルは、確立されており、前の段落で説明したように、接続は、相関された後、2つのエンティティは、コントロールフレームワークのメッセージを交換する立場になりました。以下のサブセクションでは、コントロールフレームワークの要求と応答を構築するための一般的な動作を指定します。 6.3節は、コアコントロールフレームワークのメソッドとそれらのトランザクション処理を指定します。

6.1. General Behavior for Constructing Requests
6.1. リクエストを構築するための一般的な動作

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

構築し、制御チャネル上の要求はいずれかのエンティティは、個々のパッケージの要件に応じてコントロールクライアントとして作用することができることを第9ノートで定義された構文に準拠する必要があります送信コントロールクライアントとして動作するエンティティ。制御コマンドはまた、セクション4.1と、この文書の4.2で交渉制御パッケージで定義された構文に準拠する必要があります。コントロールクライアントは、要求に挿入するための固有のトランザクションと関連付けられた識別子を作成する必要があります。最初の行は容易トランザクション識別子を抽出するために、「CFW」トークンで始まる項9にABNFで定義されているトランザクション識別子は、その後、メソッドタイプと共にコントロールフレームワークメッセージの最初の行に含まれています。トランザクション識別子は、コントロールクライアントと管理サーバー間の相互作用の文脈の中でユニークでなければなりません。このユニークなプロパティは、複数のクライアントエンティティは、単一の受信用サーバ上で実行されるトランザクションを作成することができたときの衝突を避けることができます。すべての必要な、必須の、およびオプションのコントロールフレームワークヘッダーは、次に、適切な値(明示的に詳細に関連する個々のヘッダ情報を参照)とのリクエストに挿入されます。 「コントロール・パッケージ」ヘッダはまた、この特定の要求が適用される制御パッケージを示す値で挿入されなければなりません。複数のパッケージは、セクション6.3.4.2で述べたSYNCメッセージを使用して制御チャネルごとに交渉することができます。

Any Framework message that contains an associated payload MUST also include the 'Content-Type' and 'Content-Length' message headers, which indicate the MIME type of the payload specified by the individual Control Framework packages and the size of the message body represented as a whole decimal number of octets, respectively. If no associated payload is to be added to the message, the 'Content-Length' header MUST have a value of '0'.


A Server receiving a Framework message request MUST respond with an appropriate response (as defined in Section 6.2). Control Clients MUST wait for a minimum of 2*'Transaction-Timeout' for a response before considering the transaction a failure and tidying state appropriately depending on the extension package being used.

フレームワークメッセージ要求を受信したサーバは、(セクション6.2で定義されるように)適切な応答で応答しなければなりません。コントロールクライアントがトランザクションに失敗したことを考慮して使用されている拡張パッケージに応じて適宜状態を片付け前に応答を2 *「トランザクション・タイムアウト」の最小値を待つ必要があります。

6.2. General Behavior for Constructing Responses
6.2. 応答を構築するための一般的な動作

An entity acting as a Control Server, on receiving a request, MUST generate a response within the 'Transaction-Timeout', as measured from the Control Client. The response MUST conform to the ABNF defined in Section 9. The first line of the response MUST contain the transaction identifier used in the first line of the request, as defined in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' message headers, and these MUST be ignored if received by a Client in a response.


A Control Server MUST include a status code in the first line of the response. If there is no error, the Server responds with a 200 Control Framework status code, as defined in Section 7.1. The 200 response MAY include message bodies. If the response contains a payload, the message MUST include the 'Content-Length' and 'Content-Type' headers. When the Control Client receives a 2xx-class response, the Control Command transaction is complete.

制御サーバは、応答の最初のラインのステータスコードを含まなければなりません。エラーがない場合、サーバはセクション7.1で定義されるように、200コントロールフレームワークのステータスコードで応答します。 200応答は、メッセージ本文を含むかもしれません。応答はペイロードが含まれている場合、メッセージは、「のContent-Length」や「Content-Typeの」ヘッダを含まなければなりません。コントロールクライアントが2XXクラスの応答を受信すると、制御コマンドのトランザクションが完了しています。

If the Control Server receives a request, like CONTROL, that the Server understands, but the Server knows processing the command will exceed the 'Transaction-Timeout', then the Server MUST respond with a 202 status code in the first line of the response. Following the initial response, the server will send one or more REPORT messages as described in Section 6.3.2. A Control Package MUST explicitly define the circumstances under which the server sends 200 and 202 messages.

サーバーが理解するが、Serverは「トランザクションタイムアウト」を超過するコマンドを処理して知っていることを制御サーバは、CONTROLのような要求を受信した場合、サーバは、応答の最初の行に202のステータスコードで応じなければなりません。 6.3.2項で説明したように初期応答の後、サーバは、1つまたは複数のREPORTメッセージを送信します。制御パッケージは、明示的にサーバが200と202のメッセージを送信する状況を定義しなければなりません。

If a Control Server encounters problems with a Control Framework request (like REPORT or CONTROL), an appropriate error code MUST be used in the response, as listed in Section 7. The generation of a non-2xx-class response code to a Control Framework request (like CONTROL or REPORT) will indicate failure of the transaction, and all associated transaction state and resources MUST be terminated. The response code may provide an explicit indication of why the transaction failed, which might result in a re-submission of the request depending on the extension package being used.


6.3. Transaction Processing
6.3. トランザクション処理

The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods.


The following sub-sections specify each Control Framework method and its associated transaction processing.


6.3.1. CONTROL Transactions
6.3.1. 制御トランザクション

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.


6.3.2. REPORT Transactions
6.3.2. REPORT取引

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.


All REPORT messages MUST contain the same transaction ID in the request start line that was present in the original CONTROL transaction. This correlates extended transactions with the original CONTROL transaction. A REPORT message containing a payload MUST include the 'Content-Type' and 'Content-Length' headers indicating the payload MIME type [RFC2045] defined by the Control Package and the length of the payload, respectively.

すべてのREPORTメッセージは、元の制御トランザクションに存在した要求のスタートラインに同じトランザクションIDを含まなければなりません。これは、元の制御トランザクションと拡張されたトランザクションを相関させます。ペイロードを含むREPORTメッセージは、「コンテンツタイプ」とはそれぞれ、制御パッケージによって定義されたペイロードのMIMEタイプ[RFC2045]及びペイロードの長さを示す「のContent-Length」ヘッダを含まなければなりません。 Reporting the Status of Extended Transactions。拡張取引の状況を報告

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.


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.


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.


All REPORT messages for an extended CONTROL transaction MUST contain a 'Timeout' message header. This header will contain a value in seconds that is the amount of time the recipient of the REPORT message MUST wait before assuming that there has been a problem and terminating the extended transaction and associated state. On receiving a REPORT message with a 'Status' header of 'update', the Control Client MUST reset the timer for the associated extended CONTROL transaction to the indicated timeout period. If the timeout period approaches and no intended REPORT messages have been generated, the entity acting as a Control Framework UAS for the interaction MUST generate a REPORT message containing, as defined in this paragraph, a 'Status' header of 'update' with no associated payload. Such a message acts as a timeout refresh and in no way impacts the extended transaction because no message body or semantics are permitted. It is RECOMMENDED that a minimum value of 10 and a maximum value of 15 seconds be used for the value of the 'Timeout' message header. It is also RECOMMENDED that a Control Server refresh the timeout period of the CONTROL transaction at an interval that is not too close to the expiry time. A value of 80% of the timeout period could be used. For example, if the timeout period is 10 seconds, the Server would refresh the transaction after 8 seconds.

拡張制御トランザクションのすべてのレポートメッセージは「タイムアウト」メッセージヘッダを含まなければなりません。このヘッダは、REPORTメッセージの受信者は問題があったと仮定すると、拡張トランザクションと関連付けられた状態を終了する前に待機しなければならない時間の量であり、秒単位で値を含むであろう。 「更新」の「ステータス」ヘッダとREPORTメッセージを受信すると、クライアントの制御は指示されたタイムアウト時間に関連する拡張制御トランザクションのタイマーをリセットしなければなりません。タイムアウト期間アプローチと無意図REPORTメッセージが生成されている場合は、この段落、無関連のある「更新」の「ステータス」ヘッダに定義されているように、エンティティは、含有REPORTメッセージを生成しなければならない相互作用のためのコントロールフレームワークUASとして動作しますペイロード。メッセージ・ボディやセマンティクスが許可されていないため、このようなメッセージは、拡張トランザクションタイムアウトリフレッシュとしてあり、決してへの影響に作用します。 10の最小値と15秒の最大値は「タイムアウト」メッセージヘッダーの値のために使用することを推奨されています。また、制御サーバが有効期限に近づきすぎない間隔で制御トランザクションのタイムアウト期間を更新することが推奨されます。タイムアウト期間の80%の値を使用することができます。タイムアウト期間が10秒であれば、例えば、サーバーは8秒後にトランザクションを更新します。

Subsequent REPORT messages that provide additional information relating to the extended CONTROL transaction MUST also include and increment by 1 the 'Seq' header value. A REPORT message received that has not been incremented by 1 MUST be responded to with a 406 response and the extended transaction MUST be considered terminated. On receiving a 406 response, the extended transaction MUST be terminated. REPORT messages MUST also include a 'Status' header with a value of 'update'. These REPORT messages sent to update the extended CONTROL transaction status MAY contain a message body, as defined by individual Control Packages and specified in Section 8.5. A REPORT message sent updating the extended transaction also acts as a timeout refresh, as described earlier in this section. This will result in a transaction timeout period at the initiator of the original CONTROL request being reset to the interval contained in the 'Timeout' message header.

拡張制御トランザクションに関する追加情報を提供して、後続のREPORTメッセージはまた、1「配列」ヘッダの値によって含み、インクリメントしなければなりません。 REPORTメッセージ406応答で応答しなければならない1だけインクリメントされておらず、拡張トランザクションを終了考慮しなければならないことを受け取りました。 406応答を受信すると、拡張トランザクションを終えなければなりません。 REPORTメッセージは、「更新」の値と「ステータス」ヘッダを含まなければなりません。個々の制御パッケージで定義され、セクション8.5で指定された拡張制御トランザクションのステータスを更新するために送られたこれらのREPORTメッセージは、メッセージ本文を含むかもしれません。前述のセクションで説明するように拡張されたトランザクションの更新を送信REPORTメッセージは、タイムアウトリフレッシュとして作用します。これは、「タイムアウト」メッセージヘッダに含まれる間隔にリセットされ、元の制御要求の開始時にトランザクションのタイムアウト期間をもたらすであろう。

When all processing for an extended CONTROL transaction has taken place, the entity acting as a Control Server MUST send a terminating REPORT message. The terminating REPORT message MUST increment the value in the 'Seq' message header by the value of '1' from the previous REPORT message. It MUST also include a 'Status' header with a value of 'terminate' and MAY contain a message body. It MUST also contain a 'Timeout' message header with a valid value. The inclusion of the 'Timeout' header is for consistency, and its value is ignored. A Control Framework UAC can then clean up any pending state associated with the original CONTROL transaction.

拡張制御トランザクションのすべての処理が行われた場合には、コントロール・サーバーとして動作するエンティティは、終端REPORTメッセージを送らなければなりません。終端REPORTメッセージは、以前の報告メッセージから「1」の値で「配列」メッセージヘッダーの値をインクリメントしなければなりません。それはまた、「終了」の値が「ステータス」ヘッダを含まなければなりませんとメッセージ本体を含むかもしれません。また、有効な値に「タイムアウト」メッセージヘッダを含まなければなりません。 「タイムアウト」ヘッダを含めることは、一貫性のためであり、その値は無視されます。コントロールフレームワークUACは、元の制御トランザクションに関連付けられているすべての保留状態をクリーンアップすることができます。

6.3.3. K-ALIVE Transactions
6.3.3. K-ALIVE取引

The protocol defined in this document may be used in various network architectures. This includes a wide range of deployments where the clients could be co-located in a secured, private domain, or spread across disparate domains that require traversal of devices such as Network Address Translators (NATs) and firewalls. A keep-alive mechanism enables the Control Channel to be kept active during times of inactivity. This is because many firewalls have a timeout period after which connections are closed. This mechanism also provides the ability for application-level failure detection. It should be noted that the following procedures apply only to the Control Channel being created. For details relating to the SIP keep-alive mechanism, implementers should seek guidance from SIP Outbound [RFC5626].

この文書で定義されたプロトコルは、様々なネットワークアーキテクチャで使用することができます。これは、クライアントがセキュリティで保護された、プライベートドメイン内に同じ場所に配置、または、そのような翻訳器(NAT)やファイアウォールアドレス、ネットワークなどのデバイスの横断を必要と本質的に異なるドメイン間で分散させることができ展開の広い範囲を含みます。キープアライブメカニズムは、制御チャネルが非アクティブの時間中にアクティブに保つことができます。多くのファイアウォールは、接続が閉じられた後のタイムアウト期間を持っているためです。このメカニズムは、アプリケーション・レベルの故障検出能力を提供します。以下の手順でのみ作成される制御チャネルに適用されることに留意すべきです。 SIPのキープアライブメカニズムに関する詳細については、実装者は、SIPアウトバウンド[RFC5626]から指導を求めるべきです。

The following keep-alive procedures MUST be implemented. Specific deployments MAY choose not to use the keep-alive mechanism if both entities are in a co-located domain. Note that choosing not to use the keep-alive mechanism defined in this section, even when in a co-located architecture, will reduce the ability to detect application-level errors, especially during long periods of inactivity.


Once the SIP INVITE dialog usage has been established and the underlying Control Channel has been set up, including the initial correlation handshake using SYNC as discussed in Section 6, both entities acting in the active and passive roles, as defined in COMEDIA [RFC4145], MUST start a keep-alive timer equal to the value negotiated during the Control Channel SYNC request/response exchange. This is the value from the 'Keep-Alive' header in seconds.

SIP一旦ダイアログ使用法が確立されており、下にある制御チャネルは、セクション6で説明したように、SYNCを使用して初期相関ハンドシェークを含め、設定されたINVITE COMEDIA [RFC4145]で定義されるように、能動的および受動的な役割に作用する両方のエンティティ、制御チャネルSYNC要求/応答交換時にネゴシエートされた値に等しいキープアライブタイマーを起動する必要があります。これは、秒の「キープアライブ」ヘッダーからの値です。 Behavior for an Entity in an Active Role。積極的な役割でエンティティのための行動

When in an active role, a K-ALIVE message MUST be generated before the local keep-alive timer fires. An active entity is free to send the K-ALIVE message whenever it chooses. It is RECOMMENDED for the entity to issue a K-ALIVE message after 80% of the local keep-alive timer. On receiving a 200 OK Control Framework message for the

積極的な役割で、K-ALIVEメッセージは、ローカルのキープアライブタイマーが起動する前に生成しなければならないとき。アクティブなエンティティは、選択した時はいつでもK-ALIVEメッセージを送信するために自由です。エンティティはローカルキープアライブタイマーの80%の後にK-ALIVEメッセージを発行することをお勧めします。 200 OKコントロールフレームワークのメッセージを受信すると

K-ALIVE request, the active entity MUST reset the local keep-alive timer. If no 200 OK response is received to the K-ALIVE message, or a transport-level problem is detected by some other means, before the local keep-alive timer fires, the active entity MAY use COMEDIA re-negotiation procedures to recover the connection. Otherwise, the active entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.

K-ALIVE要求、アクティブなエンティティは、ローカルキープアライブタイマーをリセットしなければなりません。何の200 OK応答は、K-ALIVEメッセージを受信して​​いない、またはトランスポートレベルの問題は、ローカルのキープアライブタイマーが起動する前に、いくつかの他の手段によって検出された場合、アクティブなエンティティは、接続を回復するためにCOMEDIA再交渉の手順を使用してもよい(MAY) 。それ以外の場合は、アクティブなエンティティは、ダイアログ、SIP INVITEを取り壊すと、関連する制御チャネルリソースを回復する必要があります。 Behavior for an Entity in a Passive Role。受動的な役割でエンティティの挙動

When acting as a passive entity, a K-ALIVE message must be received before the local keep-alive timer fires. When a K-ALIVE request is received, the passive entity MUST generate a 200 OK Control Framework response and reset the local keep-alive timer. No other Control Framework response is valid. If no K-ALIVE message is received (or a transport level problem is detected by some other means) before the local keep-alive timer fires, the passive entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.

受動的なエンティティとして動作する場合には、K-ALIVEメッセージは、ローカルのキープアライブタイマーが起動する前に受信する必要があります。 K-ALIVE要求を受信すると、受動的なエンティティは、200 OKコントロールフレームワークの応答を生成し、ローカルキープアライブタイマーをリセットしなければなりません。他のコントロールフレームワークの応答が有効ではありません。何のK-ALIVEメッセージはローカルキープアライブタイマーが起動する前に受信されない(またはトランスポートレベルの問題がいくつかの他の手段によって検出された)場合は、パッシブエンティティは、SIP INVITEダイアログ取り壊すと関連する制御チャネルリソースを回復する必要があります。

6.3.4. SYNC Transactions
6.3.4. SYNC取引

The initial SYNC request on a Control Channel is used to negotiate the timeout period for the Control Channel keep-alive mechanism and to allow clients and servers to learn the Control Packages that each supports. Subsequent SYNC requests MAY be used to change the set of Control Packages that can be used on the Control Channel.

制御チャネル上の最初のSYNC要求が制御チャネルキープアライブメカニズムのタイムアウト時間を交渉すると、クライアントとサーバーが制御パッケージそれぞれがサポートを学ぶことを可能にするために使用されます。後続のSYNC要求が制御チャネル上で使用することができる制御パッケージのセットを変更するために使用されるかもしれません。 Timeout Negotiation for the Initial SYNC Transaction。最初の同期トランザクションのタイムアウトネゴシエーション

The initial SYNC request allows the timeout period for the Control Channel keep-alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request:


o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to active, the 'Keep-Alive' header MUST be included in the SYNC message generated by the offerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to 120 seconds (this is consistent with SIP Outbound [RFC5626]). The value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The client that generated the SDP "Answer" (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value.

SDPオファーを開始するクライアントはCOMEDIA「セットアップ」を有する場合、Oアクティブに等しい属性、「キープアライブ」ヘッダーは申出により生成されたSYNCメッセージに含まれなければなりません。 「キープアライブ」ヘッダの値(これはSIPアウトバウンドと一致している[RFC5626])95〜120秒の範囲であるべきです。 「キープアライブ」ヘッダーの値は600秒を超えてはなりません。 SDP「回答」(パッシブクライアント)を生成したクライアントが同じ値を持つSYNCメッセージ200応答に「キープアライブ」ヘッダをコピーする必要があります。

o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to passive, the 'Keep-Alive' header parameter MUST be included in the SYNC message generated by the answerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to

SDPオファーを開始するクライアントはCOMEDIA「セットアップ」は受動的に等しい属性を持っている場合、O、「キープアライブ」ヘッダーパラメータを回答することにより生成されたSYNCメッセージに含まれなければなりません。 「キープアライブ」ヘッダの値が95の範囲にあるべきです

120 seconds. The client that generated the SDP offer (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value.

120秒。 SDPオファーを生成したクライアント(パッシブ・クライアント)は同じ値を持つSYNCメッセージ200応答に「キープアライブ」ヘッダをコピーする必要があります。

o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to 'actpass', the 'Keep-Alive' header parameter MUST be included in the SYNC message of the entity who is the active participant in the SDP session. If the client generating the subsequent SDP answer places a value of 'active' in the COMEDIA SDP 'setup' attribute, it will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds. If the client generating the subsequent SDP answer places a value of 'passive' in the COMEDIA 'setup' attribute, the original UA making the SDP will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds.

SDPオファーを開始するクライアントはCOMEDIA「セットアップは」「actpass」に等しい属性を持っている場合は、O、「キープアライブ」ヘッダーパラメータをSDPセッションに積極的に参加して、エンティティのSYNCメッセージに含まれなければなりません。その後のSDP回答を生成し、クライアントがCOMEDIA SDP「セットアップ」属性で「アクティブ」の値を置く場合は、SYNC要求を生成し、「キープアライブ」ヘッダーが含まれます。値の範囲は95〜120秒であるべきです。その後のSDPアンサーを生成し、クライアントがCOMEDIA「セットアップ」属性の「パッシブ」の値を置く場合、元のUAは、SDPを作るSYNC要求を生成し、「キープアライブ」ヘッダーが含まれます。値の範囲は95〜120秒であるべきです。

o If the initial negotiated offer/answer results in a COMEDIA 'setup' attribute equal to 'holdconn', the initial SYNC mechanism will occur when the offer/answer exchange is updated and the active/passive roles are resolved using COMEDIA.


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.


Once negotiated, the keep-alive timeout applies for the remainder of the Control Framework session. Any subsequent SYNC messages generated in the Control Channel do not impact the negotiated keep-alive property of the session. The 'Keep-Alive' header MUST NOT be included in subsequent SYNC messages, and if it is received, it MUST be ignored.

交渉したら、キープアライブタイムアウトがコントロールフレームワークセッションの残りの部分に適用されます。制御チャネルで生成された任意の後続のSYNCメッセージは、セッションの交渉さキープアライブプロパティには影響しません。 「キープアライブ」ヘッダーは、後続のSYNCメッセージに含まれてはならないし、それを受信した場合、それを無視しなければなりません。 Package Negotiation。パッケージの交渉

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.


A server receiving the initial SYNC request MUST examine the contents of the 'Packages' header. If the server supports at least one of the packages listed in the request, it MUST respond with a 200 response code. The response MUST contain a 'Packages' header that lists the supported packages that are in common with those from the 'Packages' header of the request (either all or a subset). This list forms a common set of Control Packages that are supported by both parties. Any Control Packages supported by the server that are not listed in the 'Packages' header of the SYNC request MAY be placed in the 'Supported' header of the response. This provides a hint to the client that generated the SYNC request about additional packages supported by the server.

最初のSYNC要求を受けたサーバは、「パッケージ」ヘッダの内容を調べる必要があります。サーバは、要求にリストされたパッケージの少なくとも一つをサポートしている場合、それは200応答コードで応じなければなりません。応答は、要求(すべてまたはサブセットのいずれか)の「パッケージ」ヘッダからのものと共通しているサポートされているパッケージの一覧を示し「パッケージ」ヘッダを含まなければなりません。このリストは、両当事者によってサポートされている制御パッケージの共通セットを形成しています。 SYNC要求の「パッケージ」ヘッダに記載されていないサーバーでサポートされている任意のコントロールパッケージは、応答の「サポートされている」ヘッダーに配置することができます。これは、サーバーでサポートされている追加パッケージについてのSYNC要求を生成し、クライアントへのヒントを提供します。

If no common packages are supported by the server receiving the SYNC message, it MUST respond with a 422 error response code. The error response MUST contain a 'Supported' header indicating the packages that are supported. The initiating client can then choose to either re-submit a new SYNC message based on the 422 response or consider the interaction a failure. This would lead to termination of the associated SIP INVITE dialog by sending a SIP BYE request, as per [RFC3261].

共通パッケージはSYNCメッセージを受信するサーバによってサポートされていない場合は、422エラー応答コードで応じなければなりません。エラー応答がサポートされているパッケージを示す「サポート」ヘッダを含まなければなりません。開始クライアントは、その後、422応答に基づいて再提出する新しいSYNCメッセージのいずれかに選択するか、または相互作用の障害を検討することができます。これは[RFC3261]に従って、SIP BYE要求を送信することによって、ダイアログをINVITE SIP関連の終了につながります。

Once the initial SYNC transaction is completed, either client MAY choose to send a subsequent new SYNC message to re-negotiate the packages that are supported within the Control Channel. A new SYNC message whose 'Packages' header has different values from the previous SYNC message can effectively add and delete the packages used in the Control Channel. If a client receiving a subsequent SYNC message does not wish to change the set of packages, it MUST respond with a 421 Control Framework response code. Subsequent SYNC messages MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control Framework headers that appeared in the original SYNC negotiation.


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.


7. Response Code Descriptions

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.


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.


7.1. 200 Response Code
7.1. 200レスポンスコード

The framework protocol transaction completed successfully.


7.2. 202 Response Code
7.2. 202レスポンスコード

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.


7.3. 400 Response Code
7.3. 400レスポンスコード

The request was syntactically incorrect.


7.4. 403 Response Code
7.4. 403レスポンスコード

The server understood the request, but is refusing to fulfill it. The client SHOULD NOT repeat the request.


7.5. 405 Response Code
7.5. 405レスポンスコード

Method not allowed. The primitive is not supported.


7.6. 406 Response Code
7.6. 406レスポンスコード

Message out of sequence.


7.7. 420 Response Code
7.7. 420レスポンスコード

Intended target of the request is for a Control Package that is not valid for the current session.


7.8. 421 Response Code
7.8. 421レスポンスコード

Recipient does not wish to re-negotiate Control Packages at this moment in time.


7.9. 422 Response Code
7.9. 422レスポンスコード

Recipient does not support any Control Packages listed in the SYNC message.


7.10. 423 Response Code
7.10. 423レスポンスコード

Recipient has an existing transaction with the same transaction ID.


7.11. 481 Response Code
7.11. 481レスポンスコード

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ことを示しています。

7.12. 500 Response Code
7.12. 500レスポンスコード

The recipient does not understand the request.


8. Control Packages

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.


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.


8.1. Control Package Name
8.1. コントロールパッケージ名

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.


8.2. Framework Message Usage
8.2. フレームワークメッセージの使用

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.


8.3. Common XML Support
8.3. 一般的なXMLのサポート

This optional section is only included in a Control Package if the attributes for media dialog or conference reference are required, as defined and discussed in Appendix A.1. The Control Package will make strong statements (using language from RFC 2119 [RFC2119]) if the XML schema defined in Appendix A.1 is to be supported. If only part of the schema is required (for example, just 'connectionid' or 'conferenceid'), the Control Package will make equally strong statements (using language from RFC 2119 [RFC2119]).

メディア・ダイアログまたは会議参照の属性は、付録A.1で定義され、必要と説明されている場合は、このオプションの項では、唯一の制御パッケージに含まれています。制御パッケージは、付録A.1で定義されたXMLスキーマをサポートする場合には(2119 [RFC2119] RFCからの言語を使用して)強い声明を行います。スキーマの一部のみが(例えば、単に「connectionid」または「conferenceid」)必要な場合は、制御パッケージは、(RFC 2119からの言語を使用して、[RFC2119])同じように強い声明を行います。

8.4. CONTROL Message Bodies
8.4. CONTROLメッセージ本文

This mandatory section of a Control Package defines the control body that can be contained within a CONTROL command request, as defined in Section 6, or that no Control Package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type that apply to a CONTROL command request and, optionally, the associated 200 response. For Control Packages that do not have a Control Package body, making such a statement satisfies the "MUST" strength of this section in the Control Package document.

制御パッケージのこの必須のセクションは、セクション6で定義されるように、制御コマンド要求内に含まれることができる制御体を定義する、または全く制御パッケージ本体が必要とされません。このセクションでは、必要に応じて、制御コマンド要求に適用され、適切なMIME [RFC2045]体型、関連する200レスポンスの詳細な構文定義と意味論の位置を示さなければなりません。そのような文を作る制御パッケージ本体を持っていない制御パッケージの場合、コントロールパッケージの文書で、このセクションの「MUST」強度を満たします。

8.5. REPORT Message Bodies
8.5. REPORTメッセージ本文

This mandatory section of a Control Package defines the REPORT body that can be contained within a REPORT command request, as defined in Section 6, or that no report package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type. It should be noted that the Control Framework specification does allow for payloads to exist in 200 responses to CONTROL messages (as defined in this document). An entity that is prepared to receive a payload type in a REPORT message MUST also be prepared to receive the same payload in a 200 response to a CONTROL message. For Control Packages that do not have a Control Package body, stating such satisfies the "MUST" strength of this section in the Control Package document.

制御パッケージのこの必須のセクションは、セクション6で定義されるように、REPORTコマンド要求内に含まれることができるレポートの本体を定義し、又は全くレポートパッケージ本体が必要とされないこと。このセクションでは、適切なMIME [RFC2045]体型の詳細な構文定義と意味論の位置を示さなければなりません。ペイロードは(本書で定義された)メッセージを制御するために200の応答で存在するコントロールフレームワークの仕様が許可しないことに留意すべきです。 REPORTメッセージ内のペイロードタイプを受信するように調製されるエンティティは、制御メッセージ200応答して同一のペイロードを受信するように準備しなければなりません。こうした満足する制御パッケージ文書で、このセクションの「MUST」強さを述べ、制御パッケージ本体を持っていないコントロールパッケージの。

8.6. Audit
8.6. 監査

Auditing of various Control Package properties such as capabilities and resources (package-level meta-information) is extremely useful. Such meta-data usually has no direct impact on Control Framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information.


This section SHOULD include the following information:


o If an auditing capability is available in this package.


o How auditing information is triggered (for example, using a Control Framework CONTROL message) and delivered (for example, in a Control Framework 200 response).


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).


8.7. Examples
8.7. 例

It is strongly RECOMMENDED that Control Packages provide a range of message flows that represent common flows using the package and this framework document.


9. Formal Syntax
9.1. Control Framework Formal Syntax
9.1. コントロールフレームワークの正式な構文

The Control Framework interactions use the UTF-8 transformation format as defined in [RFC3629]. The syntax in this section uses the Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including types 'DIGIT', 'CRLF', and 'ALPHA'.


Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are not case-sensitive.


control-req-or-resp = control-request / control-response control-request = control-req-start *headers CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content] control-req-start = pCFW SP trans-id SP method CRLF control-resp-start = pCFW SP trans-id SP status-code CRLF

制御-REQ-OR-RESP =制御要求/制御応答制御要求=制御-REQ-開始*ヘッダーCRLF [制御内容】制御応答=制御-RESP-開始*ヘッダーCRLF [制御内容]コントロール-reqスタート= pCFW SPトランスのID SP方法CRLF制御-RESPスタート= pCFW SPトランス-ID SPステータスコードCRLF

pCFW = %x43.46.57; CFW in caps trans-id = alpha-num-token method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps mSYNC = %x53.59.4E.43 ; SYNC in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps

pCFW =%x43.46.57。キャップトランスID =アルファ - NUMトークン方法の他の方式mCONTROL =%のx43.4F.4E.54.52.4F.4C / = mCONTROL / mREPORT / MSYNC / MK-ALIVEでCFW。キャップでCONTROL mREPORT =%x52.45.50.4F.52.54。キャップでREPORT MSYNC =%x53.59.4E.43。キャップMK-ALIVE =%x4B.2D.41.4C.49.56.45でSYNC。 K-ALIVEキャップで

other-method = 1*UPALPHA status-code = 3*DIGIT ; any code defined in this and other documents headers = header-name CRLF

他の方式= 1 * UPALPHAステータスコード= 3 * DIGIT。このおよび他の文書のヘッダー=ヘッダ名CRLFで定義されたコード

header-name = (Content-Length /Content-Type /Control-Package /Status /Seq /Timeout /Dialog-ID /Packages /Supported /Keep-alive /ext-header)

ヘッダ名=(のContent-Length /コンテンツタイプ/コントロール・パッケージ/ステータス/配列/タイムアウト/ダイアログ-ID /パッケージ/サポート/キープアライブ/ EXT-ヘッダ)

Content-Length = "Content-Length:" SP 1*DIGIT Control-Package = "Control-Package:" SP 1*alpha-num-token Status = "Status:" SP ("update" / "terminate" ) Timeout = "Timeout:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT Dialog-ID = "Dialog-ID:" SP dialog-id-string Packages = "Packages:" SP package-name *(COMMA package-name) Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum) Keep-alive = "Keep-Alive:" SP kalive-seconds

Content-Length = "コンテンツ長:" SP 1 * DIGITコントロール・パッケージ= "コントロール・パッケージ:" SP 1 *アルファNUMトークンステータス= "ステータス:" SP( "更新" / "終了")タイムアウト= "タイムアウト:" SP 1 * DIGIT SEQ = "配列:" SP 1 * DIGITのダイアログ-ID = "ダイアログ-ID:" SPダイアログ-ID文字列パッケージ= "パッケージ:" SPパッケージ名*(COMMAパッケージ名)サポートされている= "サポートされている:" SPのsupprtd-alphanumの*(COMMAのsupprtd-alphanum)キープアライブ= "キープアライブ:" SPのkalive秒

dialog-id-string = alpha-num-token package-name = alpha-num-token supprtd-alphanum = alpha-num-token kalive-seconds = 1*DIGIT

ダイアログ-ID文字列= alphanumトークンパッケージ名= alphanumトークンsupprtd-alphanum = alphanumトークンkalive-秒= 1 * DIGIT

alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"

alphanumトークン= ALPHANUM 3 * 31 alphanum-トークンチャーalphanumトークン-チャー= ALPHANUM / "" / " - " / "+" / "%" / "=" / "/"

control-content = *OCTET

コントロール・コンテンツ= * OCTET

Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *(SP ";" gen-param ) type = token ; Section 4.2 of RFC 4288 subtype = token ; Section 4.2 of RFC 4288

Content-Typeの= "Content-Typeの" SPメディア型メディアタイプ=タイプ "/" サブタイプ*(SP ";" GEN-PARAM)=トークンタイプ。 RFC 4288サブタイプ=トークンのセクション4.2。 RFC 4288のセクション4.2

gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string

GEN-PARAM = pnameの[ "=" は、pval]のpname =トークンは、pval =トークン/引用符で囲まれた文字列

token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E)

トークン= 1 *(%X21 /%x23-27 /%X2A-2B /%x2D-2E /%x30-39 /%x41-5A /%x5E-7E)

quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH = "\" UPALPHA = %x41-5A ALPHANUM = ALPHA / DIGIT

引用符で囲んだ文字列= DQUOTE *(qdtext / QD-ESC)DQUOTE qdtext = SP / HTAB /%X21 /%x23-5B /%x5D-7E / UTF8-NONASCII QD-ESC =(バックスラッシュバックスラッシュ)/(バックスラッシュDQUOTE)BACKSLASH = "\" UPALPHA =%x41-5A ALPHANUM = ALPHA / DIGIT

ext-header = hname ":" SP hval CRLF

EXT-ヘッダ= hname ":" SP hval CRLF

hname = ALPHA *token hval = utf8text

hname = ALPHA *トークンhval = utf8text

utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)

UTF-8テキスト= *(TAB /%x20-7E / UTF-8 NON ASCII)

UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629

UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4。 RFC 3629から

The following table details a summary of the headers that can be contained in Control Framework interactions.


         Header field        Where    CONTROL REPORT SYNC  K-ALIVE
         Content-Length                  o      o      -      -
         Control-Package       R         m      -      -      -
         Seq                             -      m      -      -
         Status                R         -      m      -      -
         Timeout               R         -      m      -      -
         Timeout              202        -      m      -      -
         Dialog-ID             R         -      -      m      -
         Packages                        -      -      m      -
         Supported             r         -      -      o      -
         Keep-Alive            R         -      -      o      -
         Content-Type                    o      o      -      -

Table 1: Summary of Headers in Control Framework Interactions


The notation used in Table 1 is as follows:


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:ヘッダーフィールドはオプションです。 - :ヘッダーフィールドは適用されない(存在する場合は無視)。

9.2. Control Framework Dialog Identifier SDP Attribute
9.2. コントロールフレームワークダイアログ識別子SDP属性

This specification defines a new media-level value attribute: 'cfw-id'. Its formatting in SDP is described by the following ABNF [RFC5234].

「CFW-ID」:この仕様では、新しいメディア・レベルの値の属性を定義します。 SDPでの書式は以下のABNF [RFC5234]に記載されています。

cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF

CFW-ダイアログ-ID = "A = CFW-ID:" 1 *(SP CFW-ID-名)CRLF

cfw-id-name = token


token = 1*(token-char)

トークン= 1 *(トークンチャー)

token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E

トークンチャー=%X21 /%x23-27 /%X2A-2B /%x2D-2E /%x30-39 /%x41-5A /%x5E-7E

The token-char and token elements are defined in [RFC4566] but included here to provide support for the implementer of this SDP feature.


10. Examples

The following examples provide an abstracted flow of Control Channel establishment and Control Framework message exchange. The SIP signaling is prefixed with the token 'SIP'. All other messages are Control Framework interactions defined in this document.

以下の実施例は、抽象化された制御チャネル確立の流れとコントロールフレームワークのメッセージ交換を提供します。 SIPシグナリングはトークン「SIP」が付いています。他のすべてのメッセージは、この文書で定義されたコントロールフレームワークの相互作用です。

In this example, the Control Client establishes a Control Channel, SYNCs with the Control Server, and issues a CONTROL request that can't be completed within the 'Transaction-Timeout', so the Control Server returns a 202 response code to extend the transaction. The Control Server then follows with REPORTs until the requested action has been completed. The SIP INVITE dialog is then terminated.

この例では、コントロールクライアントは、制御チャネル、コントロールサーバと同期を確立し、制御サーバは、トランザクションを拡張するために202応答コードを返しますので、「トランザクション・タイムアウト」内に完了することができないCONTROL要求を発行します。要求されたアクションが完了するまで制御サーバは、報告と続きます。 SIP INVITEダイアログを終了します。

            Control Client                                Control Server
                   |                                             |
                   |       (1) SIP INVITE                        |
                   |  ---------------------------------------->  |
                   |                                             |
                   |       (2) SIP 200                           |
                   |  <---------------------------------------   |
                   |                                             |
                   |       (3) SIP ACK                           |
                   |  ---------------------------------------->  |
                   |                                             |
                   |         Control Channel Established         |
                   |                                             |
                   |       (4) SYNC                              |
                   |  ---------------------------------------->  |
                   |                                             |
                   |       (5) 200                               |
                   |  <---------------------------------------   |
                   |                                             |
                   |       (6) CONTROL                           |
                   |  ---------------------------------------->  |
                   |                                             |

(1) Control Client-->Control Server (SIP): INVITE

(1)コントロールクライアント - >コントロールサーバ(SIP):SIP

INVITE SIP/2.0 To: <> From: <>;tag=8937498 Via: SIP/2.0/UDP;branch=z9hG4bK123 CSeq: 1 INVITE Max-Forwards: 70 Call-ID: Contact: <> Content-Type: application/sdp Content-Length: 206

SIP / 2.0 / UDP:; SIP / 2.0に:<>から:タグ= 8937498経由:<SIP> SIPのINVITE;ブランチ= z9hG4bK123のCSeq:1 INVITEマックス・フォワード:70のCall-ID:893jhoeihjr8392@example.com連絡先:<>のContent-Type:アプリケーション/ SDPコンテンツ-length:206

v=0 o=originator 2890844526 2890842808 IN IP4 s=- c=IN IP4 m=application 49153 TCP cfw a=setup:active a=connection:new a=cfw-id:fndskuhHKsd783hjdla (2) Control Server-->Control Client (SIP): 200 OK

アクティブA =接続:新A = CFW-ID C = IN IP4 M =アプリケーション49153 TCPのCFWのA =セットアップ - IP4 S = IN V = 0 0 =発信2890844526 2890842808 :fndskuhHKsd783hjdla(2)制御サーバ - >コントロールクライアント(SIP):200 OK

SIP/2.0 200 OK To: <>;tag=023983774 From: <>;tag=8937498 Via: SIP/2.0/UDP;branch=z9hG4bK123;received= CSeq: 1 INVITE Call-ID: Contact: <> Content-Type: application/sdp Content-Length: 203

SIP / 2.0 200 OKに:<>;タグ= 023983774から:<>;タグ= 8937498経由:SIP / 2.0 / UDP client.example。 COM;ブランチ= z9hG4bK123;受け取ら=のCSeq:1 INVITEコールIDを:893jhoeihjr8392@example.com連絡先:<>のContent-Type:アプリケーション/ SDPコンテンツの長さ: 203

v=0 o=responder 2890844600 2890842900 IN IP4 s=- c=IN IP4 m=application 49153 TCP cfw a=setup:passive a=connection:new a=cfw-id:7JeDi23i7eiysi32

V = 0 0 =レスポンダ2890844600 2890842900 IN IP4 S = - C = IN IP4 M =アプリケーション49153 TCPのCFWのA =セットアップ:受動A =接続:新しいA = CFW-ID :7JeDi23i7eiysi32

(3) Control Client-->Control Server (SIP): ACK

(3)コントロールクライアント - >コントロールサーバ(SIP):ACK

(4) Control Client opens a TCP connection to the Control Server. The connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): SYNC.

(4)コントロールクライアントは、管理サーバーへのTCP接続を開きます。接続は現在、コントロールフレームワークのメッセージを交換するために使用することができます。コントロールクライアント - >コントロールサーバー(コントロールフレームワークのメッセージ):SYNC。

CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0

CFW 8djae7khauj SYNCダイアログ-ID:fndskuhHKsd783hjdlaは、キープアライブ:100のパッケージ:MSC-IVR-基本/ 1.0

(5) Control Server-->Control Client (Control Framework message): 200.

(5)制御サーバ - >コントロールクライアント(コントロールフレームワークのメッセージ):200。

CFW 8djae7khauj 200 Keep-Alive: 100 Packages: msc-ivr-basic/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0

CFWは8djae7khauj 200キープアライブ:100のパッケージ:MSC-IVR-基本/ 1.0サポート:MSC-IVR-VXML / 1.0、MSC-confのオーディオ/ 1.0

(6) Once the SYNC process has completed, the connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): CONTROL.

同期プロセスが完了すると(6)、接続は現在コントロールフレームワークメッセージを交換するために使用することができます。コントロールクライアント - >コントロールサーバー(コントロールフレームワークのメッセージ):CONTROL。

CFW i387yeiqyiq CONTROL Control-Package: <package-name> Content-Type: example_content/example_content

CFW CONTROLコントロール・パッケージをi387yeiqyiq:<パッケージ名>のContent-Type:example_content / example_content

Content-Length: 11




(7) Control Server-->Control Client (Control Framework message): 202.

(7)制御サーバ - >クライアントの制御(コントロールフレームワークのメッセージ):202。

CFW i387yeiqyiq 202 Timeout: 10


(8) Control Server-->Control Client (Control Framework message): REPORT.

(8)制御サーバ - >コントロールクライアント(コントロールフレームワークのメッセージ):REPORT。

CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10

REPORT配列i387yeiqyiq CFW:1状態:更新タイムアウト:10

(9) Control Client-->Control Server (Control Framework message): 200.

(9)コントロールクライアント - >コントロールサーバー(コントロールフレームワークメッセージ):200。

CFW i387yeiqyiq 200 Seq: 1


(10) Control Server-->Control Client (Control Framework message): REPORT.

(10)コントロール・サーバー - >コントロールクライアント(コントロールフレームワークのメッセージ):REPORT。

CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11

CFWは、REPORT配列をi387yeiqyiq:2つの状態:更新タイムアウト:10のContent-Type:example_content / example_contentのContent-Length:11



(11) Control Client-->Control Server (Control Framework message): 200.

(11)コントロールクライアント - >コントロールサーバー(コントロールフレームワークメッセージ):200。

CFW i387yeiqyiq 200 Seq: 2


(12) Control Server-->Control Client (Control Framework message): REPORT.

(12)コントロール・サーバー - >コントロールクライアント(コントロールフレームワークのメッセージ):REPORT。

CFW i387yeiqyiq REPORT Seq: 3 Status: terminate

REPORT配列i387yeiqyiq CFW:3つのステータス:終了

Timeout: 10 Content-Type: example_content/example_content Content-Length: 11

タイムアウト:10のContent-Type:example_content / example_contentのContent-Length:11



(13) Control Client-->Control Server (Control Framework message): 200.

(13)コントロールクライアント - >コントロールサーバー(コントロールフレームワークメッセージ):200。

CFW i387yeiqyiq 200 Seq: 3


(14) Control Client-->Control Server (SIP): BYE

(14)コントロールクライアント - >コントロールサーバ(SIP):BYE

BYE SIP/2.0 To: <>;tag=023983774 From: <>;tag=8937498 Via: SIP/2.0/UDP;branch=z9hG4bK234 CSeq: 2 BYE Max-Forwards: 70 Call-ID: Contact: <> Content-Length: 0

BYEを SIP / 2.0 <>;タグ= 023983774から<>;タグ= 8937498のVia:SIP /2.0/UDP;ブランチ= z9hG4bK234のCSeq:2 BYEマックス - フォワード:70のCall-ID:893jhoeihjr8392@example.com連絡先:<>のContent-Length: 0

(15) Control Server-->Control Client (SIP): 200 OK

(15)コントロール・サーバー - >コントロールクライアント(SIP):200 OK

SIP/2.0 200 OK To: <>;tag=023983774 From: <>;tag=8937498 Via: SIP/2.0/UDP;branch=z9hG4bK234;received= CSeq: 2 BYE Call-ID: Contact: <> Content-Length: 0

SIP / 2.0 200 OKに:<>;タグ= 023983774から:<>;タグ= 8937498経由:SIP / 2.0 / UDP。 2 BYEコール-ID:893jhoeihjr8392@example.com連絡先:<>のContent-Length:0;枝= z9hG4bK234は=のCSeqを受け

11. Extensibility

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.


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.


12. Security Considerations

The Channel Framework provides confidentiality and integrity for the messages it transfers. It also provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked, as discussed in the remainder of this section.


In design, the Channel Framework complies with the security-related requirements documented in "Media Server Control Protocol Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12, REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by the Channel Framework are summarized in the following sub-sections.

より具体的には、REQ-MCP-11、REQ-MCP-12、REQ-MCP-13、およびREQ - デザインでは、チャネルのフレームワークは、 "メディアサーバー制御プロトコルの要件" に記載のセキュリティ関連の要件[RFC5167]に準拠しています-MCP-14。チャンネルフレームワークによって用いられる特定のセキュリティ対策は、以下のサブセクションにまとめられています。

12.1. Session Establishment
12.1. セッションの確立

Channel Framework sessions are established as media sessions described by SDP within the context of a SIP INVITE dialog. In order to ensure secure rendezvous between Control Framework clients and servers, the Media Channel Control Framework should make full use of mechanisms provided by SIP. The use of the 'cfw-id' SDP attribute results in important session information being carried across the SIP network. For this reason, SIP clients using this specification MUST use appropriate security mechanisms, such as TLS [RFC5246] and SMIME [RFC5751], when deployed in open networks.

チャネルFrameworkのセッションは、SIP INVITEダイアログのコンテキスト内でSDPによって記述されるメディアセッションとして確立されています。コントロールフレームワークのクライアントとサーバー間の安全なランデブーを確保するために、メディアチャンネルコントロールフレームワークは、SIPによって提供されるメカニズムをフルに活用する必要があります。 「CFW-ID」SDPの使用は、SIPネットワークを介して行われている重要なセッション情報で結果を属性。この理由のために、この仕様を使用してSIPクライアントは、TLS [RFC5246]及びオープンネットワークに配備SMIME [RFC5751]などの適切なセキュリティメカニズムを使用しなければなりません。

12.2. Transport-Level Protection
12.2. トランスポート・レベルの保護

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.


Sensitive data, such as private and financial data, is carried over the Control Framework channel. Clients and servers must be properly authenticated/authorized and the Control Channel must permit the use of confidentiality, replay protection, and integrity protection for the data. To ensure Control Channel protection, Control Framework clients and servers MUST support TLS and SHOULD use it by default unless alternative Control Channel protection is used or a protected environment is guaranteed by the administrator of the network. Alternative Control Channel protection MAY be used if desired (e.g., IPsec [RFC5246]).


TLS is used to authenticate devices and to provide integrity, replay protection, and confidentiality for the header fields being transported on the Control Channel. Channel Framework elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261] MUST be supported. Other cipher-suites MAY also be supported.

TLSは、デバイスを認証し、制御チャネル上で搬送されているヘッダフィールドのための完全性、再生保護、および機密性を提供するために使用されます。チャネルフレームワークエレメントは、TLSを実装しなければならないし、また、[RFC5246]に記載されているようにTLS ClientExtendedHelloサーバー名表示のhello拡張情報を実装しなければなりません。 TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261]のTLS暗号スイートをサポートしなければなりません。他の暗号スイートもサポートされるかもしれません。

When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922 [RFC5922].

TLSクライアントがサーバーとの接続を確立するときに、それはサーバのX.509証明書を提示しています。認証進むRFC 5922 [RFC5922]のセクション7.3(「クライアントの動作」)に記載されているように。

A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922 [RFC5922].

この仕様に準拠TLSサーバは、クライアント証明書を要求しなければなりません。クライアントが証明書を持っている場合は、RFC 5922 [RFC5922]のセクション7.4(「サーバービヘイビア」)で説明したように、それは、相互認証のためにサーバーに提示され、認証が進行されます。

12.3. Control Channel Policy Management
12.3. 制御チャネルポリシー管理

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.


It can be determined that access to resources and use of Control Channels relate to policy. It can be considered implementation and deployment detail that dictates the level of policy that is adopted. The authorization and associated policy of a Control Channel can be linked to the authentication mechanisms described in this section. For example, strictly authenticating a Control Channel using TLS authentication allows entities to protect resources and ensure the required level of granularity. Such policy can be applied at the package level or even as low as a structure like a conference instance (Control Channel X is not permitted to issue commands for Control Package y OR Control Channel A is not permitted to issue commands for conference instance B). Systems should ensure that, if required, an appropriate policy framework is adopted to satisfy the requirements for implemented packages. The most robust form of policy can be achieved using a strong authentication mechanism such as mutual TLS authentication on the Control Channel. This specification provides a Control Channel response code (403) to indicate to the issuer of a command that it is not permitted. The 403 response MUST be issued to Control Framework requests that are not permitted under the implemented policy. If a 403 response is received, a Control Framework client MAY choose to re-submit the request with differing requirements or to abandon the request. The 403 response does not provide any additional information on the policy failure due to the generic nature of this specification. Individual Control Packages can supply additional information if required. The mechanism for providing such additional information is not mandated in this specification. It should be noted that additional policy requirements to those covered in this section might be defined and applied in individual packages that specify a finer granularity for access to resources, etc.

制御チャネルのリソースと使用へのアクセスは、ポリシーに関連していると判断することができます。それが採用されているポリシーのレベルを決定実装および展開詳細と考えることができます。制御チャネルの許可と関連するポリシーは、このセクションで説明する認証機構に連結することができます。例えば、厳密TLS認証を使用して制御チャネルは、エンティティが資源を保護し、必要な粒度レベルを確保することができます認証。そのようなポリシーは、パッケージレベルで適用されるか、会議インスタンスのような構造としても限り低くすることができる(制御チャネルXコントロールパッケージYまたは制御チャネルAは、会議インスタンスBのためのコマンドを発行することが許可されていないためのコマンドを発行することが許可されていません)。システムは、必要に応じて、適切なポリシーフレームワークが実装パッケージの要件を満たすために採用されている、ことを確実にすべきです。政策の最も堅牢な形態は、制御チャネル上の相互TLS認証などの強力な認証メカニズムを使用して達成することができます。この仕様は、それが許可されていないコマンドの発行者に示すために、制御チャネルの応答コード(403)を提供します。 403応答が実装ポリシーで許可されていないフレームワークの要求を制御するために発行する必要があります。 403応答が受信されている場合は、コントロールフレームワークのクライアントは、異なる要件に要求を再提出するか、要求を放棄することを選択するかもしれません。 403応答は、本明細書の一般的な性質のために政策の失敗についての追加情報を提供していません。必要に応じて個々の制御パッケージには、追加情報を提供することができます。このような追加情報を提供するためのメカニズムはこの仕様で義務付けられていません。このセクションで説明したものに、追加のポリシー要件は、リソースへのアクセスのためのより細かい粒度を指定し、個々のパッケージなどで定義され、適用される可能性があることに留意すべきです

13. IANA Considerations
13. IANAの考慮事項

IANA has created a new registry for SIP Control Framework parameters. The "Media Control Channel Framework Parameters" registry is a container for sub-registries. This section further introduces sub-registries for control packages, method names, status codes, header field names, and port and transport protocol.

IANAは、SIPコントロールフレームワークのパラメータのための新しいレジストリを作成しました。 「メディア制御チャネルフレームワークのパラメータ」レジストリは、サブレジストリのコンテナです。このセクションでは、さらに、制御パッケージ、メソッド名、ステータスコード、ヘッダフィールド名、ポートおよびトランスポートプロトコルのサブレジストリを導入します。

Additionally, Section 13.6 registers a new MIME type for use with SDP.


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.


13.1. Control Packages Registration Information
13.1. 制御パッケージの登録情報

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".


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.


The table below lists the Control Packages defined in the "Media Control Channel Framework".


    Package Name      Reference
    ------------      ---------
    example1          [RFCXXXX]
13.1.1. Control Package Registration Template
13.1.1. 制御パッケージの登録テンプレート

Package Name:


          (Package names must conform to the syntax described in
          Section 8.1.)

Published Specification(s):


(Control Packages require an RFC.)


Person & email address to contact for further information:


13.2. Control Framework Method Names
13.2. コントロールフレームワークメソッド名

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).


CONTROL - [RFC6230] REPORT - [RFC6230] SYNC - [RFC6230] K-ALIVE - [RFC6230]

CONTROL - [RFC 6230] REPORT - [RFC 6230] SYNC - [RFC 6230] K-ALIVE - [RFC 6230]

The following information MUST be provided in an RFC in order to register a new Control Framework method:


o The method name.


o The RFC number in which the method is registered.


13.3. Control Framework Status Codes
13.3. コントロールフレームワークのステータスコード

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:


Code Description Reference


The following information MUST be provided in an RFC in order to register a new Control Framework status code:


o The status code number.


o The RFC number in which the method is registered.


o A brief description of the status code.


13.4. Control Framework Header Fields
13.4. コントロールフレームワークヘッダフィールド

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:


Control-Package - [RFC6230] Status - [RFC6230] Seq - [RFC6230] Timeout - [RFC6230] Dialog-ID - [RFC6230] Packages - [RFC6230] Supported - [RFC6230] Keep-Alive - [RFC6230] Content-Type - [RFC6230] Content-Length - [RFC6230]

コントロール - パッケージ - [RFC6230]ステータス - [RFC6230]配列 - [RFC6230]タイムアウト - [RFC6230]ダイアログ-ID - [RFC6230]パッケージ - [RFC6230]サポートされている - [RFC6230]キープアライブ - [RFC6230]のContent-Type - [RFC6230]のContent-Length - [RFC6230]

The following information MUST be provided in an RFC in order to register a new Channel Framework header field:


o The header field name.


o The RFC number in which the method is registered.


13.5. Control Framework Port
13.5. コントロールフレームワークポート

The Control Framework uses TCP port 7563, from the "registered" port range. Usage of this value is described in Section 4.1.


13.6. Media Type Registrations
13.6. メディアタイプ登録

This section describes the media types and names associated with payload formats used by the Control Framework. The registration uses the templates defined in [RFC4288]. It follows [RFC4855].


13.6.1. Registration of MIME Media Type application/cfw
13.6.1. MIMEメディアタイプアプリケーション/ CFWの登録

Type name: application


Subtype name: cfw


Required parameters: None


Optional parameters: None


Encoding considerations: Binary and see Section 4 of RFC 6230

エンコードの考慮事項:RFC 6230のバイナリおよび参照第4節

Security considerations: See Section 12 of RFC 6230

セキュリティの考慮事項:RFC 6230のセクション12を参照してください。

Interoperability considerations: Endpoints compliant to this specification must use this MIME type. Receivers who cannot support this specification will reject using appropriate protocol mechanism.


Published specification: RFC 6230

公開された仕様:RFC 6230

Applications that use this media type: Applications compliant with Media Control Channels.


Additional Information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none)


Person & email address to contact for further information: Chris Boulton <>


Intended usage: COMMON


Restrictions on usage: Should be used only in conjunction with this specification, RFC 6230.

使用に関する制限事項:これだけの仕様、RFC 6230と組み合わせて使用​​する必要があり。

Author: Chris Boulton


Change controller: IETF MEDIACTRL working group, delegated from the IESG.

変更コントローラ:IETF MEDIACTRLワーキンググループ、IESGから委任。

13.6.2. Registration of MIME Media Type application/ framework-attributes+xml

13.6.2. MIMEメディアタイプアプリケーション/フレームワークの属性+ XMLの登録

Type name: application


Subtype name: framework-attributes+xml

サブタイプ名:フレームワークの属性+ xmlの

Required parameters: (none)


Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].

オプションのパラメータ:アプリケーション/ XMLのcharsetパラメータと同じRFC 3023 [RFC3023]で指定されています。

Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].

符号化の考慮事項:RFC 3023で指定されたアプリケーション/ XMLの考察をコードするものと同じ[RFC3023]。

Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework.


Interoperability considerations: This content type provides common constructs for related Media Control Channel packages.


Published specification: RFC 6230

公開された仕様:RFC 6230

Applications that use this media type: Implementations of appropriate Media Control Channel packages.


Additional information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none)


Person & email address to contact for further information: Chris Boulton <>


Intended usage: LIMITED USE


Author/Change controller: The IETF


Other information: None.


13.7. 'cfw-id' SDP Attribute
13.7. 'CFW-ID' SDP属性

Contact name: Chris Boulton <>


Attribute name: "cfw-id".


Type of attribute Media level.


Subject to charset: Not.


Purpose of attribute: The 'cfw-id' attribute indicates an identifier that can be used to correlate the Control Channel with the SIP INVITE dialog used to negotiate it, when the attribute value is used within the Control Channel.

属性の目的:「CFW-ID」属性の属性値を制御チャネル内で使用される場合、それを交渉するために使用されるダイアログのINVITE SIPで制御チャネルを相関させるために使用することができる識別子を示します。

Allowed attribute values: A token.


13.8. URN Sub-Namespace for urn:ietf:params:xml:ns:control:framework-attributes

13.8. 骨壷のためのURNサブ名前空間:IETF:のparams:XML:NS:コントロール:フレームワークの属性

IANA has registered a new XML namespace, "urn:ietf:params:xml:ns:control:framework-attributes", per the guidelines in RFC 3688 [RFC3688].

RFC 3688 [RFC3688]のガイドラインごとに、 "フレームワーク - 属性:IETF:のparams:XML:NS:コントロール骨壷" IANAは、新しいXML名前空間を登録しています。

URI: urn:ietf:params:xml:ns:control:framework-attributes


Registrant Contact: IETF MEDIACTRL working group <>, Chris Boulton <>.

登録者連絡先:IETF MEDIACTRLワーキンググループ<>、クリスボールトン<>。



BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ""> <html xmlns="" 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=""> RFC 6230</a>.</p> </body> </html> END

BEGINの<?xml version = "1.0"?> <!DOCTYPE htmlのをPUBLIC! " - // W3C // DTD XHTML 1.0厳格// EN"「 strict.dtd "> <HTMLのxmlns ="」XML:LANG = "EN"> <HEAD> <TITLE>メディア制御チャネルは、</ TITLE> </ HEAD属性> <身体> <H1>メディア制御チャネルのための名前空間の属性</ H1> <H2> URN:IETF:のparams:XML:NS:コントロール:フレームワークの属性</ H2> <P>を参照してください。<HREF = "のhttp:/ / "> RFC 6230 </a>にします。</ p> </ body> </ html>このEND

13.9. XML Schema Registration
13.9. XML Schemaの登録

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 <>, Chris Boulton <>.

登録者連絡先:IETF MEDIACTRLワーキンググループ<>、クリスボールトン<>。

Schema: The XML for this schema can be found in Appendix A.1 of this document.


14. Contributors

Asher Shiratzky from Radvision provided valuable support and contributions to the early versions of this document.


15. Acknowledgments

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.


Expert review was also provided by Spencer Dawkins, Krishna Prasad Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided expert guidance on the dialog association mechanism. Lorenzo Miniero has constantly provided excellent feedback based on his work.

専門家のレビューはまたしてもスペンサードーキンスクリシュナプラサドKalluri、ロレンツォMiniero、およびロニによって提供されました。 Hadrielカプランは、ダイアログの関連機構に専門家の指導を提供します。ロレンツォMinieroは常に彼の作品に基づいた優れたフィードバックを提供してきました。

Ben Campbell carried out the RAI expert review on this document and provided a great deal of invaluable input. Brian Weis carried out a thorough security review. Jonathan Lennox carried out a thorough SDP review that provided some excellent modifications. Text from Eric Burger was used in the introduction in the explanation for using SIP.


16. References
16.1. Normative References
16.1. 引用規格

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション(MIME)第一部:インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.

[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル(SIP)における暫定的な応答の信頼性"。

[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル(SIP):SIPサーバの検索"、RFC 3263、2002年6月。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル(SDP)とのオファー/アンサーモデル"。

[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.

[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル(SIP)更新方法"、RFC 3311、2002年10月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.

[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル(SDP)にメディアトランスポート"、RFC 4145、2005年9月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.

[RFC4574]レヴィン、O.およびG.キャマリロ、 "セッション記述プロトコル(SDP)label属性"、RFC 4574、2006年8月。

[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.

[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF:ABNF"、STD 68、RFC 5234、2008年1月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(TLS)プロトコルバージョン1.2"、RFC 5246、2008年8月。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[RFC5751] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張(S / MIME)バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。

[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.

[RFC5922] Gurbani、V.、ローレンス、S.、およびA.ジェフリー、 "セッション開始プロトコル(SIP)にドメイン証明書"、RFC 5922、2010年6月。

16.2. Informative References
16.2. 参考文献

[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.

[MSCL-THOUGHTS]バーガー、E.、 "メディアサーバ制御言語とプロトコル思考"、進歩、2006年6月での作業。

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.

[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル(SIP)における第三者呼制御(3PCC)のベスト・プラクティスの現在" 、2004年4月。

[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.

[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル(SIP)におけるユーザエージェントの能力を示します"。

[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.

[RFC3841]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル(SIP)のための発信者が設定"、RFC 3841、2004年8月。

[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.

[RFC5125]テイラー、T.、 "歴史的にRFC 3525の再分類"、RFC 5125、2008年2月。

[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.

[RFC5167]ドリー、M.とR.でも、 "メディアサーバー制御プロトコルの要件"、RFC 5167、2008年3月。

[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.

[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル(SIP)におけるクライアント開始された接続の管理"。

Appendix A. Common Package Components


During the creation of the Control Framework, it has become clear that there are a number of components that are common across multiple packages. It has become apparent that it would be useful to collect such reusable components in a central location. In the short term, this appendix provides the placeholder for the utilities, and it is the intention that this section will eventually form the basis of an initial 'Utilities Document' that can be used by Control Packages.


A.1. Common Dialog/Multiparty Reference Schema


The following schema provides some common attributes for allowing Control Packages to apply specific commands to a particular SIP media dialog (also referred to as "Connection") or conference. If used within a Control Package, the Connection and multiparty attributes will be imported and used appropriately to specifically identify either a SIP dialog or a conference instance. If used within a package, the value contained in the 'connectionid' attribute MUST be constructed by concatenating the 'Local' and 'Remote' SIP dialog identifier tags as defined in [RFC3261]. They MUST then be separated using the ':' character. So the format would be:

次のスキーマは、制御パッケージは、特定のSIPメディアダイアログ(また、「接続」とも呼ばれる)や会議に特定のコマンドを適用することを可能にするためのいくつかの共通の属性を提供します。制御パッケージ内で使用される場合は、接続とのマルチパーティの属性がインポートされ、特にSIPダイアログや会議のインスタンスのいずれかを識別するために適切に使用されます。パッケージ内で使用される場合、「connectionid」属性に含まれる値は、[RFC3261]で定義されるように「ローカル」と「リモート」SIPダイアログ識別子タグを連結することによって構築されなければなりません。 「:」文字次に、これらを用いて分離されなければなりません。だから、フォーマットは次のようになります。

'Local Dialog tag' + ':' + 'Remote Dialog tag'


As an example, for an entity that has a SIP Local dialog identifier of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 'connectionid' attribute for a Control Framework command would be:




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.


As with the Connection attribute previously defined, it is useful to have the ability to apply specific Control Framework commands to a number of related dialogs, such as a multiparty call. This typically consists of a number of media dialogs that are logically bound by a single identifier. The following schema allows for Control Framework commands to explicitly reference such a grouping through a 'conferenceid' XML container. If used by a Control Package, any control XML referenced by the attribute applies to all related media dialogs. Unlike the dialog attribute, the 'conferenceid' attribute does not need to be constructed based on the overlying SIP dialog. The 'conferenceid' attribute value is system specific and should be selected with relevant context and uniqueness.

以前に定義された属性の接続と同様に、そのようなマルチパーティコールなどの特定のコントロールフレームワークは、関連するダイアログの数にコマンドを適用する機能があると便利です。これは、一般的に、論理的に単一の識別子により拘束されているメディア・ダイアログの数で構成されています。コントロールフレームワークは、明示的に「conferenceid」XML容器を通してそのようなグルーピングを参照するためにコマンドの次のスキーマを可能にします。制御パッケージで使用される場合は、属性によって参照される制御XMLは、関連するすべてのメディア・ダイアログに適用されます。ダイアログ属性とは異なり、「conferenceid」属性は、その上のSIPダイアログに基づいて構成されている必要はありません。 「conferenceid」属性値は、システム固有のものであり、関連するコンテキストとユニークさを選択する必要があります。

It should be noted that the values contained in both the 'connectionid' and 'conferenceid' identifiers MUST be compared in a case-sensitive manner.

connectionid 'と「conferenceid」識別子の両方に含まれる値は、大文字と小文字が区別方法で比較しなければならないことに留意すべきです。

The full schema follows:


<?xml version="1.0" encoding="UTF-8"?>

<?xml version = "1.0" エンコード= "UTF-8"?>

<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:xsd="" xmlns="urn:ietf:params:xml:ns::control:framework-attributes" elementFormDefault="qualified" attributeFormDefault="unqualified">

<XSD:スキーマのtargetNamespace = "URN:IETF:paramsは:XML:NS:コントロール:フレームワーク属性" のxmlns:のxsd = "" のxmlnsは=「URN:IETF:paramsは:XML:NS ::コントロール:フレームワークの属性」のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>

        <xsd:attributeGroup name="framework-attributes">
              SIP Connection and Conf Identifiers

<xsd:attribute name="connectionid" type="xsd:string"/>

<XSD:属性名= "connectionid" タイプ= "のxsd:文字列" />

<xsd:attribute name="conferenceid" type="xsd:string"/>

<XSD:属性名= "conferenceid" タイプ= "のxsd:文字列" />

</xsd:attributeGroup> </xsd:schema>

</ XSD:attributeGroupの> </ XSD:スキーマ>

Authors' Addresses


Chris Boulton NS-Technologies




Tim Melanchuk Rainwillow

ティムMelanchuk Rainwillow



Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden

スコットMcGlashanヒューレット・パッカードグスタフIII大通り36 SE-16985ストックホルム、スウェーデン