Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6230 NS-Technologies
Category: Standards Track T. Melanchuk
ISSN: 2070-1721 Rainwillow
S. McGlashan
Hewlett-Packard
May 2011
Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6230 NS-Technologies
Category: Standards Track T. Melanchuk
ISSN: 2070-1721 Rainwillow
S. McGlashan
Hewlett-Packard
May 2011
Media Control Channel Framework
媒体控制通道框架
Abstract
摘要
This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.
本文档描述了应用程序部署的框架和协议，其中分布了应用程序编程逻辑和媒体处理。这意味着应用程序编程逻辑可以无缝地访问不在同一物理网络实体上的适当资源。该框架使用会话启动协议（SIP）在应用程序服务器和相关的外部服务器（如媒体服务器）之间建立应用程序级控制机制。
The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope.
创建此框架的动机是提供一个适合于满足集中式会议系统要求的接口，根据IETF中XCON工作组的定义，会议系统可以分布在集中式会议系统中。但是，它不限于此范围。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6230.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6230.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
12.3. Control Channel Policy Management . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. Control Packages Registration Information . . . . . . . . 38
13.1.1. Control Package Registration Template . . . . . . . . 39
13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
13.4. Control Framework Header Fields . . . . . . . . . . . . . 40
13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
13.6.1. Registration of MIME Media Type application/cfw . . . 41
13.6.2. Registration of MIME Media Type
application/framework-attributes+xml . . . . . . . . . 42
13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 43
13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 43
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Common Package Components . . . . . . . . . . . . . . 47
A.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 47
Real-time media applications are often developed using an architecture where the application logic and media processing activities are distributed. Commonly, the application logic runs on "application servers", but the processing runs on external servers, such as "media servers". This document focuses on the framework and protocol between the application server and external processing server. The motivation for this framework comes from a set of requirements for Media Server Control, which can be found in "Media Server Control Protocol Requirements" [RFC5167]. While the Framework is not specific to media server control, it is the primary driver and use case for this work. It is intended that the framework contained in this document be able to be used for a variety of device control scenarios (for example, conference control).
实时媒体应用程序通常使用分布式应用程序逻辑和媒体处理活动的体系结构进行开发。通常，应用程序逻辑在“应用程序服务器”上运行，但处理在外部服务器（如“媒体服务器”）上运行。本文档重点介绍应用服务器和外部处理服务器之间的框架和协议。此框架的动机来自一系列媒体服务器控制要求，可在“媒体服务器控制协议要求”[RFC5167]中找到。虽然该框架并不特定于媒体服务器控制，但它是这项工作的主要驱动程序和用例。本文档中包含的框架旨在能够用于各种设备控制场景（例如，会议控制）。
This document does not define a particular SIP extension for the direct control of external components. Rather, other documents, known as "Control Packages", extend the Control Framework described by this document. Section 8 provides a comprehensive set of guidelines for creating such Control Packages.
本文档未定义用于直接控制外部组件的特定SIP扩展。相反，其他文件（称为“控制包”）扩展了本文件所述的控制框架。第8节为创建此类控制包提供了一套全面的指南。
Current IETF device control protocols, such as Megaco [RFC5125], while excellent for controlling media gateways that bridge separate networks, are troublesome for supporting media-rich applications in SIP networks. This is because Megaco duplicates many of the functions inherent in SIP. Rather than using a single protocol for session establishment and application media processing, application developers need to translate between two separate mechanisms. Moreover, the model provided by the framework presented here, using SIP, better matches the application programming model than does Megaco.
当前的IETF设备控制协议，如Megaco[RFC5125]，虽然在控制桥接独立网络的媒体网关方面非常出色，但在支持SIP网络中的媒体丰富应用方面却很麻烦。这是因为Megaco复制了SIP中固有的许多功能。应用程序开发人员需要在两种不同的机制之间进行转换，而不是使用单一的协议来建立会话和处理应用程序媒体。此外，本文介绍的框架提供的模型使用SIP，比Megaco更符合应用程序编程模型。
SIP [RFC3261] provides the ideal rendezvous mechanism for establishing and maintaining control connections to external server components. The control connections can then be used to exchange explicit command/response interactions that allow for media control and associated command response results.
SIP[RFC3261]为建立和维护与外部服务器组件的控制连接提供了理想的会合机制。然后，控制连接可用于交换显式命令/响应交互，从而允许媒体控制和相关命令响应结果。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的描述进行解释，并适用于这些合规性目标。
The following additional terms are defined for use in this document:
本文件中定义了以下附加术语：
User Agent Client (UAC): As specified in [RFC3261].
用户代理客户端（UAC）：如[RFC3261]所述。
User Agent Server (UAS): As specified in [RFC3261].
用户代理服务器（UAS）：如[RFC3261]中所述。
B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
B2BUA:B2BUA是一个背对背的SIP用户代理。
Control Server: A Control Server is an entity that performs a service, such as media processing, on behalf of a Control Client. For example, a media server offers mixing, announcement, tone detection and generation, and play and record services. The Control Server has a direct Real-Time Transport Protocol (RTP) [RFC3550] relationship with the source or sink of the media flow. In this document, we often refer to the Control Server simply as "the Server".
控制服务器：控制服务器是代表控制客户端执行服务（如媒体处理）的实体。例如，媒体服务器提供混音、广播、音调检测和生成以及播放和录制服务。控制服务器与媒体流的源或汇具有直接实时传输协议（RTP）[RFC3550]关系。在本文档中，我们通常将控制服务器简称为“服务器”。
Control Client: A Control Client is an entity that requests processing from a Control Server. Note that the Control Client might not have any processing capabilities whatsoever. For example, the Control Client may be an application server (B2BUA) or other endpoint requesting manipulation of a third party's media stream that terminates on a media server acting in the role of a Control Server. In this document, we often refer to the Control Client simply as "the Client".
控制客户端：控制客户端是从控制服务器请求处理的实体。请注意，控制客户端可能没有任何处理能力。例如，控制客户端可以是应用服务器（B2BUA）或请求操纵第三方媒体流的其他端点，该第三方媒体流终止于充当控制服务器角色的媒体服务器。在本文档中，我们通常将控制客户端简称为“客户端”。
Control Channel: A Control Channel is a reliable connection between a Client and Server that is used to exchange Framework messages. The term "Connection" is used synonymously within this document.
控制通道：控制通道是用于交换框架消息的客户端和服务器之间的可靠连接。术语“连接”在本文件中同义使用。
Framework Message: A Framework message is a message on a Control Channel that has a type corresponding to one of the Methods defined in this document. A Framework message is often referred to by its method, such as a "CONTROL message".
框架消息：框架消息是控制通道上的消息，其类型与本文档中定义的方法之一相对应。框架消息通常由其方法引用，例如“控制消息”。
Method: A Method is the type of a Framework message. Four Methods are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
方法：方法是框架消息的类型。本文档中定义了四种方法：同步、控制、报告和K-ALIVE。
Control Command: A Control Command is an application-level request from a Client to a Server. Control Commands are carried in the body of CONTROL messages. Control Commands are defined in separate specifications known as "Control Packages".
控制命令：控制命令是从客户端到服务器的应用程序级请求。控制命令包含在控制消息体中。控制命令在称为“控制包”的单独规范中定义。
Framework Transaction: A Framework Transaction is defined as a sequence composed of a Control Framework message originated by either a Control Client or Control Server and responded to with a Control Framework response code message. Note that the Control Framework has no "provisional" responses. A Control Framework
框架事务：框架事务定义为由控制客户端或控制服务器发起的控制框架消息组成的序列，并使用控制框架响应代码消息进行响应。请注意，控制框架没有“临时”响应。控制框架
transaction is referenced throughout the document as a 'Transaction-Timeout'.
在整个文档中，事务被引用为“事务超时”。
Transaction-Timeout: The maximum allowed time between a Control Client or Server issuing a Framework message and it arriving at the destination. The value for 'Transaction-Timeout' is 10 seconds.
事务超时：控制客户端或服务器发出框架消息到到达目标之间允许的最长时间。“事务超时”的值为10秒。
This document details mechanisms for establishing, using, and terminating a reliable transport connection channel using SIP and the Session Description Protocol offer/answer [RFC3264] exchange. The established connection is then used for controlling an external server. The following text provides a non-normative overview of the mechanisms used. Detailed, normative guidelines are provided later in the document.
本文档详细介绍了使用SIP和会话描述协议提供/应答[RFC3264]交换建立、使用和终止可靠传输连接通道的机制。然后，建立的连接用于控制外部服务器。下文提供了所用机制的非规范性概述。本文件后面将提供详细的规范性指南。
Control Channels are negotiated using standard SIP mechanisms that would be used in a similar manner to creating a SIP multimedia session. Figure 1 illustrates a simplified view of the mechanism. It highlights a separation of the SIP signaling traffic and the associated Control Channel that is established as a result of the SIP interactions.
使用标准SIP机制协商控制信道，该机制将以与创建SIP多媒体会话类似的方式使用。图1显示了该机制的简化视图。它强调了SIP信令业务和作为SIP交互的结果而建立的相关控制信道的分离。
Initial analysis into the Control Framework, as documented in [MSCL-THOUGHTS], established the following. One might ask, "If all we are doing is establishing a TCP connection to control the media server, why do we need SIP?" This is a reasonable question. The key is that we use SIP for media session establishment. If we are using SIP for media session establishment, then we need to ensure the URI used for session establishment resolves to the same node as the node for session control. Using the SIP routing mechanism, and having the server initiate the TCP connection back, ensures this works. For example, the URI sip:myserver.example.com may resolve to sip: server21.farm12.northeast.example.net, whereas the URI http://myserver.example.com may resolve to http://server41.httpfarm.central.example.net. That is, the host part is not necessarily unambiguous.
如[MSCL-Thinks]所述，对控制框架的初步分析确定了以下内容。有人可能会问，“如果我们所做的只是建立一个TCP连接来控制媒体服务器，为什么我们需要SIP？”这是一个合理的问题。关键是我们使用SIP建立媒体会话。如果我们使用SIP建立媒体会话，那么我们需要确保用于会话建立的URI解析为与会话控制节点相同的节点。使用SIP路由机制，并让服务器重新启动TCP连接，确保了这一点。例如，URI sip:myserver.example.com可能解析为sip:server21.farm12.northeast.example.net，而URIhttp://myserver.example.com 可以决定http://server41.httpfarm.central.example.net. 也就是说，主体部分不一定是明确的。
The use of SIP to negotiate the Control Channel provides many inherent capabilities, which include:
使用SIP协商控制通道提供了许多固有功能，包括：
o Service location - Use SIP Proxies and Back-to-Back User Agents for locating Control Servers.
o 服务位置-使用SIP代理和背靠背用户代理来定位控制服务器。
o Security mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication.
o 安全机制-利用已建立的安全机制，如传输层安全（TLS）和客户端身份验证。
o Connection maintenance - The ability to re-negotiate a connection, ensure it is active, and so forth.
o 连接维护—重新协商连接、确保连接处于活动状态等的能力。
o Application agnostic - Generic protocol allows for easy extension.
o 应用程序无关-通用协议允许轻松扩展。
As mentioned in the previous list, one of the main benefits of using SIP as the session control protocol is the "Service Location" facilities provided. This applies both at a routing level, where [RFC3263] provides the physical location of devices, and at the service level, using Caller Preferences [RFC3840] and Callee Capabilities [RFC3841]. The ability to select a Control Server based on service-level capabilities is extremely powerful when considering a distributed, clustered architecture containing varying services (for example, voice, video, IM). More detail on locating Control Server resources using these techniques is outlined in Section 4.1 of this document.
如前所述，使用SIP作为会话控制协议的主要好处之一是提供了“服务位置”设施。这既适用于[RFC3263]提供设备物理位置的路由级别，也适用于使用呼叫者首选项[RFC3840]和被呼叫者功能[RFC3841]的服务级别。在考虑包含各种服务（例如，语音、视频、IM）的分布式集群体系结构时，基于服务级别功能选择控制服务器的能力非常强大。有关使用这些技术定位控制服务器资源的更多详细信息，请参见本文档的第4.1节。
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
图1：基本架构
The example from Figure 1 conveys a 1:1 connection between the Control Client and the Control Server. It is possible, if required, for the client to request multiple Control Channels using separate SIP INVITE dialogs between the Control Client and the Control Server entities. Any of the connections created between the two entities can then be used for Server control interactions. The control connections are orthogonal to any given media session. Specific media session information is incorporated in control interaction commands, which themselves are defined in external packages, using the XML schema defined in Appendix A. The ability to have multiple Control Channels allows for stronger redundancy and the ability to manage high volumes of traffic in busy systems.
图1中的示例表示控制客户端和控制服务器之间的1:1连接。如果需要，客户端可以使用控制客户端和控制服务器实体之间的单独SIP INVITE对话框请求多个控制通道。然后，两个实体之间创建的任何连接都可以用于服务器控制交互。控制连接与任何给定的媒体会话正交。特定的媒体会话信息包含在控制交互命令中，这些命令本身在外部软件包中定义，使用附录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.
客户端构造标准SIP INVITE请求并将其发送到外部服务器，如[RFC3261]中所定义。会话描述协议（SDP）有效负载包括控制信道协商所需的信息，是传递对本规范支持的主要机制。本文档中定义了application/cfw MIME类型，以传达符合本规范的适当SDP格式。用于建立和维护可靠连接的面向连接的媒体（COMEDIA）[RFC4145]规范用作协商机制的一部分（更多详细信息将在后面的章节中提供）。客户端还包括本规范中定义的“cfw id”SDP属性，该属性是一个唯一标识符，用于将底层媒体控制通道与提供/应答交换关联起来。
Client Sends to External Server:
客户端发送到外部服务器：
INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
Call-ID: 7823987HJHG6
Max-Forwards: 70
CSeq: 1 INVITE
Contact: <sip:Client@clientmachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
Call-ID: 7823987HJHG6
Max-Forwards: 70
CSeq: 1 INVITE
Contact: <sip:Client@clientmachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example.com
s=-
c=IN IP4 controller.example.com
m=application 49153 TCP cfw
a=setup:active
a=connection:new
a=cfw-id:H839quwhjdhegvdga
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example.com
s=-
c=IN IP4 controller.example.com
m=application 49153 TCP cfw
a=setup:active
a=connection:new
a=cfw-id:H839quwhjdhegvdga
On receiving the INVITE request, an external Server supporting this mechanism generates a 200 OK response containing appropriate SDP and formatted using the application/cfw MIME type specified in this document. The Server inserts its own unique 'cfw-id' SDP attribute, which differs from the one received in the INVITE (offer).
收到INVITE请求后，支持此机制的外部服务器将生成一个200 OK响应，其中包含适当的SDP，并使用本文档中指定的application/cfw MIME类型进行格式化。服务器插入自己独特的“cfw id”SDP属性，该属性不同于在邀请（报价）中收到的属性。
External Server Sends to Client:
外部服务器发送到客户端：
SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4
SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0
o=responder 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:U8dh7UHDushsdu32uha
v=0
o=responder 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:U8dh7UHDushsdu32uha
The Control Client receives the SIP 200 OK response and extracts the relevant information (also sending a SIP ACK). It creates an outgoing (as specified by the SDP 'setup' attribute of 'active') TCP connection to the Control Server. The connection address (taken from 'c=') and port (taken from 'm=') are used to identify the remote port in the new connection.
控制客户端接收SIP 200 OK响应并提取相关信息（还发送SIP ACK）。它创建一个到控制服务器的传出（由“活动”的SDP“设置”属性指定）TCP连接。连接地址（取自“c=”）和端口（取自“m=”）用于标识新连接中的远程端口。
Once established, the newly created connection can be used to exchange requests and responses as defined in this document. If required, after the Control Channel has been set up, media sessions can be established using standard SIP Third Party Call Control (3PCC) [RFC3725].
一旦建立，新创建的连接可用于交换本文档中定义的请求和响应。如果需要，在设置控制信道后，可以使用标准SIP第三方呼叫控制（3PCC）[RFC3725]建立媒体会话。
Figure 2 provides a simplified example where the framework is used to control a User Agent's RTP session.
图2提供了一个简化的示例，其中框架用于控制用户代理的RTP会话。
+--------Control SIP Dialog(1)---------+
| |
v v
+-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack|
| +---+-----+---+ +---+-----+---+
| | | | |
| | Control |<--Control Channel(1)-->| |
| | Client | | Control |
| +-------------+ | Server |
+--+--+ | |
|User | | |
|Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+
+--------Control SIP Dialog(1)---------+
| |
v v
+-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack|
| +---+-----+---+ +---+-----+---+
| | | | |
| | Control |<--Control Channel(1)-->| |
| | Client | | Control |
| +-------------+ | Server |
+--+--+ | |
|User | | |
|Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+
Figure 2: Participant Architecture
图2：参与者架构
The link (1) represents the SIP INVITE dialog usage and dedicated Control Channel previously described in this overview section. The link (2) from Figure 2 represents the User Agent SIP INVITE dialog usage interactions and associated media flow. A User Agent creates a SIP INVITE dialog usage with the Control Client entity. The Control Client entity then creates a SIP INVITE dialog usage to the Control Server, using B2BUA type functionality. Using the interaction illustrated by (2), the Control Client negotiates media capabilities with the Control Server, on behalf of the User Agent, using SIP 3PCC. [RFC3725].
链接（1）表示SIP INVITE对话框的使用情况和前面在本概述部分中描述的专用控制通道。图2中的链接（2）表示用户代理SIP INVITE对话框使用交互和相关媒体流。用户代理使用控制客户端实体创建SIP INVITE对话框。然后，控制客户端实体使用B2BUA类型的功能为控制服务器创建SIP INVITE对话框用法。使用（2）所示的交互，控制客户端代表用户代理使用SIP 3PCC与控制服务器协商媒体功能。[RFC3725]。
This section describes the setup, using SIP, of the dedicated Control Channel. Once the Control Channel has been established, commands can be exchanged (as discussed in Section 6).
本节介绍使用SIP设置专用控制通道。一旦建立了控制通道，就可以交换命令（如第6节所述）。
When a UAC wishes to establish a Control Channel, it MUST construct and transmit a new SIP INVITE request for Control Channel setup. The UAC MUST construct the INVITE request as defined in [RFC3261].
当UAC希望建立控制信道时，它必须构造并传输一个新的SIP INVITE请求，以进行控制信道设置。UAC必须按照[RFC3261]中的定义构造INVITE请求。
If a reliable response is received (as defined in [RFC3261] and [RFC3262]), the mechanisms defined in this document are applicable to the newly created SIP INVITE dialog usage.
如果收到可靠的响应（如[RFC3261]和[RFC3262]中所定义），则本文档中定义的机制适用于新创建的SIP INVITE对话用法。
The UAC SHOULD include a valid session description (an 'offer' as defined in [RFC3264]) in an INVITE request using the Session Description Protocol defined in [RFC4566] but MAY choose an offer-less INVITE as per [RFC3261]. The SDP SHOULD be formatted in accordance with the steps below and using the MIME type application/ cfw, which is registered in Section 13. The following information defines the composition of specific elements of the SDP payload the offerer MUST adhere to when used in a SIP-based offer/answer exchange using SDP and the application/cfw MIME type. The SDP being constructed MUST contain only a single occurrence of a Control Channel definition outlined in this specification but can contain other media lines if required.
UAC应使用[RFC4566]中定义的会话描述协议在INVITE请求中包含有效的会话描述（如[RFC3264]中定义的“要约”），但可以根据[RFC3261]选择无要约的INVITE。SDP应按照以下步骤进行格式化，并使用MIME类型应用程序/cfw，该应用程序在第13节中注册。以下信息定义了在使用SDP和应用程序/cfw MIME类型进行基于SIP的提供/应答交换时，报价人必须遵守的SDP有效负载的特定元素的组成。正在构造的SDP必须仅包含本规范中概述的控制通道定义的一次引用，但如果需要，可以包含其他媒体线。
The Connection Data line in the SDP payload is constructed as specified in [RFC4566]:
SDP有效负载中的连接数据线按照[RFC4566]中的规定构造：
c=<nettype> <addrtype> <connection-address>
c=<nettype> <addrtype> <connection-address>
The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The
third sub-field for Connection Data is <connection-address>. This
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.
提供SDP发起者地址的表示，例如DNS/IP表示。地址是用于连接的地址。
Example:
例子：
c=IN IP4 controller.example.com
c=在IP4 controller.example.com中
The SDP MUST contain a corresponding Media Description entry:
SDP必须包含相应的媒体描述条目：
m=<media> <port> <proto> <fmt>
m=<media> <port> <proto> <fmt>
The first "sub-field", <media>, MUST equal the value "application". The second sub-field, <port>, MUST represent a port on which the constructing client can receive an incoming connection if required. The port is used in combination with the address specified in the Connection Data line defined previously to supply connection details. If the entity constructing the SDP can't receive incoming connections, it must still enter a valid port entry. The use of the port value '0' has the same meaning as defined in a SIP offer/answer exchange [RFC3264]. The Control Framework has a default port defined in Section 13.5. This value is default, although a client is free to choose explicit port numbers. However, SDP SHOULD use the default port number, unless local policy prohibits its use. Using the default port number allows network administrators to manage firewall policy for Control Framework interactions. The third sub-field, <proto>, compliant to this specification, MUST support the values "TCP" and "TCP/TLS". Implementations MUST support TLS as a transport-level security mechanism for the Control Channel, although use of TLS in specific deployments is optional. Control Framework implementations MUST support TCP as a transport protocol. When an entity identifies a transport value but is not willing to establish the session, it MUST respond using the appropriate SIP mechanism. The <fmt> sub-field MUST contain the value "cfw".
第一个“子字段”<media>，必须等于值“application”。第二个子字段，<port>，必须表示一个端口，如果需要，构造客户端可以在该端口上接收传入连接。端口与先前定义的连接数据线中指定的地址结合使用，以提供连接详细信息。如果构建SDP的实体无法接收传入连接，则它仍必须输入有效的端口条目。端口值“0”的使用与SIP提供/应答交换[RFC3264]中定义的含义相同。控制框架具有第13.5节中定义的默认端口。此值是默认值，但客户端可以自由选择显式端口号。但是，SDP应使用默认端口号，除非本地策略禁止使用。使用默认端口号允许网络管理员管理控制框架交互的防火墙策略。符合本规范的第三个子字段<proto>，必须支持值“TCP”和“TCP/TLS”。实现必须支持TLS作为控制通道的传输级安全机制，尽管在特定部署中使用TLS是可选的。控制框架实现必须支持TCP作为传输协议。当实体识别传输值但不愿意建立会话时，它必须使用适当的SIP机制进行响应。<fmt>子字段必须包含值“cfw”。
The SDP MUST also contain a number of SDP media attributes (a=) that are specifically defined in the COMEDIA [RFC4145] specification. The attributes provide connection negotiation and maintenance parameters. It is RECOMMENDED that a Controlling UAC initiate a connection to an external Server but that an external Server MAY negotiate and initiate a connection using COMEDIA, if network topology prohibits initiating connections in a certain direction. An example of the COMEDIA attributes is:
SDP还必须包含COMEDIA[RFC4145]规范中专门定义的许多SDP媒体属性（a=）。这些属性提供连接协商和维护参数。建议控制UAC启动到外部服务器的连接，但如果网络拓扑禁止启动特定方向的连接，则外部服务器可以使用COMEDIA协商并启动连接。喜剧属性的一个例子是：
a=setup:active
a=connection:new
a=setup:active
a=connection:new
This example demonstrates a new connection that will be initiated from the owner of the SDP payload. The connection details are contained in the SDP answer received from the UAS. A full example of an SDP payload compliant to this specification can be viewed in Section 3. Once the SDP has been constructed along with the remainder of the SIP INVITE request (as defined in [RFC3261]), it can be sent to the appropriate location. The SIP INVITE dialog usage and appropriate control connection is then established.
此示例演示将从SDP有效负载的所有者启动的新连接。连接详细信息包含在从UAS收到的SDP应答中。符合本规范的SDP有效载荷的完整示例见第3节。一旦SDP与SIP INVITE请求的其余部分（如[RFC3261]中所定义）一起构建，就可以将其发送到适当的位置。然后建立SIP INVITE对话框使用和适当的控制连接。
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. The 'cfw-id' attribute indicates an identifier that can be used within the Control Channel to correlate the Control Channel with this SIP INVITE dialog usage. The 'cfw-id' attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/answer exchanges. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange. This applies specifically to the 'connection' attribute as defined in [RFC4145]. If a SIP UAC wants to change some other parts of the SDP but reuse the already established connection, it uses the value of 'existing' in the 'connection' attribute (for example, a=connection:existing). If it has noted that a connection has failed and wants to re-establish the connection, it uses the value of 'new' in the 'connection' attribute (for example, a=connection:new). Throughout this, the connection identifier specified in the 'cfw-id' SDP parameter MUST NOT change. One is simply negotiating the underlying TCP connection between endpoints but always using the same Control Framework session, which is 1:1 for the lifetime of the SIP INVITE dialog usage.
构建报价的SIP UAC必须包括第9.2节中定义的“cfw id”SDP属性。“cfw id”属性表示可在控制通道内使用的标识符，以将控制通道与此SIP INVITE对话框使用关联。“cfw id”属性在UAC和UAS之间的交互上下文中必须是唯一的，并且不得与其他SIP提供/应答交换中使用的“cfw id”实例冲突。为“cfw id”属性选择的值必须在相关SIP INVITE对话框使用的整个持续时间内使用，并且在提供/应答交换的更新过程中不得更改。这特别适用于[RFC4145]中定义的“连接”属性。如果SIP UAC希望更改SDP的某些其他部分，但重用已建立的连接，它将在“连接”属性中使用“现有”的值（例如，a=connection:existing）。如果它注意到某个连接失败并希望重新建立该连接，它将在“connection”属性中使用“new”值（例如，a=connection:new）。在此过程中，“cfw id”SDP参数中指定的连接标识符不得更改。一种是简单地协商端点之间的底层TCP连接，但始终使用相同的控制框架会话，这在SIP INVITE对话使用的生命周期中是1:1。
A non-2xx-class final SIP response (3xx, 4xx, 5xx, and 6xx) received for the INVITE request indicates that no SIP INVITE dialog usage has been created and is treated as specified by SIP [RFC3261]. Specifically, support of this specification is negotiated through the presence of the media type defined in this specification. The receipt of a SIP error response such as "488" indicates that the offer contained in a request is not acceptable. The inclusion of the media line associated with this specification in such a rejected offer indicates to the client generating the offer that this could be due to the receiving client not supporting this specification. The client generating the offer MUST act as it would normally on receiving this response, as per [RFC3261]. Media streams can also be rejected by setting the port to "0" in the "m=" line of the session description, as defined in [RFC3264]. A client using this specification MUST be prepared to receive an answer where the "m=" line it inserted for using the Control Framework has been set to "0".
为INVITE请求接收到的非2xx类最终SIP响应（3xx、4xx、5xx和6xx）表明尚未创建SIP INVITE对话框使用，并按照SIP[RFC3261]的规定进行处理。具体而言，通过存在本规范中定义的媒体类型来协商对本规范的支持。收到SIP错误响应（如“488”）表示请求中包含的报价不可接受。在这样一个被拒绝的报价中包含与本规范相关联的媒体线路，向生成报价的客户表明这可能是由于接收客户不支持本规范。根据[RFC3261]，生成报价的客户必须在收到此响应时正常行事。还可以通过在会话描述的“m=”行中将端口设置为“0”（如[RFC3264]中所定义）来拒绝媒体流。使用本规范的客户机必须准备好在为使用控制框架而插入的“m=”行已设置为“0”时接收答案。
In this situation, the client will act as it would for any other media type with a port set to "0".
在这种情况下，客户端将与端口设置为“0”的任何其他媒体类型一样工作。
On receiving a SIP INVITE request, an external Server (SIP UAS) inspects the message for indications of support for the mechanisms defined in this specification. This is achieved through inspection of the session description of the offer message and identifying support for the application/cfw MIME type in the SDP. If the SIP UAS wishes to construct a reliable response that conveys support for the extension, it MUST follow the mechanisms defined in [RFC3261]. If support is conveyed in a reliable SIP provisional response, the mechanisms in [RFC3262] MUST also be used. It should be noted that the SDP offer is not restricted to the initial INVITE request and MAY appear in any series of messages that are compliant to [RFC3261], [RFC3262], [RFC3311], and [RFC3264].
在接收到SIP INVITE请求时，外部服务器（SIP UAS）会检查消息是否支持本规范中定义的机制。这是通过检查offer消息的会话描述并确定对SDP中application/cfw MIME类型的支持来实现的。如果SIP UAS希望构建一个可靠的响应来传递对扩展的支持，则必须遵循[RFC3261]中定义的机制。如果在可靠的SIP临时响应中传达支持，则还必须使用[RFC3262]中的机制。应注意，SDP报价不限于初始邀请请求，并且可能出现在符合[RFC3261]、[RFC3262]、[RFC3311]和[RFC3264]的任何消息系列中。
When constructing an answer, the SDP payload MUST be constructed using the semantic (connection, media, and attribute) defined in Section 4.1 using valid local settings and also with full compliance to the COMEDIA [RFC4145] specification. For example, the SDP attributes included in the answer constructed for the example offer provided in Section 4.1 would look as follows:
在构建答案时，必须使用第4.1节中定义的语义（连接、媒体和属性），使用有效的本地设置，并完全符合COMEDIA[RFC4145]规范，来构建SDP有效负载。例如，为第4.1节中提供的示例报价构建的答案中包含的SDP属性如下所示：
a=setup:passive
a=connection:new
a=setup:passive
a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP attribute as defined in Section 9.2. This attribute MUST be unique in the context of the interaction between the UAC and UAS and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/ answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id' value received in the offer as it is used to uniquely identify and distinguish between multiple endpoints that generate SDP answers. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP INVITE dialog usage and not be changed during updates to the offer/answer exchange.
构建应答的客户端必须包含第9.2节中定义的“cfw id”SDP属性。此属性在UAC和UAS之间的交互环境中必须是唯一的，并且不得与其他SIP提供/应答交换中使用的“cfw id”实例冲突。“cfw id”必须与报价中收到的“cfw id”值不同，因为它用于唯一标识和区分生成SDP答案的多个端点。为“cfw id”属性选择的值必须在相关SIP INVITE对话框使用的整个持续时间内使用，并且在提供/应答交换的更新过程中不得更改。
Once the SDP answer has been constructed, it is sent using standard SIP mechanisms. Depending on the contents of the SDP payloads that were negotiated using the offer/answer exchange, a reliable connection will be established between the Controlling UAC and External Server UAS entities. The newly established connection is now available to exchange Control Command primitives. The state of the SIP INVITE dialog usage and the associated Control Channel are now implicitly linked. If either party wishes to terminate a Control Channel, it simply issues a SIP termination request (for example, a
构建SDP应答后，将使用标准SIP机制发送该应答。根据使用要约/应答交换协商的SDP有效载荷的内容，将在控制UAC和外部服务器UAS实体之间建立可靠连接。新建立的连接现在可用于exchange控制命令原语。SIP INVITE对话框使用状态和关联的控制通道现在隐式链接。如果任何一方希望终止一个控制通道，它只需发出一个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.
接收SIP选项请求的UAS必须按照[RFC3261]中的定义做出适当响应。UAS必须在SIP“Accept”头中包含SIP 200 OK响应中支持的媒体类型，以指示有效的媒体类型。
It is intended that the Control Framework will be used within a variety of architectures for a wide range of functions. One of the primary functions will be the use of the Control Channel to apply multiple specific Control Package commands to media sessions established by SIP INVITE dialogs (media dialogs) with a given remote server. For example, the Control Server might send a command to generate audio media (such as an announcement) on an RTP stream between a User Agent and a media server.
控制框架将在各种体系结构中用于广泛的功能。主要功能之一是使用控制通道将多个特定控制包命令应用于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对话框（见图2）可能包含多个媒体描述（如SDP中的“m=”所定义）。对于要定向到使用控制框架的实体的每个“m=”定义，控制客户端必须包括[RFC4574]中定义的媒体标签属性。这允许控制客户端稍后在控制通道上的特定媒体线路（m=）上显式地引导命令。
This framework identifies the referencing of such associated media dialogs as extremely important. A connection reference attribute has been specified that can optionally be imported into any Control Package. It is intended that this will reduce the repetitive specifying of dialog reference language. The schema can be found in Appendix A.1.
该框架将此类相关媒体对话框的引用确定为极其重要的。已指定连接引用属性，该属性可以选择性地导入到任何控制包中。这样做的目的是减少对话框引用语言的重复指定。该模式可在附录A.1中找到。
Similarly, the ability to identify and apply commands to a group of associated media dialogs (multiparty) is also identified as a common structure that could be defined and reused, for example, playing a prompt to all participants in a Conference. The schema for such operations can also be found in Appendix A.1.
类似地，识别并将命令应用于一组相关媒体对话框（多方）的能力也被识别为可以定义和重用的公共结构，例如，向会议中的所有参与者播放提示。此类操作的模式也可在附录A.1中找到。
Support for both the common attributes described here is specified as part of each Control Package definition, as detailed in Section 8.
如第8节所述，对此处描述的两个公共属性的支持都指定为每个控制包定义的一部分。
In this document, the use of the COMEDIA specification allows for a Control Channel to be set up in either direction as a result of a SIP INVITE transaction. SIP provides a flexible negotiation mechanism to establish the Control Channel, but there needs to be a mechanism within the Control Channel to correlate it with the SIP INVITE dialog usage implemented for its establishment. A Control Client receiving an incoming connection (whether it be acting in the role of UAC or UAS) has no way of identifying the associated SIP INVITE dialog usage as it could be simply listening for all incoming connections on a specific port. The following steps, which implementations MUST support, allow a connecting UA (that is, the UA with the active role in COMEDIA) to identify the associated SIP INVITE dialog usage that triggered the connection. Unless there is an alternative dialog association mechanism used, the UAs MUST carry out these steps before any other signaling on the newly created Control Channel.
在本文档中，COMEDIA规范的使用允许作为SIP INVITE事务的结果在任意方向上设置控制通道。SIP提供了一种灵活的协商机制来建立控制通道，但控制通道中需要有一种机制来将其与为建立控制通道而实现的SIP INVITE对话使用相关联。接收传入连接的控制客户端（无论它是扮演UAC还是UAS角色）无法识别关联的SIP INVITE对话用法，因为它可能只是侦听特定端口上的所有传入连接。实现必须支持的以下步骤允许连接UA（即在COMEDIA中扮演活动角色的UA）识别触发连接的相关SIP INVITE对话框使用情况。除非使用了替代的对话关联机制，否则UAs必须在新创建的控制信道上发送任何其他信号之前执行这些步骤。
o Once the connection has been established, the UA acting in the active role (active UA) to initiate the connection MUST send a Control Framework SYNC request. The SYNC request MUST be constructed as defined in Section 9.1 and MUST contain the 'Dialog-ID' message header.
o 建立连接后，以活动角色（活动UA）启动连接的UA必须发送控制框架同步请求。同步请求必须按照第9.1节中的定义构造，并且必须包含“对话ID”消息头。
o The 'Dialog-ID' message header is populated with the value of the local 'cfw-id' media-level attribute that was inserted by the same client in the SDP offer/answer exchange to establish the Control Channel. This allows for a correlation between the Control Channel and its associated SIP INVITE dialog usage.
o “对话ID”消息头由本地“cfw ID”媒体级属性的值填充，该属性由同一客户端插入SDP提供/应答交换以建立控制通道。这允许控制通道与其关联的SIP INVITE对话使用之间存在关联。
o On creating the SYNC request, the active UA MUST follow the procedures outlined in Section 6.3.3. This provides details of connection keep-alive messages.
o 创建同步请求时，活动UA必须遵循第6.3.3节中概述的程序。这提供了连接保持活动消息的详细信息。
o On creating the SYNC request, the active UA MUST also follow the procedures outlined in Section 6.3.4.2. This provides details of the negotiation mechanism used to determine the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection.
o 在创建同步请求时，活动UA还必须遵循第6.3.4.2节中概述的程序。这提供了用于确定可在已建立的控制通道连接上交换的协议数据单元（PDU）的协商机制的详细信息。
o The UA in the active role for the connection creation MUST then send the SYNC request. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a 2xx-class SIP response, it MUST wait for an incoming SIP ACK message before issuing the SYNC. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a reliable 1XX class SIP response, it MUST wait for an incoming SIP PRACK message before issuing the SYNC.
o 然后，处于连接创建活动角色的UA必须发送同步请求。如果用于创建连接的活动角色中的UA是SIP UAS，并且已在2xx类SIP响应中生成其SDP响应，则在发出同步之前，它必须等待传入的SIP ACK消息。如果连接创建的活动角色中的UA是SIP UAS，并且已在可靠的1XX类SIP响应中生成其SDP响应，则必须等待传入的SIP 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，则它必须在建立控制通道时立即发送同步消息。然后，它必须等待至少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.
o 如果没有收到同步消息的响应，则会发生超时，控制通道将随着相关的SIP INVITE对话框使用情况一起终止。活动UA必须发出BYE请求以终止SIP INVITE对话框的使用。
o If the active UA receives a 481 response from the passive UA, this means the SYNC request was received, but the associated SIP INVITE dialog usage specified in the SYNC message does not exist. The active client MUST terminate the Control Channel. The active UA MUST issue a SIP BYE request to terminate the SIP INVITE dialog usage.
o 如果主动UA收到来自被动UA的481响应，这意味着已收到同步请求，但同步消息中指定的相关SIP INVITE对话用法不存在。活动客户端必须终止控制通道。活动UA必须发出SIP BYE请求以终止SIP INVITE对话框的使用。
o All other error responses received for the SYNC request are treated as detailed in this specification and also result in the termination of the Control Channel and the associated SIP INVITE dialog usage. The active UA MUST issue a BYE request to terminate the SIP INVITE dialog usage.
o 为同步请求接收的所有其他错误响应将按照本规范中的详细说明进行处理，并且还会导致控制通道和相关SIP INVITE对话使用的终止。活动UA必须发出BYE请求以终止SIP INVITE对话框的使用。
o The receipt of a 200 response to a SYNC message implies that the SIP INVITE dialog usage and control connection have been successfully correlated. The Control Channel can now be used for further interactions.
o 接收到对同步消息的200响应意味着SIP 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.
一旦初始交换完成，当控制通道从任何一方打开时，可以在任何一点发送同步消息。如果存在，“保持活动”和“对话框ID”标题的内容不得更改。“保持活动”和“对话ID”标题的新值没有相关性，因为它们是在媒体控制通道框架会话的生命周期内协商的。
Once a successful Control Channel has been established, as defined in Sections 4.1 and 4.2, and the connection has been correlated, as described in previous paragraphs, the two entities are now in a position to exchange Control Framework messages. The following sub-sections specify the general behavior for constructing Control Framework requests and responses. Section 6.3 specifies the core Control Framework methods and their transaction processing.
一旦按照第4.1节和第4.2节中的定义建立了成功的控制通道，并且按照前面段落中的描述关联了连接，这两个实体现在就可以交换控制框架消息了。以下小节指定了构造控制框架请求和响应的一般行为。第6.3节规定了核心控制框架方法及其事务处理。
An entity acting as a Control Client that constructs and sends requests on a Control Channel MUST adhere to the syntax defined in Section 9. Note that either entity can act as a Control Client depending on individual package requirements. Control Commands MUST also adhere to the syntax defined by the Control Packages negotiated in Sections 4.1 and 4.2 of this document. A Control Client MUST create a unique transaction and associated identifier for insertion in the request. The transaction identifier is then included in the first line of a Control Framework message along with the method type, as defined in the ABNF in Section 9. The first line starts with the "CFW" token for the purpose of easily extracting the transaction identifier. The transaction identifier MUST be unique in the context of the interaction between the Control Client and Control Server. This unique property helps avoid clashes when multiple client entities could be creating transactions to be carried out on a single receiving server. All required, mandatory, and optional Control Framework headers are then inserted into the request with appropriate values (see relevant individual header information for explicit detail). A 'Control-Package' header MUST also be inserted with the value indicating the Control Package to which this specific request applies. Multiple packages can be negotiated per Control Channel using the SYNC message discussed in Section 6.3.4.2.
作为控制客户端在控制通道上构造和发送请求的实体必须遵守第9节中定义的语法。请注意，这两个实体都可以作为控制客户端，具体取决于各个包的要求。控制命令还必须遵守本文件第4.1节和第4.2节中协商的控制包定义的语法。控制客户端必须创建唯一的事务和关联的标识符，以便插入到请求中。然后，事务标识符与方法类型一起包含在控制框架消息的第一行中，如第9节ABNF中所定义。第一行以“CFW”标记开始，以便轻松提取事务标识符。事务标识符在控制客户端和控制服务器之间的交互上下文中必须是唯一的。当多个客户端实体可以创建要在单个接收服务器上执行的事务时，此唯一属性有助于避免冲突。然后，所有必需的、必需的和可选的控制框架标头都将插入到具有适当值的请求中（有关明确的详细信息，请参阅相关的单个标头信息）。还必须插入一个“控制包”标题，其值指示此特定请求适用的控制包。使用第6.3.4.2节中讨论的同步消息，每个控制通道可以协商多个包。
Any Framework message that contains an associated payload MUST also include the 'Content-Type' and 'Content-Length' message headers, which indicate the MIME type of the payload specified by the individual Control Framework packages and the size of the message body represented as a whole decimal number of octets, respectively. If no associated payload is to be added to the message, the 'Content-Length' header MUST have a value of '0'.
包含相关负载的任何框架消息还必须包括“Content Type”和“Content Length”消息头，这分别指示由各个控制框架包指定的负载的MIME类型和以八位字节整十进制数表示的消息体大小。如果不向消息添加关联的有效负载，“Content Length”标头的值必须为“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*“Transaction-Timeout”的响应，然后根据所使用的扩展包将事务视为失败并适当地整理状态。
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
作为控制服务器的实体在接收到请求时，必须在“事务超时”内生成响应，这是从控制客户端测量的。响应必须符合第9节中定义的ABNF。响应的第一行必须包含请求的第一行中使用的事务标识符，如下所示
defined in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' message headers, and these MUST be ignored if received by a Client in a response.
定义见第6.1节。响应不得包含“状态”或“超时”消息头，如果客户端在响应中收到这些消息头，则必须忽略它们。
A Control Server MUST include a status code in the first line of the response. If there is no error, the Server responds with a 200 Control Framework status code, as defined in Section 7.1. The 200 response MAY include message bodies. If the response contains a payload, the message MUST include the 'Content-Length' and 'Content-Type' headers. When the Control Client receives a 2xx-class response, the Control Command transaction is complete.
控制服务器必须在响应的第一行包含状态代码。如果没有错误，服务器将使用第7.1节中定义的200控制框架状态代码进行响应。200响应可以包括消息体。如果响应包含有效负载，则消息必须包含“内容长度”和“内容类型”标题。当控制客户端收到2xx类响应时，控制命令事务完成。
If the Control Server receives a request, like CONTROL, that the Server understands, but the Server knows processing the command will exceed the 'Transaction-Timeout', then the Server MUST respond with a 202 status code in the first line of the response. Following the initial response, the server will send one or more REPORT messages as described in Section 6.3.2. A Control Package MUST explicitly define the circumstances under which the server sends 200 and 202 messages.
如果控制服务器接收到服务器理解的请求（如控制），但服务器知道处理命令将超过“事务超时”，则服务器必须在响应的第一行中使用202状态代码进行响应。初始响应后，服务器将发送一条或多条报告消息，如第6.3.2节所述。控制包必须明确定义服务器发送200和202条消息的环境。
If a Control Server encounters problems with a Control Framework request (like REPORT or CONTROL), an appropriate error code MUST be used in the response, as listed in Section 7. The generation of a non-2xx-class response code to a Control Framework request (like CONTROL or REPORT) will indicate failure of the transaction, and all associated transaction state and resources MUST be terminated. The response code may provide an explicit indication of why the transaction failed, which might result in a re-submission of the request depending on the extension package being used.
如果控制服务器在控制框架请求（如报告或控制）中遇到问题，则必须在响应中使用适当的错误代码，如第7节所列。对控制框架请求（如控制或报告）生成非2xx类响应代码将指示事务失败，并且必须终止所有关联的事务状态和资源。响应代码可以提供事务失败原因的明确指示，这可能导致请求重新提交，具体取决于所使用的扩展包。
The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods.
控制框架定义了四种类型的请求（方法）：控制、报告、K-ALIVE和同步。实现必须支持发送和接收这四种方法。
The following sub-sections specify each Control Framework method and its associated transaction processing.
以下小节指定了每个控制框架方法及其关联的事务处理。
A CONTROL message is used by the Control Client to pass control-related information to a Control Server. It is also used as the event-reporting mechanism in the Control Framework. Reporting events is simply another usage of the CONTROL message, which is permitted to be sent in either direction between two participants in a session, carrying the appropriate payload for an event. The message is constructed in the same way as any standard Control Framework
控制客户端使用控制消息将控制相关信息传递给控制服务器。它还用作控制框架中的事件报告机制。报告事件只是控制消息的另一种用法，允许在会话中的两个参与者之间向任意方向发送控制消息，并携带事件的适当负载。消息的构造方式与任何标准控制框架相同
message, as discussed in Section 6.1 and defined in Section 9. A CONTROL message MAY contain a message body. The explicit Control Command(s) of the message payload contained in a CONTROL message are specified in separate Control Package specifications. Separate Control Package specifications MUST conform to the format defined in Section 8.4. A CONTROL message containing a payload MUST include a 'Content-Type' header. The payload MUST be one of the payload types defined by the Control Package. Individual packages MAY allow a CONTROL message that does not contain a payload. This could in fact be a valid message exchange within a specific package; if it's not, an appropriate package-level error message MUST be generated.
信息，如第6.1节所述和第9节所定义。控制消息可以包含消息体。控制消息中包含的消息有效负载的显式控制命令在单独的控制包规范中指定。单独的控制包规范必须符合第8.4节规定的格式。包含有效负载的控制消息必须包含“内容类型”标头。有效载荷必须是控制包定义的有效载荷类型之一。单个包可能允许不包含有效负载的控制消息。这实际上可能是特定包内的有效消息交换；如果不是，则必须生成相应的包级别错误消息。
A 'REPORT' message is used by a Control Server when processing of a CONTROL command extends beyond the 'Transaction-Timeout', as measured from the Client. In this case, the Server returns a 202 response. The Server returns status updates and the final results of the command in subsequent REPORT messages.
当控制命令的处理超出从客户端测量的“事务超时”时，控制服务器使用“报告”消息。在这种情况下，服务器返回202响应。服务器将在后续报告消息中返回状态更新和命令的最终结果。
All REPORT messages MUST contain the same transaction ID in the request start line that was present in the original CONTROL transaction. This correlates extended transactions with the original CONTROL transaction. A REPORT message containing a payload MUST include the 'Content-Type' and 'Content-Length' headers indicating the payload MIME type [RFC2045] defined by the Control Package and the length of the payload, respectively.
所有报告消息在请求开始行中必须包含与原始控制事务中相同的事务ID。这将扩展事务与原始控制事务相关联。包含有效负载的报告消息必须包括“Content Type”和“Content Length”头，分别指示由控制包定义的有效负载MIME类型[RFC2045]和有效负载的长度。
On receiving a CONTROL message, a Control Server MUST respond within 'Transaction-Timeout' with a status code for the request, as specified in Section 6.2. If the processing of the command completes within that time, a 200 response code MUST be sent. If the command does not complete within that time, the response code 202 MUST be sent indicating that the requested command is still being processed and the CONTROL transaction is being extended. The REPORT method is then used to update and terminate the status of the extended transaction. The Control Server should not wait until the last possible opportunity to make the decision of issuing a 202 response code and should ensure that it has plenty of time for the response to arrive at the Control Client. If it does not have time, transactions will be terminated (timed out) at the Control Client before completion.
在收到控制消息时，控制服务器必须在“事务超时”内响应请求的状态代码，如第6.2节所述。如果命令处理在该时间内完成，则必须发送200响应代码。如果命令未在该时间内完成，则必须发送响应代码202，指示请求的命令仍在处理中，并且控制事务正在扩展。然后使用REPORT方法更新和终止扩展事务的状态。控制服务器不应等到最后一次可能的机会才做出发出202响应代码的决定，并应确保有足够的时间让响应到达控制客户端。如果没有时间，事务将在完成之前在控制客户端终止（超时）。
A Control Server issuing a 202 response MUST ensure the message contains a 'Timeout' message header. This header MUST have a value in seconds that is the amount of time the recipient of the 202 message MUST wait before assuming that there has been a problem and terminating the extended transaction and associated state.
发出202响应的控制服务器必须确保消息包含“超时”消息头。此标头必须有一个以秒为单位的值，该值是202消息的收件人在假设出现问题并终止扩展事务和关联状态之前必须等待的时间量。
The initial REPORT message MUST contain a 'Seq' (Sequence) message header with a value equal to '1'. Note: the 'Seq' numbers at both Control Client and Control Server for Framework messages are independent.
初始报告消息必须包含值等于“1”的“Seq”（序列）消息头。注意：框架消息的控制客户端和控制服务器上的“Seq”编号是独立的。
All REPORT messages for an extended CONTROL transaction MUST contain a 'Timeout' message header. This header will contain a value in seconds that is the amount of time the recipient of the REPORT message MUST wait before assuming that there has been a problem and terminating the extended transaction and associated state. On receiving a REPORT message with a 'Status' header of 'update', the Control Client MUST reset the timer for the associated extended CONTROL transaction to the indicated timeout period. If the timeout period approaches and no intended REPORT messages have been generated, the entity acting as a Control Framework UAS for the interaction MUST generate a REPORT message containing, as defined in this paragraph, a 'Status' header of 'update' with no associated payload. Such a message acts as a timeout refresh and in no way impacts the extended transaction because no message body or semantics are permitted. It is RECOMMENDED that a minimum value of 10 and a maximum value of 15 seconds be used for the value of the 'Timeout' message header. It is also RECOMMENDED that a Control Server refresh the timeout period of the CONTROL transaction at an interval that is not too close to the expiry time. A value of 80% of the timeout period could be used. For example, if the timeout period is 10 seconds, the Server would refresh the transaction after 8 seconds.
扩展控制事务的所有报告消息必须包含“超时”消息头。此标头将包含一个以秒为单位的值，该值是报告消息的收件人在假设出现问题并终止扩展事务和关联状态之前必须等待的时间量。收到“状态”标题为“更新”的报告消息时，控制客户端必须将相关扩展控制事务的计时器重置为指示的超时时间。如果超时时间接近且未生成预期报告消息，则作为交互控制框架UAS的实体必须生成一条报告消息，其中包含本段中定义的“更新”的“状态”标头，且没有相关的有效负载。这样的消息充当超时刷新，不会影响扩展事务，因为不允许使用消息体或语义。建议将最小值10和最大值15秒用于“超时”消息头的值。还建议控制服务器以不太接近到期时间的间隔刷新控制事务的超时时间。可以使用80%的超时时间。例如，如果超时时间为10秒，服务器将在8秒后刷新事务。
Subsequent REPORT messages that provide additional information relating to the extended CONTROL transaction MUST also include and increment by 1 the 'Seq' header value. A REPORT message received that has not been incremented by 1 MUST be responded to with a 406 response and the extended transaction MUST be considered terminated. On receiving a 406 response, the extended transaction MUST be terminated. REPORT messages MUST also include a 'Status' header with a value of 'update'. These REPORT messages sent to update the extended CONTROL transaction status MAY contain a message body, as defined by individual Control Packages and specified in Section 8.5. A REPORT message sent updating the extended transaction also acts as a timeout refresh, as described earlier in this section. This will result in a transaction timeout period at the initiator of the original CONTROL request being reset to the interval contained in the 'Timeout' message header.
提供与扩展控制事务相关的附加信息的后续报告消息还必须包括“Seq”标题值，并增加1。接收到的未递增1的报告消息必须以406响应响应，扩展事务必须视为已终止。收到406响应后，必须终止扩展事务。报告消息还必须包含值为“更新”的“状态”标题。为更新扩展控制事务状态而发送的这些报告消息可能包含一个消息体，该消息体由各个控制包定义，并在第8.5节中指定。发送的更新扩展事务的报告消息也充当超时刷新，如本节前面所述。这将导致原始控制请求发起方的事务超时时间重置为“超时”消息头中包含的时间间隔。
When all processing for an extended CONTROL transaction has taken place, the entity acting as a Control Server MUST send a terminating REPORT message. The terminating REPORT message MUST increment the value in the 'Seq' message header by the value of '1' from the previous REPORT message. It MUST also include a 'Status' header with a value of 'terminate' and MAY contain a message body. It MUST also contain a 'Timeout' message header with a valid value. The inclusion of the 'Timeout' header is for consistency, and its value is ignored. A Control Framework UAC can then clean up any pending state associated with the original CONTROL transaction.
当扩展控制事务的所有处理完成时，作为控制服务器的实体必须发送终止报告消息。终止报告消息必须将“Seq”消息头中的值从上一个报告消息中增加“1”。它还必须包含一个值为“terminate”的“Status”头，并且可能包含一个消息体。它还必须包含具有有效值的“Timeout”消息头。包含“Timeout”标头是为了一致性，其值将被忽略。然后，控制框架UAC可以清除与原始控制事务关联的任何挂起状态。
The protocol defined in this document may be used in various network architectures. This includes a wide range of deployments where the clients could be co-located in a secured, private domain, or spread across disparate domains that require traversal of devices such as Network Address Translators (NATs) and firewalls. A keep-alive mechanism enables the Control Channel to be kept active during times of inactivity. This is because many firewalls have a timeout period after which connections are closed. This mechanism also provides the ability for application-level failure detection. It should be noted that the following procedures apply only to the Control Channel being created. For details relating to the SIP keep-alive mechanism, implementers should seek guidance from SIP Outbound [RFC5626].
本文件中定义的协议可用于各种网络体系结构。这包括一系列广泛的部署，其中客户端可以位于安全的私有域中，或者分布在需要遍历设备（如网络地址转换器（NAT）和防火墙）的不同域中。保持活动机制使控制通道在不活动期间保持活动。这是因为许多防火墙都有一个超时时间，超过这个时间连接就会关闭。该机制还提供了应用程序级故障检测的能力。应注意，以下程序仅适用于正在创建的控制通道。有关SIP保持活动机制的详细信息，实施者应向SIP Outbound[RFC5626]寻求指导。
The following keep-alive procedures MUST be implemented. Specific deployments MAY choose not to use the keep-alive mechanism if both entities are in a co-located domain. Note that choosing not to use the keep-alive mechanism defined in this section, even when in a co-located architecture, will reduce the ability to detect application-level errors, especially during long periods of inactivity.
必须执行以下保持活动的程序。如果两个实体位于同一个域中，则特定部署可能会选择不使用保持活动机制。请注意，选择不使用本节中定义的保持活动机制，即使在同一位置的体系结构中，也会降低检测应用程序级错误的能力，特别是在长时间不活动的情况下。
Once the SIP INVITE dialog usage has been established and the underlying Control Channel has been set up, including the initial correlation handshake using SYNC as discussed in Section 6, both entities acting in the active and passive roles, as defined in COMEDIA [RFC4145], MUST start a keep-alive timer equal to the value negotiated during the Control Channel SYNC request/response exchange. This is the value from the 'Keep-Alive' header in seconds.
一旦建立了SIP INVITE对话用法并设置了基础控制通道，包括第6节中讨论的使用SYNC的初始相关握手，两个实体都扮演主动和被动角色，如COMEDIA[RFC4145]中所定义，必须启动与控制通道同步请求/响应交换期间协商的值相等的保持活动计时器。这是“保持活动”标题的秒值。
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消息。在接收到用于
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请求时，活动实体必须重置本地保持活动计时器。如果在本地保持活动计时器触发之前，没有收到对K-ALIVE消息的200 OK响应，或者通过一些其他方式检测到传输级别问题，则活动实体可以使用comesia重新协商过程来恢复连接。否则，活动实体必须中断SIP INVITE对话框并恢复关联的控制通道资源。
When acting as a passive entity, a K-ALIVE message must be received before the local keep-alive timer fires. When a K-ALIVE request is received, the passive entity MUST generate a 200 OK Control Framework response and reset the local keep-alive timer. No other Control Framework response is valid. If no K-ALIVE message is received (or a transport level problem is detected by some other means) before the local keep-alive timer fires, the passive entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.
当充当被动实体时，必须在本地保持活动计时器触发之前接收K-ALIVE消息。当收到K-ALIVE请求时，被动实体必须生成200 OK控制框架响应并重置本地保持活动计时器。没有其他有效的控制框架响应。如果在本地保持活动计时器触发之前未收到K-ALIVE消息（或通过其他方式检测到传输级别问题），则被动实体必须中断SIP INVITE对话框并恢复相关的控制通道资源。
The initial SYNC request on a Control Channel is used to negotiate the timeout period for the Control Channel keep-alive mechanism and to allow clients and servers to learn the Control Packages that each supports. Subsequent SYNC requests MAY be used to change the set of Control Packages that can be used on the Control Channel.
控制通道上的初始同步请求用于协商控制通道保持活动机制的超时时间，并允许客户端和服务器了解各自支持的控制包。后续同步请求可用于更改可在控制通道上使用的控制包集。
The initial SYNC request allows the timeout period for the Control Channel keep-alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request:
初始同步请求允许协商控制通道保持活动机制的超时时间。初始同步请求必须遵循以下规则：
o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to active, the 'Keep-Alive' header MUST be included in the SYNC message generated by the offerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to 120 seconds (this is consistent with SIP Outbound [RFC5626]). The value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The client that generated the SDP "Answer" (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value.
o 如果发起SDP报价的客户具有等于active的喜剧“setup”属性，则报价人生成的同步消息中必须包含“Keep Alive”标题。“保持活动”标头的值应在95到120秒的范围内（这与SIP出站[RFC5626]一致）。“保持活动”标题的值不得超过600秒。生成SDP“应答”的客户端（被动客户端）必须将“保持活动”标头复制到同步消息的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
o 如果发起SDP报价的客户端具有等于被动的喜剧“设置”属性，“保持活动”标题参数必须包含在应答者生成的同步消息中。“保持活动”标题的值应在95到100之间
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提供的客户端（被动客户端）必须将“Keep Alive”头复制到同步消息的200响应中，并使用相同的值。
o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to 'actpass', the 'Keep-Alive' header parameter MUST be included in the SYNC message of the entity who is the active participant in the SDP session. If the client generating the subsequent SDP answer places a value of 'active' in the COMEDIA SDP 'setup' attribute, it will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds. If the client generating the subsequent SDP answer places a value of 'passive' in the COMEDIA 'setup' attribute, the original UA making the SDP will generate the SYNC request and include the 'Keep-Alive' header. The value SHOULD be in the range 95 to 120 seconds.
o 如果发起SDP优惠的客户端具有等于“actpass”的喜剧“setup”属性，“Keep Alive”头参数必须包含在作为SDP会话活动参与者的实体的同步消息中。如果生成后续SDP应答的客户端在COMEDIA SDP“setup”属性中放置了一个值“active”，它将生成同步请求并包含“Keep Alive”头。该值应在95到120秒的范围内。如果生成后续SDP应答的客户端在喜剧“设置”属性中放置“被动”值，则生成SDP的原始UA将生成同步请求并包含“保持活动”标头。该值应在95到120秒的范围内。
o If the initial negotiated offer/answer results in a COMEDIA 'setup' attribute equal to 'holdconn', the initial SYNC mechanism will occur when the offer/answer exchange is updated and the active/passive roles are resolved using COMEDIA.
o 如果初始协商的报价/应答导致喜剧“设置”属性等于“holdconn”，则在更新报价/应答交换并使用喜剧解决主动/被动角色时，将出现初始同步机制。
The previous steps ensure that the entity initiating the Control Channel connection is always the one specifying the keep-alive timeout period. It will always be the initiator of the connection who generates the K-ALIVE messages.
前面的步骤确保启动控制通道连接的实体始终是指定保持活动超时时间的实体。生成K-ALIVE消息的始终是连接的发起方。
Once negotiated, the keep-alive timeout applies for the remainder of the Control Framework session. Any subsequent SYNC messages generated in the Control Channel do not impact the negotiated keep-alive property of the session. The 'Keep-Alive' header MUST NOT be included in subsequent SYNC messages, and if it is received, it MUST be ignored.
一旦协商，保持活动超时将应用于控制框架会话的其余部分。在控制通道中生成的任何后续同步消息都不会影响会话的协商保持活动状态属性。“Keep Alive”标头不得包含在后续同步消息中，如果收到，则必须忽略它。
As part of the SYNC message exchange, a client generating the request MUST include a 'Packages' header, as defined in Section 9. The 'Packages' header contains a list of all Control Framework packages that can be supported within this control session, from the perspective of the client creating the SYNC message. All Channel Framework package names MUST be tokens that adhere to the rules set out in Section 8. The 'Packages' header of the initial SYNC message MUST contain at least one value.
作为同步消息交换的一部分，生成请求的客户端必须包括“Packages”头，如第9节所定义。从创建同步消息的客户端的角度来看，“Packages”标头包含此控制会话中可支持的所有控制框架包的列表。所有通道框架包名称必须是符合第8节规定规则的令牌。初始同步消息的“Packages”标头必须至少包含一个值。
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
接收初始同步请求的服务器必须检查“Packages”标头的内容。如果服务器至少支持请求中列出的一个包，则必须以200响应进行响应
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.
密码响应必须包含一个“Packages”头，该头列出了与请求的“Packages”头中的包（全部或子集）相同的受支持包。此列表形成了一组双方都支持的通用控制包。未在同步请求的“Packages”标头中列出的服务器支持的任何控制包都可以放置在响应的“supported”标头中。这将向生成同步请求的客户端提供有关服务器支持的其他包的提示。
If no common packages are supported by the server receiving the SYNC message, it MUST respond with a 422 error response code. The error response MUST contain a 'Supported' header indicating the packages that are supported. The initiating client can then choose to either re-submit a new SYNC message based on the 422 response or consider the interaction a failure. This would lead to termination of the associated SIP INVITE dialog by sending a SIP BYE request, as per [RFC3261].
如果接收同步消息的服务器不支持公共包，则必须使用422错误响应代码进行响应。错误响应必须包含指示支持的包的“受支持”标头。然后，发起客户端可以选择基于422响应重新提交新的同步消息，或者考虑交互失败。根据[RFC3261]，这将通过发送SIP BYE请求来终止相关的SIP INVITE对话框。
Once the initial SYNC transaction is completed, either client MAY choose to send a subsequent new SYNC message to re-negotiate the packages that are supported within the Control Channel. A new SYNC message whose 'Packages' header has different values from the previous SYNC message can effectively add and delete the packages used in the Control Channel. If a client receiving a subsequent SYNC message does not wish to change the set of packages, it MUST respond with a 421 Control Framework response code. Subsequent SYNC messages MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control Framework headers that appeared in the original SYNC negotiation.
初始同步事务完成后，任一客户端都可以选择发送后续的新同步消息，以重新协商控制通道中支持的包。如果新同步消息的“Packages”头与以前的同步消息具有不同的值，则可以有效地添加和删除控制通道中使用的包。如果接收后续同步消息的客户端不希望更改包集，则必须使用421控制框架响应代码进行响应。后续同步消息不得更改原始同步协商中出现的“对话ID”和“保持活动”控制框架标头的值。
An entity MAY honor Control Framework commands relating to a Control Package it no longer supports after package re-negotiation. When the entity does not wish to honor such commands, it MUST respond to the request with a 420 response.
实体可以执行与包重新协商后不再支持的控制包相关的控制框架命令。当实体不希望执行此类命令时，它必须以420响应响应请求。
The following response codes are defined for transaction responses to methods defined in Section 6.1. All response codes in this section MUST be supported and can be used in response to both CONTROL and REPORT messages except that a 202 MUST NOT be generated in response to a REPORT message.
针对第6.1节中定义的方法的交易响应，定义了以下响应代码。必须支持本节中的所有响应代码，并可用于响应控制和报告消息，但不得生成202响应报告消息。
Note that these response codes apply to Framework Transactions only. Success or error indications for Control Commands MUST be treated as the result of a Control Command and returned in either a 200 response or REPORT message.
请注意，这些响应代码仅适用于框架事务。控制命令的成功或错误指示必须视为控制命令的结果，并在200响应或报告消息中返回。
The framework protocol transaction completed successfully.
框架协议事务已成功完成。
The framework protocol transaction completed successfully and additional information will be provided at a later time through the REPORT mechanism defined in Section 6.3.2.
框架协议事务已成功完成，稍后将通过第6.3.2节中定义的报告机制提供更多信息。
The request was syntactically incorrect.
请求在语法上不正确。
The server understood the request, but is refusing to fulfill it. The client SHOULD NOT repeat the request.
服务器理解该请求，但拒绝满足该请求。客户端不应重复该请求。
Method not allowed. The primitive is not supported.
方法不允许。不支持原语。
Message out of sequence.
消息顺序不对。
Intended target of the request is for a Control Package that is not valid for the current session.
请求的预期目标是针对对当前会话无效的控制包。
Recipient does not wish to re-negotiate Control Packages at this moment in time.
接收人此时不希望重新协商控制包。
Recipient does not support any Control Packages listed in the SYNC message.
收件人不支持同步消息中列出的任何控制包。
Recipient has an existing transaction with the same transaction ID.
收件人具有具有相同事务ID的现有事务。
The transaction of the request does not exist. In response to a SYNC request, the 481 response code indicates that the corresponding SIP INVITE dialog usage does not exist.
请求的事务不存在。作为对同步请求的响应，481响应代码表示相应的SIP INVITE对话用法不存在。
The recipient does not understand the request.
收件人不理解该请求。
Control Packages specify behavior that extends the capability defined in this document. Control Packages MUST NOT weaken statements of "MUST" and "SHOULD" strength in this document. A Control Package MAY strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified by the specific usage of the framework.
控制包指定扩展此文档中定义的功能的行为。控制包不得削弱本文件中“必须”和“应该”的声明。如果框架的具体使用证明合理，控制包可以将“应该”、“建议”和“可能”改为“必须”。
In addition to the usual sections expected in Standards-Track RFCs and SIP extension documents, authors of Control Packages need to address each of the issues detailed in the following sub-sections. The following sections MUST be used as a template and included appropriately in all Control-Package specifications. To reiterate, the following sections do not solely form the basis of all Control-Package specifications but are included as a minimum to provide essential package-level information. A Control-Package specification can take any valid form it wishes as long as it includes at least the following information listed in this section.
除了标准跟踪RFC和SIP扩展文件中预期的常规章节外，控制包的作者还需要解决以下小节中详述的每个问题。以下章节必须用作模板，并适当包含在所有控制包规范中。重申一下，以下章节并非仅构成所有控制包规范的基础，而是作为最低要求提供基本的包级信息。控制包规范可以采用其希望的任何有效形式，只要它至少包括本节中列出的以下信息。
This section MUST be present in all extensions to this document and provides a token name for the Control Package. The section MUST include information that appears in the IANA registration of the token. Information on registering Control Package tokens is contained in Section 13.
本节必须出现在本文档的所有扩展中，并为控制包提供令牌名称。该部分必须包括令牌的IANA注册中显示的信息。关于注册控制包令牌的信息包含在第13节中。
The Control Framework defines a number of message primitives that can be used to exchange commands and information. There are no limitations restricting the directionality of messages passed down a Control Channel. This section of a Control Package document MUST explicitly detail the types of Framework messages (Methods) that can be used as well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type.
控制框架定义了许多可用于交换命令和信息的消息原语。没有限制沿控制通道传递的消息的方向性的限制。控制包文档的这一部分必须明确详细说明可以使用的框架消息（方法）的类型，并提供实体之间方向性的指示。这将包括允许哪个角色类型启动请求类型。
This optional section is only included in a Control Package if the attributes for media dialog or conference reference are required, as defined and discussed in Appendix A.1. The Control Package will make strong statements (using language from RFC 2119 [RFC2119]) if the XML schema defined in Appendix A.1 is to be supported. If only part of the schema is required (for example, just 'connectionid' or 'conferenceid'), the Control Package will make equally strong statements (using language from RFC 2119 [RFC2119]).
如附录a.1中所定义和讨论的，仅当需要媒体对话框或会议参考的属性时，此可选部分才包含在控制包中。如果要支持附录A.1中定义的XML模式，控制包将发出强语句（使用RFC 2119[RFC2119]中的语言）。如果只需要部分模式（例如，仅需要“connectionid”或“conferenceid”），则控制包将生成同样强的语句（使用RFC2119[RFC2119]中的语言）。
This mandatory section of a Control Package defines the control body that can be contained within a CONTROL command request, as defined in Section 6, or that no Control Package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type that apply to a CONTROL command request and, optionally, the associated 200 response. For Control Packages that do not have a Control Package body, making such a statement satisfies the "MUST" strength of this section in the Control Package document.
控制包的此强制性部分定义了控制命令请求中可以包含的控制主体（如第6节所定义），或者不需要控制包主体。本节必须指明适用于控制命令请求和（可选）相关200响应的适当MIME[RFC2045]主体类型的详细语法定义和语义的位置。对于没有控制包正文的控制包，做出这样的声明满足控制包文档中本节的“必须”强度。
This mandatory section of a Control Package defines the REPORT body that can be contained within a REPORT command request, as defined in Section 6, or that no report package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type. It should be noted that the Control Framework specification does allow for payloads to exist in 200 responses to CONTROL messages (as defined in this document). An entity that is prepared to receive a payload type in a REPORT message MUST also be prepared to receive the same payload in a 200 response to a CONTROL message. For Control Packages that do not have a Control Package body, stating such satisfies the "MUST" strength of this section in the Control Package document.
控制包的此必填部分定义了可包含在报告命令请求中的报告正文，如第6部分所定义，或者不需要报告包正文。本节必须指明适当MIME[RFC2045]主体类型的详细语法定义和语义的位置。应注意的是，控制框架规范允许有效载荷存在于200个控制消息响应中（如本文档中所定义）。准备在报告消息中接收有效负载类型的实体还必须准备在对控制消息的200响应中接收相同的有效负载。对于没有控制包主体的控制包，说明该控制包满足控制包文件中本节的“必须”强度。
Auditing of various Control Package properties such as capabilities and resources (package-level meta-information) is extremely useful. Such meta-data usually has no direct impact on Control Framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information.
对各种控制包属性（如功能和资源（包级元信息））的审核非常有用。这种元数据通常对控制框架交互没有直接影响，但允许学习上下文信息。鼓励控制包利用控制框架交互来提供相关的包审核信息。
This section SHOULD include the following information:
本节应包括以下信息：
o If an auditing capability is available in this package.
o 如果此包中有审核功能。
o How auditing information is triggered (for example, using a Control Framework CONTROL message) and delivered (for example, in a Control Framework 200 response).
o 如何触发（例如，使用控制框架控制消息）和传递（例如，在控制框架200响应中）审核信息。
o The location of the audit query and response format for the payload (for example, it could be a separate XML schema OR part of a larger XML schema).
o 有效负载的审计查询和响应格式的位置（例如，它可以是单独的XML模式或更大的XML模式的一部分）。
It is strongly RECOMMENDED that Control Packages provide a range of message flows that represent common flows using the package and this framework document.
强烈建议控制包提供一系列消息流，这些消息流表示使用包和本框架文档的公共流。
The Control Framework interactions use the UTF-8 transformation format as defined in [RFC3629]. The syntax in this section uses the Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including types 'DIGIT', 'CRLF', and 'ALPHA'.
控制框架交互使用[RFC3629]中定义的UTF-8转换格式。本节中的语法使用[RFC5234]中定义的增广巴科斯诺尔形式（ABNF），包括类型“DIGIT”、“CRLF”和“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
control-req-or-resp = control-request / control-response
control-request = control-req-start *headers CRLF [control-content]
control-response = control-resp-start *headers CRLF [control-content]
control-req-start = pCFW SP trans-id SP method CRLF
control-resp-start = pCFW SP trans-id SP status-code CRLF
pCFW = %x43.46.57; CFW in caps
trans-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps
mSYNC = %x53.59.4E.43 ; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps
pCFW = %x43.46.57; CFW in caps
trans-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps
mSYNC = %x53.59.4E.43 ; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps
other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents
other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF
headers = header-name CRLF
header-name = (Content-Length
/Content-Type
/Control-Package
/Status
/Seq
/Timeout
/Dialog-ID
/Packages
/Supported
/Keep-alive
/ext-header)
header-name = (Content-Length
/Content-Type
/Control-Package
/Status
/Seq
/Timeout
/Dialog-ID
/Packages
/Supported
/Keep-alive
/ext-header)
Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT
Dialog-ID = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds
Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT
Dialog-ID = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token package-name = alpha-num-token supprtd-alphanum = alpha-num-token kalive-seconds = 1*DIGIT
对话框id字符串=alpha num令牌包名称=alpha num令牌支持alphanum=alpha num令牌kalive seconds=1*位
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
control-content = *OCTET
control-content = *OCTET
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *(SP ";" gen-param )
type = token ; Section 4.2 of RFC 4288
subtype = token ; Section 4.2 of RFC 4288
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *(SP ";" gen-param )
type = token ; Section 4.2 of RFC 4288
subtype = token ; Section 4.2 of RFC 4288
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
ext-header = hname ":" SP hval CRLF
ext header=hname:“SP hval CRLF
hname = ALPHA *token hval = utf8text
hname=ALPHA*标记hval=utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629
The following table details a summary of the headers that can be contained in Control Framework interactions.
下表详细列出了可包含在控制框架交互中的头的摘要。
Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________
Content-Length o o - -
Control-Package R m - - -
Seq - m - -
Status R - m - -
Timeout R - m - -
Timeout 202 - m - -
Dialog-ID R - - m -
Packages - - m -
Supported r - - o -
Keep-Alive R - - o -
Content-Type o o - -
Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________
Content-Length o o - -
Control-Package R m - - -
Seq - m - -
Status R - m - -
Timeout R - m - -
Timeout 202 - m - -
Dialog-ID R - - m -
Packages - - m -
Supported r - - o -
Keep-Alive R - - o -
Content-Type o o - -
Table 1: Summary of Headers in Control Framework Interactions
表1：控制框架交互中的标题摘要
The notation used in Table 1 is as follows:
表1中使用的符号如下：
R: header field may only appear in requests. r: header field may only appear in responses. 2xx, 4xx, etc.: response codes with which the header field can be used. [blank]: header field may appear in either requests or responses. m: header field is mandatory. o: header field is optional. -: header field is not applicable (ignored if present).
R：标题字段只能出现在请求中。r：标题字段只能出现在响应中。2xx、4xx等：可以使用标题字段的响应代码。[空白]：标题字段可能出现在请求或响应中。m：标题字段是必需的。o:标题字段是可选的。-:标题字段不适用（如果存在则忽略）。
This specification defines a new media-level value attribute: 'cfw-id'. Its formatting in SDP is described by the following ABNF [RFC5234].
此规范定义了一个新的媒体级别值属性：“cfw id”。其SDP格式由以下ABNF[RFC5234]描述。
cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF
cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF
cfw-id-name = token
cfw-id-name = token
token = 1*(token-char)
token = 1*(token-char)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
The token-char and token elements are defined in [RFC4566] but included here to provide support for the implementer of this SDP feature.
[RFC4566]中定义了令牌字符和令牌元素，但此处包含这些元素是为了为该SDP功能的实现者提供支持。
The following examples provide an abstracted flow of Control Channel establishment and Control Framework message exchange. The SIP signaling is prefixed with the token 'SIP'. All other messages are Control Framework interactions defined in this document.
以下示例提供了控制通道建立和控制框架消息交换的抽象流程。SIP信令以令牌“SIP”作为前缀。所有其他消息都是本文档中定义的控制框架交互。
In this example, the Control Client establishes a Control Channel, SYNCs with the Control Server, and issues a CONTROL request that can't be completed within the 'Transaction-Timeout', so the Control Server returns a 202 response code to extend the transaction. The Control Server then follows with REPORTs until the requested action has been completed. The SIP INVITE dialog is then terminated.
在此示例中，控制客户端建立控制通道，与控制服务器同步，并发出无法在“事务超时”内完成的控制请求，因此控制服务器返回202响应代码以扩展事务。然后，控制服务器会继续报告，直到请求的操作完成。然后终止SIP INVITE对话框。
Control Client Control Server
| |
| (1) SIP INVITE |
| ----------------------------------------> |
| |
| (2) SIP 200 |
| <--------------------------------------- |
| |
| (3) SIP ACK |
| ----------------------------------------> |
| |
|==>=======================================>==|
| Control Channel Established |
|==>=======================================>==|
| |
| (4) SYNC |
| ----------------------------------------> |
| |
| (5) 200 |
| <--------------------------------------- |
| |
| (6) CONTROL |
| ----------------------------------------> |
| |
Control Client Control Server
| |
| (1) SIP INVITE |
| ----------------------------------------> |
| |
| (2) SIP 200 |
| <--------------------------------------- |
| |
| (3) SIP ACK |
| ----------------------------------------> |
| |
|==>=======================================>==|
| Control Channel Established |
|==>=======================================>==|
| |
| (4) SYNC |
| ----------------------------------------> |
| |
| (5) 200 |
| <--------------------------------------- |
| |
| (6) CONTROL |
| ----------------------------------------> |
| |
(1) Control Client-->Control Server (SIP): INVITE
sip:control-server@example.com
(1) Control Client-->Control Server (SIP): INVITE
sip:control-server@example.com
INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp
Content-Length: 206
INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp
Content-Length: 206
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example.com
s=-
c=IN IP4 control-client.example.com
m=application 49153 TCP cfw
a=setup:active
a=connection:new
a=cfw-id:fndskuhHKsd783hjdla
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example.com
s=-
c=IN IP4 control-client.example.com
m=application 49153 TCP cfw
a=setup:active
a=connection:new
a=cfw-id:fndskuhHKsd783hjdla
(2) Control Server-->Control Client (SIP): 200 OK
(2) 控制服务器-->控制客户端（SIP）：200正常
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc2.example.com>
Content-Type: application/sdp
Content-Length: 203
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc2.example.com>
Content-Type: application/sdp
Content-Length: 203
v=0
o=responder 2890844600 2890842900 IN IP4 controller.example.com
s=-
c=IN IP4 control-server.example.com
m=application 49153 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:7JeDi23i7eiysi32
v=0
o=responder 2890844600 2890842900 IN IP4 controller.example.com
s=-
c=IN IP4 control-server.example.com
m=application 49153 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:7JeDi23i7eiysi32
(3) Control Client-->Control Server (SIP): ACK
(3) 控制客户端-->控制服务器（SIP）：确认
(4) Control Client opens a TCP connection to the Control Server. The connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): SYNC.
(4) 控制客户端打开到控制服务器的TCP连接。该连接现在可用于交换控制框架消息。控制客户端-->控制服务器（控制框架消息）：同步。
CFW 8djae7khauj SYNC Dialog-ID: fndskuhHKsd783hjdla Keep-Alive: 100 Packages: msc-ivr-basic/1.0
CFW 8djae7khauj同步对话框ID:FNDSKUHKSD783HJDLA保持活动状态：100个包：msc ivr basic/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
Keep-Alive: 100
Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
(6) Once the SYNC process has completed, the connection can now be used to exchange Control Framework messages. Control Client-->Control Server (Control Framework message): CONTROL.
(6) 同步过程完成后，连接现在可用于交换控制框架消息。控制客户端-->控制服务器（控制框架消息）：控制。
CFW i387yeiqyiq CONTROL
Control-Package: <package-name>
Content-Type: example_content/example_content
CFW i387yeiqyiq CONTROL
Control-Package: <package-name>
Content-Type: example_content/example_content
Content-Length: 11
内容长度：11
<XML BLOB/>
<XML BLOB/>
(7) Control Server-->Control Client (Control Framework message): 202.
(7) 控制服务器-->控制客户端（控制框架消息）：202。
CFW i387yeiqyiq 202 Timeout: 10
CFW i387yeiqyiq 202超时：10
(8) Control Server-->Control Client (Control Framework message): REPORT.
(8) 控制服务器-->控制客户端（控制框架消息）：报告。
CFW i387yeiqyiq REPORT Seq: 1 Status: update Timeout: 10
CFW I387YEIQYIQYIQ报告序列：1状态：更新超时：10
(9) Control Client-->Control Server (Control Framework message): 200.
(9) 控制客户端-->控制服务器（控制框架消息）：200。
CFW i387yeiqyiq 200 Seq: 1
CFW I387YEIQYIQYIQ 200序列：1
(10) Control Server-->Control Client (Control Framework message): REPORT.
（10） 控制服务器-->控制客户端（控制框架消息）：报告。
CFW i387yeiqyiq REPORT Seq: 2 Status: update Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
CFW I387YEIQYIQYIQ报告序列：2状态：更新超时：10内容类型：示例内容/示例内容长度：11
<XML BLOB/>
<XML BLOB/>
(11) Control Client-->Control Server (Control Framework message): 200.
（11） 控制客户端-->控制服务器（控制框架消息）：200。
CFW i387yeiqyiq 200 Seq: 2
CFW I387YEIQYIQYIQ 200序列：2
(12) Control Server-->Control Client (Control Framework message): REPORT.
（12） 控制服务器-->控制客户端（控制框架消息）：报告。
CFW i387yeiqyiq REPORT Seq: 3 Status: terminate
CFW I387YEIQYIQYIQ报告序列：3状态：终止
Timeout: 10 Content-Type: example_content/example_content Content-Length: 11
超时：10内容类型：示例内容/示例内容长度：11
<XML BLOB/>
<XML BLOB/>
(13) Control Client-->Control Server (Control Framework message): 200.
（13） 控制客户端-->控制服务器（控制框架消息）：200。
CFW i387yeiqyiq 200 Seq: 3
CFW I387YEIQYIQYIQ 200序列：3
(14) Control Client-->Control Server (SIP): BYE
（14） 控制客户端-->控制服务器（SIP）：再见
BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Length: 0
BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Length: 0
(15) Control Server-->Control Client (SIP): 200 OK
（15） 控制服务器-->控制客户端（SIP）：200正常
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5
CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc1.example.com>
Content-Length: 0
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5
CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc1.example.com>
Content-Length: 0
The Media Control Channel Framework was designed to be only minimally extensible. New methods, header fields, and status codes can be defined in Standards-Track RFCs. The Media Control Channel Framework does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and it MUST describe how its use will be signaled.
媒体控制通道框架的设计仅具有最低限度的可扩展性。可以在标准跟踪RFC中定义新方法、标题字段和状态代码。媒体控制通道框架不包含版本号或任何协商机制，以要求或发现新功能。如果将来指定了需要协商的扩展，则规范将需要描述如何在封装信令协议中协商扩展。如果将来发生不可互操作的更新或扩展，它将被视为一个新协议，并且它必须描述如何通知其使用。
In order to allow extension header fields without breaking interoperability, if a Media Control Channel device receives a request or response containing a header field that it does not understand, it MUST ignore the header field and process the request or response as if the header field was not present. If a Media Control Channel device receives a request with an unknown method, it MUST return a 500 response.
为了在不破坏互操作性的情况下允许扩展标头字段，如果媒体控制通道设备接收到包含其不理解的标头字段的请求或响应，则必须忽略标头字段，并像标头字段不存在一样处理请求或响应。如果媒体控制通道设备接收到方法未知的请求，则必须返回500响应。
The Channel Framework provides confidentiality and integrity for the messages it transfers. It also provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked, as discussed in the remainder of this section.
通道框架为其传输的消息提供机密性和完整性。它还保证连接的主机是它要连接的主机，并且连接没有被劫持，如本节其余部分所述。
In design, the Channel Framework complies with the security-related requirements documented in "Media Server Control Protocol Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12, REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by the Channel Framework are summarized in the following sub-sections.
在设计中，通道框架符合“媒体服务器控制协议要求”[RFC5167]中记录的安全相关要求——更具体地说，是REQ-MCP-11、REQ-MCP-12、REQ-MCP-13和REQ-MCP-14。渠道框架采用的具体安全措施总结在以下小节中。
Channel Framework sessions are established as media sessions described by SDP within the context of a SIP INVITE dialog. In order to ensure secure rendezvous between Control Framework clients and servers, the Media Channel Control Framework should make full use of mechanisms provided by SIP. The use of the 'cfw-id' SDP attribute results in important session information being carried across the SIP network. For this reason, SIP clients using this specification MUST use appropriate security mechanisms, such as TLS [RFC5246] and SMIME [RFC5751], when deployed in open networks.
通道框架会话建立为SDP在SIP INVITE对话框上下文中描述的媒体会话。为了保证控制框架客户端和服务器之间的安全会合，媒体通道控制框架应该充分利用SIP提供的机制。“cfw id”SDP属性的使用会导致通过SIP网络传输重要的会话信息。因此，当部署在开放网络中时，使用此规范的SIP客户端必须使用适当的安全机制，如TLS[RFC5246]和SMIME[RFC5751]。
When using only TCP connections, the Channel Framework security is weak. Although the Channel Framework requires the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see data exchanges.
仅使用TCP连接时，通道框架安全性较弱。尽管通道框架要求能够保护此交换，但不能保证始终使用此保护。如果不使用这种保护，任何人都可以看到数据交换。
Sensitive data, such as private and financial data, is carried over the Control Framework channel. Clients and servers must be properly authenticated/authorized and the Control Channel must permit the use of confidentiality, replay protection, and integrity protection for the data. To ensure Control Channel protection, Control Framework clients and servers MUST support TLS and SHOULD use it by default
敏感数据，如私人和财务数据，通过控制框架通道传输。客户端和服务器必须经过适当的身份验证/授权，并且控制通道必须允许对数据使用机密性、重播保护和完整性保护。为确保控制通道保护，控制框架客户端和服务器必须支持TLS，并且默认情况下应使用TLS
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]).
除非使用替代控制通道保护或网络管理员保证受保护的环境。如果需要，可以使用替代控制通道保护（例如，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，还必须实现用于服务器名称指示的TLS ClientExtendedHello扩展hello信息，如[RFC5246]中所述。必须支持TLS_RSA_与_AES_128_CBC_SHA[RFC3261]的TLS密码套件。还可能支持其他密码套件。
When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922 [RFC5922].
当TLS客户端与服务器建立连接时，它将显示服务器的X.509证书。按照RFC 5922[RFC5922]第7.3节（“客户行为”）的规定进行认证。
A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922 [RFC5922].
符合本规范的TLS服务器必须要求客户端证书；如果客户机拥有一个证书，它将被提交给服务器进行相互身份验证，身份验证将按照RFC 5922[RFC5922]第7.4节（“服务器行为”）中的描述进行。
This specification permits the establishment of a dedicated Control Channel using SIP. It is also permitted for entities to create multiple channels for the purpose of failover and redundancy. As a general solution, the ability for multiple entities to create connections and have access to resources could be the cause of potential conflict in shared environments. It should be noted that this document does not carry any specific mechanism to overcome such conflicts but will provide a summary of how to do so.
本规范允许使用SIP建立专用控制信道。还允许实体为故障切换和冗余目的创建多个通道。作为一种通用解决方案，多个实体创建连接和访问资源的能力可能是共享环境中潜在冲突的原因。应当指出的是，本文件没有任何克服此类冲突的具体机制，但将概述如何克服这些冲突。
It can be determined that access to resources and use of Control Channels relate to policy. It can be considered implementation and deployment detail that dictates the level of policy that is adopted. The authorization and associated policy of a Control Channel can be linked to the authentication mechanisms described in this section. For example, strictly authenticating a Control Channel using TLS authentication allows entities to protect resources and ensure the required level of granularity. Such policy can be applied at the package level or even as low as a structure like a conference instance (Control Channel X is not permitted to issue commands for Control Package y OR Control Channel A is not permitted to issue commands for conference instance B). Systems should ensure that, if
可以确定对资源的访问和控制渠道的使用与策略有关。可以将其视为实施和部署细节，它决定了所采用的策略级别。控制通道的授权和相关策略可以链接到本节中描述的身份验证机制。例如，使用TLS身份验证严格验证控制通道允许实体保护资源并确保所需的粒度级别。这种策略可以在包级别应用，甚至可以低到像会议实例这样的结构（控制通道X不允许为控制包y发出命令，或者控制通道a不允许为会议实例B发出命令）。系统应确保，如果
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身份验证）可以实现最健壮的策略形式。本规范提供控制信道响应代码（403），以向命令的发出者指示不允许该命令。403响应必须发布到已实施策略不允许的控制框架请求。如果收到403响应，控制框架客户端可以选择重新提交具有不同要求的请求，或者放弃该请求。由于本规范的通用性，403响应不提供有关策略失败的任何其他信息。如果需要，单独的控制包可以提供附加信息。本规范不强制要求提供此类附加信息的机制。应该注意的是，除了本节所述的政策要求之外，还可以在单独的包中定义和应用额外的政策要求，这些包为访问资源等指定了更精细的粒度。
IANA has created a new registry for SIP Control Framework parameters. The "Media Control Channel Framework Parameters" registry is a container for sub-registries. This section further introduces sub-registries for control packages, method names, status codes, header field names, and port and transport protocol.
IANA为SIP控制框架参数创建了一个新的注册表。“媒体控制通道框架参数”注册表是子注册表的容器。本节进一步介绍控制包的子注册表、方法名称、状态代码、头字段名称以及端口和传输协议。
Additionally, Section 13.6 registers a new MIME type for use with SDP.
此外，第13.6节注册了一个新的MIME类型，用于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.
对于本文档创建的所有注册中心和子注册中心，创建新注册时应用的策略也将在更改现有注册时应用。
This specification establishes the Control Packages sub-registry under Media Control Channel Framework Packages. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream), using the IANA policy [RFC5226] "RFC Required".
本规范在介质控制通道框架包下建立控制包子注册表。必须使用IANA策略[RFC5226]“需要RFC”在RFC（IETF流或独立提交流）中发布此子注册表中的新参数。
As this document specifies no package or template-package names, the initial IANA registration for Control Packages will be empty. The remainder of the text in this section gives an example of the type of information to be maintained by the IANA.
由于本文档未指定包或模板包名称，控制包的初始IANA注册将为空。本节剩余部分给出了IANA需要维护的信息类型示例。
The table below lists the Control Packages defined in the "Media Control Channel Framework".
下表列出了“媒体控制渠道框架”中定义的控制包。
Package Name Reference
------------ ---------
example1 [RFCXXXX]
Package Name Reference
------------ ---------
example1 [RFCXXXX]
Package Name:
包名称：
(Package names must conform to the syntax described in Section 8.1.)
（软件包名称必须符合第8.1节中描述的语法。）
Published Specification(s):
已发布的规范：
(Control Packages require an RFC.)
（控制包需要RFC。）
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
This specification establishes the Method Names sub-registry under Media Control Channel Framework Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream).
此规范在媒体控制通道框架参数下建立方法名称子注册表，并按如下方式启动其填充。此子注册表中的新参数必须在RFC中发布（在IETF流或独立提交流中）。
CONTROL - [RFC6230]
REPORT - [RFC6230]
SYNC - [RFC6230]
K-ALIVE - [RFC6230]
CONTROL - [RFC6230]
REPORT - [RFC6230]
SYNC - [RFC6230]
K-ALIVE - [RFC6230]
The following information MUST be provided in an RFC in order to register a new Control Framework method:
为了注册新的控制框架方法，必须在RFC中提供以下信息：
o The method name.
o 方法名称。
o The RFC number in which the method is registered.
o 注册方法的RFC编号。
This specification establishes the Status Code sub-registry under Media Control Channel Framework Parameters. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined in Section 9. It takes the following format:
本规范在介质控制通道框架参数下建立状态代码子注册表。此子注册表中的新参数必须在RFC中发布（在IETF流或独立提交流中）。第9节对其初始人口进行了定义。它采用以下格式：
Code Description Reference
代码描述参考
The following information MUST be provided in an RFC in order to register a new Control Framework status code:
为了注册新的控制框架状态代码，必须在RFC中提供以下信息：
o The status code number.
o 状态代码编号。
o The RFC number in which the method is registered.
o 注册方法的RFC编号。
o A brief description of the status code.
o 状态代码的简要说明。
This specification establishes the Header Field sub-registry under Media Control Channel Framework Parameters. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined as follows:
本规范在介质控制通道框架参数下建立标头字段子注册表。此子注册表中的新参数必须在RFC中发布（在IETF流或独立提交流中）。其初始人口定义如下：
Control-Package - [RFC6230]
Status - [RFC6230]
Seq - [RFC6230]
Timeout - [RFC6230]
Dialog-ID - [RFC6230]
Packages - [RFC6230]
Supported - [RFC6230]
Keep-Alive - [RFC6230]
Content-Type - [RFC6230]
Content-Length - [RFC6230]
Control-Package - [RFC6230]
Status - [RFC6230]
Seq - [RFC6230]
Timeout - [RFC6230]
Dialog-ID - [RFC6230]
Packages - [RFC6230]
Supported - [RFC6230]
Keep-Alive - [RFC6230]
Content-Type - [RFC6230]
Content-Length - [RFC6230]
The following information MUST be provided in an RFC in order to register a new Channel Framework header field:
为了注册新的Channel Framework标头字段，必须在RFC中提供以下信息：
o The header field name.
o 标题字段名。
o The RFC number in which the method is registered.
o 注册方法的RFC编号。
The Control Framework uses TCP port 7563, from the "registered" port range. Usage of this value is described in Section 4.1.
控制框架使用“已注册”端口范围中的TCP端口7563。第4.1节描述了该值的用法。
This section describes the media types and names associated with payload formats used by the Control Framework. The registration uses the templates defined in [RFC4288]. It follows [RFC4855].
本节描述与控制框架使用的有效负载格式相关联的媒体类型和名称。注册使用[RFC4288]中定义的模板。它遵循[RFC4855]。
Type name: application
类型名称：应用程序
Subtype name: cfw
子类型名称：cfw
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: Binary and see Section 4 of RFC 6230
编码注意事项：二进制编码，参见RFC 6230第4节
Security considerations: See Section 12 of RFC 6230
安全注意事项：见RFC 6230第12节
Interoperability considerations: Endpoints compliant to this specification must use this MIME type. Receivers who cannot support this specification will reject using appropriate protocol mechanism.
互操作性注意事项：符合此规范的端点必须使用此MIME类型。不支持此规范的接收器将拒绝使用适当的协议机制。
Published specification: RFC 6230
已发布规范：RFC 6230
Applications that use this media type: Applications compliant with Media Control Channels.
使用此介质类型的应用程序：与介质控制通道兼容的应用程序。
Additional Information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Additional Information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: Should be used only in conjunction with this specification, RFC 6230.
使用限制：只能与本规范RFC 6230结合使用。
Author: Chris Boulton
作者：克里斯·博尔顿
Change controller: IETF MEDIACTRL working group, delegated from the IESG.
变更控制者：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].
可选参数：与RFC 3023[RFC3023]中指定的application/xml的字符集参数相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
编码注意事项：与RFC 3023[RFC3023]中指定的应用程序/xml的编码注意事项相同。
Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework.
安全注意事项：除了核心媒体控制通道框架提供的安全注意事项外，没有已知的安全注意事项。
Interoperability considerations: This content type provides common constructs for related Media Control Channel packages.
互操作性注意事项：此内容类型为相关的媒体控制通道包提供通用构造。
Published specification: RFC 6230
已发布规范：RFC 6230
Applications that use this media type: Implementations of appropriate Media Control Channel packages.
使用此介质类型的应用程序：适当介质控制通道包的实现。
Additional information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Additional information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller: The IETF
作者/变更控制者：IETF
Other information: None.
其他资料：无。
Contact name: Chris Boulton <chris@ns-technologies.com>
Contact name: Chris Boulton <chris@ns-technologies.com>
Attribute name: "cfw-id".
属性名称：“cfw id”。
Type of attribute Media level.
媒体级别属性的类型。
Subject to charset: Not.
以字符集为准：不。
Purpose of attribute: The 'cfw-id' attribute indicates an identifier that can be used to correlate the Control Channel with the SIP INVITE dialog used to negotiate it, when the attribute value is used within the Control Channel.
属性用途：“cfw id”属性表示当属性值在控制通道内使用时，可用于将控制通道与用于协商的SIP INVITE对话框关联的标识符。
Allowed attribute values: A token.
允许的属性值：标记。
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes
IANA has registered a new XML namespace, "urn:ietf:params:xml:ns:control:framework-attributes", per the guidelines in RFC 3688 [RFC3688].
IANA已经按照RFC 3688[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:control:framework attributes”。
URI: urn:ietf:params:xml:ns:control:framework-attributes
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
注册人联系人：IETF MEDIACTRL工作组<mediactrl@ietf.org>，克里斯·博尔顿<chris@ns-technologies.com>。
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt">
RFC 6230</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt">
RFC 6230</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in RFC 3688 [RFC3688].
本节根据RFC 3688[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:ns:control:framework-attributes
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, Chris Boulton <chris@ns-technologies.com>.
注册人联系人：IETF MEDIACTRL工作组<mediactrl@ietf.org>，克里斯·博尔顿<chris@ns-technologies.com>。
Schema: The XML for this schema can be found in Appendix A.1 of this document.
模式：此模式的XML可在本文档的附录A.1中找到。
Asher Shiratzky from Radvision provided valuable support and contributions to the early versions of this document.
Radvision的Asher Shiratzky为本文件的早期版本提供了宝贵的支持和贡献。
The authors would like to thank Ian Evans of Avaya, Michael Bardzinski and John Dally of NS-Technologies, Adnan Saleem of Radisys, and Dave Morgan for useful review and input to this work. Eric Burger contributed to the early phases of this work.
作者要感谢Avaya的Ian Evans、NS Technologies的Michael Bardzinski和John Dally、Radisys的Adnan Saleem和Dave Morgan对这项工作的有益评论和投入。Eric Burger为这项工作的早期阶段做出了贡献。
Expert review was also provided by Spencer Dawkins, Krishna Prasad Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided expert guidance on the dialog association mechanism. Lorenzo Miniero has constantly provided excellent feedback based on his work.
斯宾塞·道金斯（Spencer Dawkins）、克里希纳·普拉萨德·卡卢里（Krishna Prasad Kalluri）、洛伦佐·米尼罗（Lorenzo Miniero）和罗尼·伊恩（Roni Even）也提供了专家评审。Hadriel Kaplan就对话协会机制提供了专家指导。Lorenzo Miniero根据他的工作不断提供优秀的反馈。
Ben Campbell carried out the RAI expert review on this document and provided a great deal of invaluable input. Brian Weis carried out a thorough security review. Jonathan Lennox carried out a thorough SDP review that provided some excellent modifications. Text from Eric Burger was used in the introduction in the explanation for using SIP.
Ben Campbell对该文件进行了RAI专家评审，并提供了大量宝贵的意见。Brian Weis进行了彻底的安全审查。Jonathan Lennox进行了全面的SDP审查，提供了一些出色的修改。介绍中使用了Eric Burger的文本，并解释了如何使用SIP。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年8月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922]Gurbani，V.，Lawrence，S.，和A.Jeffrey，“会话启动协议（SIP）中的域证书”，RFC 59222010年6月。
[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.
[MSCL-Thinks]Burger，E.，“媒体服务器控制语言和协议思想”，进展中的工作，2006年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]Taylor，T.，“将RFC 3525重新分类为历史”，RFC 51252008年2月。
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167]Dolly，M.和R.Een，“媒体服务器控制协议要求”，RFC 51672008年3月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
During the creation of the Control Framework, it has become clear that there are a number of components that are common across multiple packages. It has become apparent that it would be useful to collect such reusable components in a central location. In the short term, this appendix provides the placeholder for the utilities, and it is the intention that this section will eventually form the basis of an initial 'Utilities Document' that can be used by Control Packages.
在创建控制框架的过程中，很明显有许多组件在多个包中是通用的。很明显，在一个中心位置收集这样的可重用组件是有用的。在短期内，本附录为公用设施提供了占位符，本节的目的是最终形成可由控制包使用的初始“公用设施文件”的基础。
The following schema provides some common attributes for allowing Control Packages to apply specific commands to a particular SIP media dialog (also referred to as "Connection") or conference. If used within a Control Package, the Connection and multiparty attributes will be imported and used appropriately to specifically identify either a SIP dialog or a conference instance. If used within a package, the value contained in the 'connectionid' attribute MUST be constructed by concatenating the 'Local' and 'Remote' SIP dialog identifier tags as defined in [RFC3261]. They MUST then be separated using the ':' character. So the format would be:
以下模式提供了一些通用属性，用于允许控制包将特定命令应用于特定的SIP媒体对话框（也称为“连接”）或会议。如果在控制包中使用，则将导入连接和多方属性，并适当地使用它们来专门标识SIP对话框或会议实例。如果在包中使用，“connectionid”属性中包含的值必须通过连接[RFC3261]中定义的“本地”和“远程”SIP对话框标识符标记来构造。然后必须使用“：”字符将它们分开。因此，格式应为：
'Local Dialog tag' + ':' + 'Remote Dialog tag'
'Local Dialog tag' + ':' + 'Remote Dialog tag'
As an example, for an entity that has a SIP Local dialog identifier of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 'connectionid' attribute for a Control Framework command would be:
例如，对于具有SIP本地对话标识符“7HDY839”和远程对话标识符“HJKSkyHS”的实体，控制框架命令的“connectionid”属性应为：
7HDY839:HJKSkyHS
7HDY839:HJKSkyHS
It should be noted that Control Framework requests initiated in conjunction with a SIP dialog will produce a different 'connectionid' value depending on the directionality of the request; for example, Local and Remote tags are locally identifiable.
应注意，结合SIP对话发起的控制框架请求将根据请求的方向性产生不同的“connectionid”值；例如，本地和远程标记是本地可识别的。
As with the Connection attribute previously defined, it is useful to have the ability to apply specific Control Framework commands to a number of related dialogs, such as a multiparty call. This typically consists of a number of media dialogs that are logically bound by a single identifier. The following schema allows for Control Framework commands to explicitly reference such a grouping through a 'conferenceid' XML container. If used by a Control Package, any control XML referenced by the attribute applies to all related media dialogs. Unlike the dialog attribute, the 'conferenceid' attribute does not need to be constructed based on the overlying SIP dialog. The 'conferenceid' attribute value is system specific and should be selected with relevant context and uniqueness.
与前面定义的连接属性一样，能够将特定的控制框架命令应用于多个相关对话框（例如多方调用）非常有用。这通常由多个由单个标识符逻辑绑定的媒体对话框组成。以下模式允许控制框架命令通过“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" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>
</xsd:attributeGroup>
</xsd:schema>
Authors' Addresses
作者地址
Chris Boulton NS-Technologies
克里斯·博尔顿技术公司
EMail: chris@ns-technologies.com
EMail: chris@ns-technologies.com
Tim Melanchuk Rainwillow
蒂姆·梅兰丘克·雷威洛
EMail: timm@rainwillow.com
EMail: timm@rainwillow.com
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
斯科特·麦克拉山-惠普古斯塔夫三世：瑞典斯德哥尔摩东南-16985号s大道36号
EMail: smcg.stds01@mcglashan.org
EMail: smcg.stds01@mcglashan.org