diff options
Diffstat (limited to 'doc/rfc/rfc6230.txt')
| -rw-r--r-- | doc/rfc/rfc6230.txt | 2747 |
1 files changed, 2747 insertions, 0 deletions
diff --git a/doc/rfc/rfc6230.txt b/doc/rfc/rfc6230.txt new file mode 100644 index 0000000..9b25d98 --- /dev/null +++ b/doc/rfc/rfc6230.txt @@ -0,0 +1,2747 @@ + + + + + + +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. + + The motivation for the creation of this framework is to provide an + interface suitable to meet the requirements of a centralized + conference system, where the conference system can be distributed, as + defined by the XCON working group in the IETF. It is not, however, + limited to this scope. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + 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. + + + + + + + + + + +Boulton, et al. Standards Track [Page 1] + +RFC 6230 Media Control Channel Framework May 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + + +Boulton, et al. Standards Track [Page 2] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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 + + + + + + + + + + + + + + +Boulton, et al. Standards Track [Page 3] + +RFC 6230 Media Control Channel Framework May 2011 + + +1. Introduction + + Real-time media applications are often developed using an + architecture where the application logic and media processing + activities are distributed. Commonly, the application logic runs on + "application servers", but the processing runs on external servers, + such as "media servers". This document focuses on the framework and + protocol between the application server and external processing + server. The motivation for this framework comes from a set of + requirements for Media Server Control, which can be found in "Media + Server Control Protocol Requirements" [RFC5167]. While the Framework + is not specific to media server control, it is the primary driver and + use case for this work. It is intended that the framework contained + in this document be able to be used for a variety of device control + scenarios (for example, conference control). + + This document does not define a particular SIP extension for the + direct control of external components. Rather, other documents, + known as "Control Packages", extend the Control Framework described + by this document. Section 8 provides a comprehensive set of + guidelines for creating such Control Packages. + + Current IETF device control protocols, such as Megaco [RFC5125], + while excellent for controlling media gateways that bridge separate + networks, are troublesome for supporting media-rich applications in + SIP networks. This is because Megaco duplicates many of the + functions inherent in SIP. Rather than using a single protocol for + session establishment and application media processing, application + developers need to translate between two separate mechanisms. + Moreover, the model provided by the framework presented here, using + SIP, better matches the application programming model than does + Megaco. + + 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. + +2. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119], as + scoped to those conformance targets. + + + + + + +Boulton, et al. Standards Track [Page 4] + +RFC 6230 Media Control Channel Framework May 2011 + + + The following additional terms are defined for use in this document: + + User Agent Client (UAC): As specified in [RFC3261]. + + User Agent Server (UAS): As specified in [RFC3261]. + + B2BUA: A B2BUA is a Back-to-Back SIP User Agent. + + Control Server: A Control Server is an entity that performs a + service, such as media processing, on behalf of a Control Client. + For example, a media server offers mixing, announcement, tone + detection and generation, and play and record services. The + Control Server has a direct Real-Time Transport Protocol (RTP) + [RFC3550] relationship with the source or sink of the media flow. + In this document, we often refer to the Control Server simply as + "the Server". + + Control Client: A Control Client is an entity that requests + processing from a Control Server. Note that the Control Client + might not have any processing capabilities whatsoever. For + example, the Control Client may be an application server (B2BUA) + or other endpoint requesting manipulation of a third party's media + stream that terminates on a media server acting in the role of a + Control Server. In this document, we often refer to the Control + Client simply as "the Client". + + Control Channel: A Control Channel is a reliable connection between + a Client and Server that is used to exchange Framework messages. + The term "Connection" is used synonymously within this document. + + Framework Message: A Framework message is a message on a Control + Channel that has a type corresponding to one of the Methods + defined in this document. A Framework message is often referred + to by its method, such as a "CONTROL message". + + Method: A Method is the type of a Framework message. Four Methods + are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE. + + 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 + + + +Boulton, et al. Standards Track [Page 5] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + +3. Overview + + This document details mechanisms for establishing, using, and + terminating a reliable transport connection channel using SIP and the + Session Description Protocol offer/answer [RFC3264] exchange. The + established connection is then used for controlling an external + server. The following text provides a non-normative overview of the + mechanisms used. Detailed, normative guidelines are provided later + in the document. + + Control Channels are negotiated using standard SIP mechanisms that + would be used in a similar manner to creating a SIP multimedia + session. Figure 1 illustrates a simplified view of the mechanism. + It highlights a separation of the SIP signaling traffic and the + associated Control Channel that is established as a result of the SIP + interactions. + + Initial analysis into the Control Framework, as documented in + [MSCL-THOUGHTS], established the following. One might ask, "If all + we are doing is establishing a TCP connection to control the media + server, why do we need SIP?" This is a reasonable question. The key + is that we use SIP for media session establishment. If we are using + SIP for media session establishment, then we need to ensure the URI + used for session establishment resolves to the same node as the node + for session control. Using the SIP routing mechanism, and having the + server initiate the TCP connection back, ensures this works. For + example, the URI 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. + + The use of SIP to negotiate the Control Channel provides many + inherent capabilities, which include: + + o Service location - Use SIP Proxies and Back-to-Back User Agents + for locating Control Servers. + + o Security mechanisms - Leverage established security mechanisms + such as Transport Layer Security (TLS) and Client Authentication. + + + +Boulton, et al. Standards Track [Page 6] + +RFC 6230 Media Control Channel Framework May 2011 + + + o Connection maintenance - The ability to re-negotiate a connection, + ensure it is active, and so forth. + + o Application agnostic - Generic protocol allows for easy extension. + + As mentioned in the previous list, one of the main benefits of using + SIP as the session control protocol is the "Service Location" + facilities provided. This applies both at a routing level, where + [RFC3263] provides the physical location of devices, and at the + service level, using Caller Preferences [RFC3840] and Callee + Capabilities [RFC3841]. The ability to select a Control Server based + on service-level capabilities is extremely powerful when considering + a distributed, clustered architecture containing varying services + (for example, voice, video, IM). More detail on locating Control + Server resources using these techniques is outlined in Section 4.1 of + this document. + + +--------------SIP Traffic--------------+ + | | + v v + +-----+ +--+--+ + | SIP | | SIP | + |Stack| |Stack| + +---+-----+---+ +---+-----+---+ + | Control | | Control | + | Client |<----Control Channel---->| Server | + +-------------+ +-------------+ + + Figure 1: Basic Architecture + + The example from Figure 1 conveys a 1:1 connection between the + Control Client and the Control Server. It is possible, if required, + for the client to request multiple Control Channels using separate + SIP INVITE dialogs between the Control Client and the Control Server + entities. Any of the connections created between the two entities + can then be used for Server control interactions. The control + connections are orthogonal to any given media session. Specific + media session information is incorporated in control interaction + commands, which themselves are defined in external packages, using + the XML schema defined in Appendix A. The ability to have multiple + Control Channels allows for stronger redundancy and the ability to + manage high volumes of traffic in busy systems. + + 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. + + + +Boulton, et al. Standards Track [Page 7] + +RFC 6230 Media Control Channel Framework May 2011 + + + The Client constructs and sends a standard SIP INVITE request, as + defined in [RFC3261], to the external Server. The Session + Description Protocol (SDP) payload includes the required information + for Control Channel negotiation and is the primary mechanism for + conveying support for this specification. The application/cfw MIME + type is defined in this document to convey the appropriate SDP format + for compliance to this specification. The Connection-Oriented Media + (COMEDIA) [RFC4145] specification for setting up and maintaining + reliable connections is used as part of the negotiation mechanism + (more detail available in later sections). The Client also includes + the 'cfw-id' SDP attribute, as defined in this specification, which + is a unique identifier used to correlate the underlying Media Control + Channel with the offer/answer exchange. + + Client Sends to External Server: + + INVITE sip:External-Server@example.com SIP/2.0 + To: <sip:External-Server@example.com> + From: <sip:Client@example.com>;tag=64823746 + Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d + Call-ID: 7823987HJHG6 + Max-Forwards: 70 + CSeq: 1 INVITE + Contact: <sip:Client@clientmachine.example.com> + Content-Type: application/sdp + Content-Length: [..] + + v=0 + o=originator 2890844526 2890842808 IN IP4 controller.example.com + s=- + c=IN IP4 controller.example.com + m=application 49153 TCP cfw + a=setup:active + a=connection:new + a=cfw-id:H839quwhjdhegvdga + + On receiving the INVITE request, an external Server supporting this + mechanism generates a 200 OK response containing appropriate SDP and + formatted using the application/cfw MIME type specified in this + document. The Server inserts its own unique 'cfw-id' SDP attribute, + which differs from the one received in the INVITE (offer). + + 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 + + + +Boulton, et al. Standards Track [Page 8] + +RFC 6230 Media Control Channel Framework May 2011 + + +Call-ID: 7823987HJHG6 +CSeq: 1 INVITE +Contact: <sip:External-Server@servermachine.example.com> +Content-Type: application/sdp +Content-Length: [..] + +v=0 +o=responder 2890844526 2890842808 IN IP4 server.example.com +s=- +c=IN IP4 mserver.example.com +m=application 7563 TCP cfw +a=setup:passive +a=connection:new +a=cfw-id:U8dh7UHDushsdu32uha + + The Control Client receives the SIP 200 OK response and extracts the + relevant information (also sending a SIP ACK). It creates an + outgoing (as specified by the SDP 'setup' attribute of 'active') TCP + connection to the Control Server. The connection address (taken from + 'c=') and port (taken from 'm=') are used to identify the remote port + in the new connection. + + Once established, the newly created connection can be used to + exchange requests and responses as defined in this document. If + required, after the Control Channel has been set up, media sessions + can be established using standard SIP Third Party Call Control (3PCC) + [RFC3725]. + + Figure 2 provides a simplified example where the framework is used to + control a User Agent's RTP session. + + +--------Control SIP Dialog(1)---------+ + | | + v v + +-----+ +--+--+ + +------(2)------>| SIP |---------------(2)------------->| SIP | + | |Stack| |Stack| + | +---+-----+---+ +---+-----+---+ + | | | | | + | | Control |<--Control Channel(1)-->| | + | | Client | | Control | + | +-------------+ | Server | + +--+--+ | | + |User | | | + |Agent|<=====================RTP(2)===================>| | + +-----+ +-------------+ + + Figure 2: Participant Architecture + + + +Boulton, et al. Standards Track [Page 9] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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]. + +4. Control Channel Setup + + This section describes the setup, using SIP, of the dedicated Control + Channel. Once the Control Channel has been established, commands can + be exchanged (as discussed in Section 6). + +4.1. Control Client SIP UAC Behavior + + 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]. + + If a reliable response is received (as defined in [RFC3261] and + [RFC3262]), the mechanisms defined in this document are applicable to + the newly created SIP INVITE dialog usage. + + The UAC SHOULD include a valid session description (an 'offer' as + defined in [RFC3264]) in an INVITE request using the Session + Description Protocol defined in [RFC4566] but MAY choose an offer- + less INVITE as per [RFC3261]. The SDP SHOULD be formatted in + accordance with the steps below and using the MIME type application/ + cfw, which is registered in Section 13. The following information + defines the composition of specific elements of the SDP payload the + offerer MUST adhere to when used in a SIP-based offer/answer exchange + using SDP and the application/cfw MIME type. The SDP being + constructed MUST contain only a single occurrence of a Control + Channel definition outlined in this specification but can contain + other media lines if required. + + The Connection Data line in the SDP payload is constructed as + specified in [RFC4566]: + + c=<nettype> <addrtype> <connection-address> + + The first sub-field, <nettype>, MUST equal the value "IN". The + second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The + third sub-field for Connection Data is <connection-address>. This + + + +Boulton, et al. Standards Track [Page 10] + +RFC 6230 Media Control Channel Framework May 2011 + + + supplies a representation of the SDP originator's address, for + example, DNS/IP representation. The address is the address used for + connections. + + Example: + + c=IN IP4 controller.example.com + + The SDP MUST contain a corresponding Media Description entry: + + 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". + + 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: + + a=setup:active + a=connection:new + + + + + +Boulton, et al. Standards Track [Page 11] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + + 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. + + 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". + + + +Boulton, et al. Standards Track [Page 12] + +RFC 6230 Media Control Channel Framework May 2011 + + + In this situation, the client will act as it would for any other + media type with a port set to "0". + +4.2. Control Server SIP UAS Behavior + + 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]. + + 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: + + 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. + + 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 + + + +Boulton, et al. Standards Track [Page 13] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + + 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. + +5. Establishing Media Streams - Control Client SIP UAC Behavior + + 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 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=). + + This framework identifies the referencing of such associated media + dialogs as extremely important. A connection reference attribute has + been specified that can optionally be imported into any Control + Package. It is intended that this will reduce the repetitive + specifying of dialog reference language. The schema can be found in + Appendix A.1. + + Similarly, the ability to identify and apply commands to a group of + associated media dialogs (multiparty) is also identified as a common + structure that could be defined and reused, for example, playing a + prompt to all participants in a Conference. The schema for such + operations can also be found in Appendix A.1. + + Support for both the common attributes described here is specified as + part of each Control Package definition, as detailed in Section 8. + + + + + + + + +Boulton, et al. Standards Track [Page 14] + +RFC 6230 Media Control Channel Framework May 2011 + + +6. Control Framework Interactions + + In this document, the use of the COMEDIA specification allows for a + Control Channel to be set up in either direction as a result of a SIP + INVITE transaction. SIP provides a flexible negotiation mechanism to + establish the Control Channel, but there needs to be a mechanism + within the Control Channel to correlate it with the SIP INVITE dialog + usage implemented for its establishment. A Control Client receiving + an incoming connection (whether it be acting in the role of UAC or + UAS) has no way of identifying the associated SIP INVITE dialog usage + as it could be simply listening for all incoming connections on a + specific port. The following steps, which implementations MUST + support, allow a connecting UA (that is, the UA with the active role + in COMEDIA) to identify the associated SIP INVITE dialog usage that + triggered the connection. Unless there is an alternative dialog + association mechanism used, the UAs MUST carry out these steps before + any other signaling on the newly created Control Channel. + + 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 The 'Dialog-ID' message header is populated with the value of the + local 'cfw-id' media-level attribute that was inserted by the same + client in the SDP offer/answer exchange to establish the Control + Channel. This allows for a correlation between the Control + Channel and its associated SIP INVITE dialog usage. + + o On creating the SYNC request, the active UA MUST follow the + procedures outlined in Section 6.3.3. This provides details of + connection keep-alive messages. + + o 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 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. + + + +Boulton, et al. Standards Track [Page 15] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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'. + + 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 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 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 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. + + SYNC messages can be sent at any point while the Control Channel is + open from either side, once the initial exchange is complete. If + present, the contents of the 'Keep-Alive' and 'Dialog-ID' headers + MUST NOT change. New values of the 'Keep-Alive' and 'Dialog-ID' + headers have no relevance as they are negotiated for the lifetime of + the Media Control Channel Framework session. + + Once a successful Control Channel has been established, as defined in + Sections 4.1 and 4.2, and the connection has been correlated, as + described in previous paragraphs, the two entities are now in a + position to exchange Control Framework messages. The following sub- + sections specify the general behavior for constructing Control + Framework requests and responses. Section 6.3 specifies the core + Control Framework methods and their transaction processing. + + + + + +Boulton, et al. Standards Track [Page 16] + +RFC 6230 Media Control Channel Framework May 2011 + + +6.1. General Behavior for Constructing Requests + + 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. + + Any Framework message that contains an associated payload MUST also + include the 'Content-Type' and 'Content-Length' message headers, + which indicate the MIME type of the payload specified by the + individual Control Framework packages and the size of the message + body represented as a whole decimal number of octets, respectively. + If no associated payload is to be added to the message, the 'Content- + Length' header MUST have a value of '0'. + + A Server receiving a Framework message request MUST respond with an + appropriate response (as defined in Section 6.2). Control Clients + MUST wait for a minimum of 2*'Transaction-Timeout' for a response + before considering the transaction a failure and tidying state + appropriately depending on the extension package being used. + +6.2. General Behavior for Constructing Responses + + 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 + + + + + +Boulton, et al. Standards Track [Page 17] + +RFC 6230 Media Control Channel Framework May 2011 + + + defined in Section 6.1. Responses MUST NOT include the 'Status' or + 'Timeout' message headers, and these MUST be ignored if received by a + Client in a response. + + A Control Server MUST include a status code in the first line of the + response. If there is no error, the Server responds with a 200 + Control Framework status code, as defined in Section 7.1. The 200 + response MAY include message bodies. If the response contains a + payload, the message MUST include the 'Content-Length' and 'Content- + Type' headers. When the Control Client receives a 2xx-class + response, the Control Command transaction is complete. + + 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. + + If a Control Server encounters problems with a Control Framework + request (like REPORT or CONTROL), an appropriate error code MUST be + used in the response, as listed in Section 7. The generation of a + non-2xx-class response code to a Control Framework request (like + CONTROL or REPORT) will indicate failure of the transaction, and all + associated transaction state and resources MUST be terminated. The + response code may provide an explicit indication of why the + transaction failed, which might result in a re-submission of the + request depending on the extension package being used. + +6.3. Transaction Processing + + The Control Framework defines four types of requests (methods): + CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support + sending and receiving these four methods. + + The following sub-sections specify each Control Framework method and + its associated transaction processing. + +6.3.1. CONTROL Transactions + + 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 + + + +Boulton, et al. Standards Track [Page 18] + +RFC 6230 Media Control Channel Framework May 2011 + + + message, as discussed in Section 6.1 and defined in Section 9. A + CONTROL message MAY contain a message body. The explicit Control + Command(s) of the message payload contained in a CONTROL message are + specified in separate Control Package specifications. Separate + Control Package specifications MUST conform to the format defined in + Section 8.4. A CONTROL message containing a payload MUST include a + 'Content-Type' header. The payload MUST be one of the payload types + defined by the Control Package. Individual packages MAY allow a + CONTROL message that does not contain a payload. This could in fact + be a valid message exchange within a specific package; if it's not, + an appropriate package-level error message MUST be generated. + +6.3.2. REPORT Transactions + + A 'REPORT' message is used by a Control Server when processing of a + CONTROL command extends beyond the 'Transaction-Timeout', as measured + from the Client. In this case, the Server returns a 202 response. + The Server returns status updates and the final results of the + command in subsequent REPORT messages. + + All REPORT messages MUST contain the same transaction ID in the + request start line that was present in the original CONTROL + transaction. This correlates extended transactions with the original + CONTROL transaction. A REPORT message containing a payload MUST + include the 'Content-Type' and 'Content-Length' headers indicating + the payload MIME type [RFC2045] defined by the Control Package and + the length of the payload, respectively. + +6.3.2.1. Reporting the Status of Extended Transactions + + On receiving a CONTROL message, a Control Server MUST respond within + 'Transaction-Timeout' with a status code for the request, as + specified in Section 6.2. If the processing of the command completes + within that time, a 200 response code MUST be sent. If the command + does not complete within that time, the response code 202 MUST be + sent indicating that the requested command is still being processed + and the CONTROL transaction is being extended. The REPORT method is + then used to update and terminate the status of the extended + transaction. The Control Server should not wait until the last + possible opportunity to make the decision of issuing a 202 response + code and should ensure that it has plenty of time for the response to + arrive at the Control Client. If it does not have time, transactions + will be terminated (timed out) at the Control Client before + completion. + + + + + + + +Boulton, et al. Standards Track [Page 19] + +RFC 6230 Media Control Channel Framework May 2011 + + + A Control Server issuing a 202 response MUST ensure the message + contains a 'Timeout' message header. This header MUST have a value + in seconds that is the amount of time the recipient of the 202 + message MUST wait before assuming that there has been a problem and + terminating the extended transaction and associated state. + + The initial REPORT message MUST contain a 'Seq' (Sequence) message + header with a value equal to '1'. Note: the 'Seq' numbers at both + Control Client and Control Server for Framework messages are + independent. + + All REPORT messages for an extended CONTROL transaction MUST contain + a 'Timeout' message header. This header will contain a value in + seconds that is the amount of time the recipient of the REPORT + message MUST wait before assuming that there has been a problem and + terminating the extended transaction and associated state. On + receiving a REPORT message with a 'Status' header of 'update', the + Control Client MUST reset the timer for the associated extended + CONTROL transaction to the indicated timeout period. If the timeout + period approaches and no intended REPORT messages have been + generated, the entity acting as a Control Framework UAS for the + interaction MUST generate a REPORT message containing, as defined in + this paragraph, a 'Status' header of 'update' with no associated + payload. Such a message acts as a timeout refresh and in no way + impacts the extended transaction because no message body or semantics + are permitted. It is RECOMMENDED that a minimum value of 10 and a + maximum value of 15 seconds be used for the value of the 'Timeout' + message header. It is also RECOMMENDED that a Control Server refresh + the timeout period of the CONTROL transaction at an interval that is + not too close to the expiry time. A value of 80% of the timeout + period could be used. For example, if the timeout period is 10 + seconds, the Server would refresh the transaction after 8 seconds. + + 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. + + + +Boulton, et al. Standards Track [Page 20] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + +6.3.3. K-ALIVE Transactions + + 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]. + + 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. + +6.3.3.1. Behavior for an Entity in an Active Role + + When in an active role, a K-ALIVE message MUST be generated before + the local keep-alive timer fires. An active entity is free to send + the K-ALIVE message whenever it chooses. It is RECOMMENDED for the + entity to issue a K-ALIVE message after 80% of the local keep-alive + timer. On receiving a 200 OK Control Framework message for the + + + +Boulton, et al. Standards Track [Page 21] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + +6.3.3.2. Behavior for an Entity in a Passive Role + + When acting as a passive entity, a K-ALIVE message must be received + before the local keep-alive timer fires. When a K-ALIVE request is + received, the passive entity MUST generate a 200 OK Control Framework + response and reset the local keep-alive timer. No other Control + Framework response is valid. If no K-ALIVE message is received (or a + transport level problem is detected by some other means) before the + local keep-alive timer fires, the passive entity MUST tear down the + SIP INVITE dialog and recover the associated Control Channel + resources. + +6.3.4. SYNC Transactions + + 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. + +6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction + + The initial SYNC request allows the timeout period for the Control + Channel keep-alive mechanism to be negotiated. The following rules + MUST be followed for the initial SYNC request: + + o If the Client initiating the SDP offer has a COMEDIA 'setup' + attribute equal to active, the 'Keep-Alive' header MUST be + included in the SYNC message generated by the offerer. The value + of the 'Keep-Alive' header SHOULD be in the range of 95 to 120 + seconds (this is consistent with SIP Outbound [RFC5626]). The + value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The + client that generated the SDP "Answer" (the passive client) MUST + copy the 'Keep-Alive' header into the 200 response to the SYNC + message with the same value. + + 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 + + + +Boulton, et al. Standards Track [Page 22] + +RFC 6230 Media Control Channel Framework May 2011 + + + 120 seconds. The client that generated the SDP offer (the passive + client) MUST copy the 'Keep-Alive' header into the 200 response to + the SYNC message with the same value. + + o 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 If the initial negotiated offer/answer results in a COMEDIA + 'setup' attribute equal to 'holdconn', the initial SYNC mechanism + will occur when the offer/answer exchange is updated and the + active/passive roles are resolved using COMEDIA. + + The previous steps ensure that the entity initiating the Control + Channel connection is always the one specifying the keep-alive + timeout period. It will always be the initiator of the connection + who generates the K-ALIVE messages. + + Once negotiated, the keep-alive timeout applies for the remainder of + the Control Framework session. Any subsequent SYNC messages + generated in the Control Channel do not impact the negotiated keep- + alive property of the session. The 'Keep-Alive' header MUST NOT be + included in subsequent SYNC messages, and if it is received, it MUST + be ignored. + +6.3.4.2. Package Negotiation + + As part of the SYNC message exchange, a client generating the request + MUST include a 'Packages' header, as defined in Section 9. The + 'Packages' header contains a list of all Control Framework packages + that can be supported within this control session, from the + perspective of the client creating the SYNC message. All Channel + Framework package names MUST be tokens that adhere to the rules set + out in Section 8. The 'Packages' header of the initial SYNC message + MUST contain at least one value. + + A server receiving the initial SYNC request MUST examine the contents + of the 'Packages' header. If the server supports at least one of the + packages listed in the request, it MUST respond with a 200 response + + + +Boulton, et al. Standards Track [Page 23] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + + 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]. + + Once the initial SYNC transaction is completed, either client MAY + choose to send a subsequent new SYNC message to re-negotiate the + packages that are supported within the Control Channel. A new SYNC + message whose 'Packages' header has different values from the + previous SYNC message can effectively add and delete the packages + used in the Control Channel. If a client receiving a subsequent SYNC + message does not wish to change the set of packages, it MUST respond + with a 421 Control Framework response code. Subsequent SYNC messages + MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control + Framework headers that appeared in the original SYNC negotiation. + + An entity MAY honor Control Framework commands relating to a Control + Package it no longer supports after package re-negotiation. When the + entity does not wish to honor such commands, it MUST respond to the + request with a 420 response. + +7. Response Code Descriptions + + The following response codes are defined for transaction responses to + methods defined in Section 6.1. All response codes in this section + MUST be supported and can be used in response to both CONTROL and + REPORT messages except that a 202 MUST NOT be generated in response + to a REPORT message. + + Note that these response codes apply to Framework Transactions only. + Success or error indications for Control Commands MUST be treated as + the result of a Control Command and returned in either a 200 response + or REPORT message. + + + + +Boulton, et al. Standards Track [Page 24] + +RFC 6230 Media Control Channel Framework May 2011 + + +7.1. 200 Response Code + + The framework protocol transaction completed successfully. + +7.2. 202 Response Code + + The framework protocol transaction completed successfully and + additional information will be provided at a later time through the + REPORT mechanism defined in Section 6.3.2. + +7.3. 400 Response Code + + The request was syntactically incorrect. + +7.4. 403 Response Code + + The server understood the request, but is refusing to fulfill it. + The client SHOULD NOT repeat the request. + +7.5. 405 Response Code + + Method not allowed. The primitive is not supported. + +7.6. 406 Response Code + + Message out of sequence. + +7.7. 420 Response Code + + Intended target of the request is for a Control Package that is not + valid for the current session. + +7.8. 421 Response Code + + Recipient does not wish to re-negotiate Control Packages at this + moment in time. + +7.9. 422 Response Code + + Recipient does not support any Control Packages listed in the SYNC + message. + +7.10. 423 Response Code + + Recipient has an existing transaction with the same transaction ID. + + + + + + +Boulton, et al. Standards Track [Page 25] + +RFC 6230 Media Control Channel Framework May 2011 + + +7.11. 481 Response Code + + 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. + +7.12. 500 Response Code + + The recipient does not understand the request. + +8. Control Packages + + Control Packages specify behavior that extends the capability defined + in this document. Control Packages MUST NOT weaken statements of + "MUST" and "SHOULD" strength in this document. A Control Package MAY + strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified + by the specific usage of the framework. + + In addition to the usual sections expected in Standards-Track RFCs + and SIP extension documents, authors of Control Packages need to + address each of the issues detailed in the following sub-sections. + The following sections MUST be used as a template and included + appropriately in all Control-Package specifications. To reiterate, + the following sections do not solely form the basis of all Control- + Package specifications but are included as a minimum to provide + essential package-level information. A Control-Package specification + can take any valid form it wishes as long as it includes at least the + following information listed in this section. + +8.1. Control Package Name + + This section MUST be present in all extensions to this document and + provides a token name for the Control Package. The section MUST + include information that appears in the IANA registration of the + token. Information on registering Control Package tokens is + contained in Section 13. + +8.2. Framework Message Usage + + 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. + + + + +Boulton, et al. Standards Track [Page 26] + +RFC 6230 Media Control Channel Framework May 2011 + + +8.3. Common XML Support + + 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]). + +8.4. CONTROL Message Bodies + + 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. + +8.5. REPORT Message Bodies + + 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. + +8.6. Audit + + 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. + + + + + +Boulton, et al. Standards Track [Page 27] + +RFC 6230 Media Control Channel Framework May 2011 + + + This section SHOULD include the following information: + + o If an auditing capability is available in this package. + + o How auditing information is triggered (for example, using a + Control Framework CONTROL message) and delivered (for example, in + a Control Framework 200 response). + + o The location of the audit query and response format for the + payload (for example, it could be a separate XML schema OR part of + a larger XML schema). + +8.7. Examples + + It is strongly RECOMMENDED that Control Packages provide a range of + message flows that represent common flows using the package and this + framework document. + +9. Formal Syntax + +9.1. Control Framework Formal Syntax + + The Control Framework interactions use the UTF-8 transformation + format as defined in [RFC3629]. The syntax in this section uses the + Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including + types 'DIGIT', 'CRLF', and 'ALPHA'. + + Unless otherwise stated in the definition of a particular header + field, field values, parameter names, and parameter values are not + case-sensitive. + + control-req-or-resp = control-request / control-response + control-request = control-req-start *headers CRLF [control-content] + control-response = control-resp-start *headers CRLF [control-content] + control-req-start = pCFW SP trans-id SP method CRLF + control-resp-start = pCFW SP trans-id SP status-code CRLF + + 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 + + + + +Boulton, et al. Standards Track [Page 28] + +RFC 6230 Media Control Channel Framework May 2011 + + + headers = header-name CRLF + + header-name = (Content-Length + /Content-Type + /Control-Package + /Status + /Seq + /Timeout + /Dialog-ID + /Packages + /Supported + /Keep-alive + /ext-header) + + Content-Length = "Content-Length:" SP 1*DIGIT + Control-Package = "Control-Package:" SP 1*alpha-num-token + Status = "Status:" SP ("update" / "terminate" ) + Timeout = "Timeout:" SP 1*DIGIT + Seq = "Seq:" SP 1*DIGIT + Dialog-ID = "Dialog-ID:" SP dialog-id-string + Packages = "Packages:" SP package-name *(COMMA package-name) + Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum) + Keep-alive = "Keep-Alive:" SP kalive-seconds + + dialog-id-string = alpha-num-token + package-name = alpha-num-token + supprtd-alphanum = alpha-num-token + kalive-seconds = 1*DIGIT + + alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char + alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/" + + control-content = *OCTET + + Content-Type = "Content-Type:" SP media-type + media-type = type "/" subtype *(SP ";" gen-param ) + type = token ; Section 4.2 of RFC 4288 + subtype = token ; Section 4.2 of RFC 4288 + + gen-param = pname [ "=" pval ] + pname = token + pval = token / quoted-string + + token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E + / %x30-39 / %x41-5A / %x5E-7E) + + + + + + +Boulton, et al. Standards Track [Page 29] + +RFC 6230 Media Control Channel Framework May 2011 + + + quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE + qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E + / UTF8-NONASCII + qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) + BACKSLASH = "\" + UPALPHA = %x41-5A + ALPHANUM = ALPHA / DIGIT + + ext-header = hname ":" SP hval CRLF + + hname = ALPHA *token + hval = utf8text + + utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) + + UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629 + + The following table details a summary of the headers that can be + contained in Control Framework interactions. + + Header field Where CONTROL REPORT SYNC K-ALIVE + ___________________________________________________________ + Content-Length o o - - + Control-Package R m - - - + Seq - m - - + Status R - m - - + Timeout R - m - - + Timeout 202 - m - - + Dialog-ID R - - m - + Packages - - m - + Supported r - - o - + Keep-Alive R - - o - + Content-Type o o - - + + Table 1: Summary of Headers in Control Framework Interactions + + The notation used in Table 1 is as follows: + + R: header field may only appear in requests. + r: header field may only appear in responses. + 2xx, 4xx, etc.: response codes with which the header field can be used. + [blank]: header field may appear in either requests or responses. + m: header field is mandatory. + o: header field is optional. + -: header field is not applicable (ignored if present). + + + + + + +Boulton, et al. Standards Track [Page 30] + +RFC 6230 Media Control Channel Framework May 2011 + + +9.2. Control Framework Dialog Identifier SDP Attribute + + This specification defines a new media-level value attribute: + 'cfw-id'. Its formatting in SDP is described by the following ABNF + [RFC5234]. + + cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF + + cfw-id-name = token + + token = 1*(token-char) + + token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 + / %x41-5A / %x5E-7E + + The token-char and token elements are defined in [RFC4566] but + included here to provide support for the implementer of this SDP + feature. + +10. Examples + + The following examples provide an abstracted flow of Control Channel + establishment and Control Framework message exchange. The SIP + signaling is prefixed with the token 'SIP'. All other messages are + Control Framework interactions defined in this document. + + 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. + + + + + + + + + + + + + + + + + + + +Boulton, et al. Standards Track [Page 31] + +RFC 6230 Media Control Channel Framework May 2011 + + + Control Client Control Server + | | + | (1) SIP INVITE | + | ----------------------------------------> | + | | + | (2) SIP 200 | + | <--------------------------------------- | + | | + | (3) SIP ACK | + | ----------------------------------------> | + | | + |==>=======================================>==| + | Control Channel Established | + |==>=======================================>==| + | | + | (4) SYNC | + | ----------------------------------------> | + | | + | (5) 200 | + | <--------------------------------------- | + | | + | (6) CONTROL | + | ----------------------------------------> | + | | + + (1) Control Client-->Control Server (SIP): INVITE + sip:control-server@example.com + + INVITE sip:control-server@example.com SIP/2.0 + To: <sip:control-server@example.com> + From: <sip:control-client@example.com>;tag=8937498 + Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123 + CSeq: 1 INVITE + Max-Forwards: 70 + Call-ID: 893jhoeihjr8392@example.com + Contact: <sip:control-client@pc1.example.com> + Content-Type: application/sdp + Content-Length: 206 + + v=0 + o=originator 2890844526 2890842808 IN IP4 controller.example.com + s=- + c=IN IP4 control-client.example.com + m=application 49153 TCP cfw + a=setup:active + a=connection:new + a=cfw-id:fndskuhHKsd783hjdla + + + + +Boulton, et al. Standards Track [Page 32] + +RFC 6230 Media Control Channel Framework May 2011 + + + (2) Control Server-->Control Client (SIP): 200 OK + +SIP/2.0 200 OK +To: <sip:control-server@example.com>;tag=023983774 +From: <sip:control-client@example.com>;tag=8937498 +Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5 +CSeq: 1 INVITE +Call-ID: 893jhoeihjr8392@example.com +Contact: <sip:control-server@pc2.example.com> +Content-Type: application/sdp +Content-Length: 203 + +v=0 +o=responder 2890844600 2890842900 IN IP4 controller.example.com +s=- +c=IN IP4 control-server.example.com +m=application 49153 TCP cfw +a=setup:passive +a=connection:new +a=cfw-id:7JeDi23i7eiysi32 + + (3) Control Client-->Control Server (SIP): ACK + + (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. + + CFW 8djae7khauj SYNC + Dialog-ID: fndskuhHKsd783hjdla + Keep-Alive: 100 + Packages: msc-ivr-basic/1.0 + + (5) Control Server-->Control Client (Control Framework message): + 200. + + 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. + + CFW i387yeiqyiq CONTROL + Control-Package: <package-name> + Content-Type: example_content/example_content + + + +Boulton, et al. Standards Track [Page 33] + +RFC 6230 Media Control Channel Framework May 2011 + + + Content-Length: 11 + + <XML BLOB/> + + (7) Control Server-->Control Client (Control Framework message): + 202. + + CFW i387yeiqyiq 202 + Timeout: 10 + + (8) Control Server-->Control Client (Control Framework message): + REPORT. + + CFW i387yeiqyiq REPORT + Seq: 1 + Status: update + Timeout: 10 + + (9) Control Client-->Control Server (Control Framework message): + 200. + + CFW i387yeiqyiq 200 + Seq: 1 + + (10) Control Server-->Control Client (Control Framework message): + REPORT. + + CFW i387yeiqyiq REPORT + Seq: 2 + Status: update + Timeout: 10 + Content-Type: example_content/example_content + Content-Length: 11 + + <XML BLOB/> + + (11) Control Client-->Control Server (Control Framework message): + 200. + + CFW i387yeiqyiq 200 + Seq: 2 + + (12) Control Server-->Control Client (Control Framework message): + REPORT. + + CFW i387yeiqyiq REPORT + Seq: 3 + Status: terminate + + + +Boulton, et al. Standards Track [Page 34] + +RFC 6230 Media Control Channel Framework May 2011 + + + Timeout: 10 + Content-Type: example_content/example_content + Content-Length: 11 + + <XML BLOB/> + + (13) Control Client-->Control Server (Control Framework message): + 200. + + CFW i387yeiqyiq 200 + Seq: 3 + + (14) Control Client-->Control Server (SIP): BYE + + BYE sip:control-server@pc2.example.com SIP/2.0 + To: <sip:control-server@example.com>;tag=023983774 + From: <sip:client@example.com>;tag=8937498 + Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234 + CSeq: 2 BYE + Max-Forwards: 70 + Call-ID: 893jhoeihjr8392@example.com + Contact: <sip:control-client@pc1.example.com> + Content-Length: 0 + + (15) Control Server-->Control Client (SIP): 200 OK + +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 + +11. Extensibility + + The Media Control Channel Framework was designed to be only minimally + extensible. New methods, header fields, and status codes can be + defined in Standards-Track RFCs. The Media Control Channel Framework + does not contain a version number or any negotiation mechanism to + require or discover new features. If an extension is specified in + the future that requires negotiation, the specification will need to + describe how the extension is to be negotiated in the encapsulating + signaling protocol. If a non-interoperable update or extension + occurs in the future, it will be treated as a new protocol, and it + MUST describe how its use will be signaled. + + + + +Boulton, et al. Standards Track [Page 35] + +RFC 6230 Media Control Channel Framework May 2011 + + + In order to allow extension header fields without breaking + interoperability, if a Media Control Channel device receives a + request or response containing a header field that it does not + understand, it MUST ignore the header field and process the request + or response as if the header field was not present. If a Media + Control Channel device receives a request with an unknown method, it + MUST return a 500 response. + +12. Security Considerations + + The Channel Framework provides confidentiality and integrity for the + messages it transfers. It also provides assurances that the + connected host is the host that it meant to connect to and that the + connection has not been hijacked, as discussed in the remainder of + this section. + + In design, the Channel Framework complies with the security-related + requirements documented in "Media Server Control Protocol + Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12, + REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by + the Channel Framework are summarized in the following sub-sections. + +12.1. Session Establishment + + 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. + +12.2. Transport-Level Protection + + When using only TCP connections, the Channel Framework security is + weak. Although the Channel Framework requires the ability to protect + this exchange, there is no guarantee that the protection will be used + all the time. If such protection is not used, anyone can see data + exchanges. + + Sensitive data, such as private and financial data, is carried over + the Control Framework channel. Clients and servers must be properly + authenticated/authorized and the Control Channel must permit the use + of confidentiality, replay protection, and integrity protection for + the data. To ensure Control Channel protection, Control Framework + clients and servers MUST support TLS and SHOULD use it by default + + + +Boulton, et al. Standards Track [Page 36] + +RFC 6230 Media Control Channel Framework May 2011 + + + unless alternative Control Channel protection is used or a protected + environment is guaranteed by the administrator of the network. + Alternative Control Channel protection MAY be used if desired (e.g., + IPsec [RFC5246]). + + TLS is used to authenticate devices and to provide integrity, replay + protection, and confidentiality for the header fields being + transported on the Control Channel. Channel Framework elements MUST + implement TLS and MUST also implement the TLS ClientExtendedHello + extended hello information for server name indication as described in + [RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA + [RFC3261] MUST be supported. Other cipher-suites MAY also be + supported. + + 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]. + + 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]. + +12.3. Control Channel Policy Management + + This specification permits the establishment of a dedicated Control + Channel using SIP. It is also permitted for entities to create + multiple channels for the purpose of failover and redundancy. As a + general solution, the ability for multiple entities to create + connections and have access to resources could be the cause of + potential conflict in shared environments. It should be noted that + this document does not carry any specific mechanism to overcome such + conflicts but will provide a summary of how to do so. + + It can be determined that access to resources and use of Control + Channels relate to policy. It can be considered implementation and + deployment detail that dictates the level of policy that is adopted. + The authorization and associated policy of a Control Channel can be + linked to the authentication mechanisms described in this section. + For example, strictly authenticating a Control Channel using TLS + authentication allows entities to protect resources and ensure the + required level of granularity. Such policy can be applied at the + package level or even as low as a structure like a conference + instance (Control Channel X is not permitted to issue commands for + Control Package y OR Control Channel A is not permitted to issue + commands for conference instance B). Systems should ensure that, if + + + +Boulton, et al. Standards Track [Page 37] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + +13. IANA Considerations + + 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. + + Additionally, Section 13.6 registers a new MIME type for use with + SDP. + + For all registries and sub-registries created by this document, the + policy applied when creating a new registration is also applied when + changing an existing registration. + +13.1. Control Packages Registration Information + + This specification establishes the Control Packages sub-registry + under Media Control Channel Framework Packages. New parameters in + this sub-registry must be published in an RFC (either in the IETF + stream or Independent Submission stream), using the IANA policy + [RFC5226] "RFC Required". + + As this document specifies no package or template-package names, the + initial IANA registration for Control Packages will be empty. The + remainder of the text in this section gives an example of the type of + information to be maintained by the IANA. + + + + + +Boulton, et al. Standards Track [Page 38] + +RFC 6230 Media Control Channel Framework May 2011 + + + The table below lists the Control Packages defined in the "Media + Control Channel Framework". + + Package Name Reference + ------------ --------- + example1 [RFCXXXX] + +13.1.1. Control Package Registration Template + + Package Name: + + (Package names must conform to the syntax described in + Section 8.1.) + + Published Specification(s): + + (Control Packages require an RFC.) + + Person & email address to contact for further information: + +13.2. Control Framework Method Names + + This specification establishes the Method Names sub-registry under + Media Control Channel Framework Parameters and initiates its + population as follows. New parameters in this sub-registry must be + published in an RFC (either in the IETF stream or Independent + Submission stream). + + + CONTROL - [RFC6230] + REPORT - [RFC6230] + SYNC - [RFC6230] + K-ALIVE - [RFC6230] + + The following information MUST be provided in an RFC in order to + register a new Control Framework method: + + o The method name. + + o The RFC number in which the method is registered. + +13.3. Control Framework Status Codes + + 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: + + + +Boulton, et al. Standards Track [Page 39] + +RFC 6230 Media Control Channel Framework May 2011 + + + Code Description Reference + + The following information MUST be provided in an RFC in order to + register a new Control Framework status code: + + o The status code number. + + o The RFC number in which the method is registered. + + o A brief description of the status code. + +13.4. Control Framework Header Fields + + This specification establishes the Header Field sub-registry under + Media Control Channel Framework Parameters. New parameters in this + sub-registry must be published in an RFC (either in the IETF stream + or Independent Submission stream). Its initial population is defined + as follows: + + Control-Package - [RFC6230] + Status - [RFC6230] + Seq - [RFC6230] + Timeout - [RFC6230] + Dialog-ID - [RFC6230] + Packages - [RFC6230] + Supported - [RFC6230] + Keep-Alive - [RFC6230] + Content-Type - [RFC6230] + Content-Length - [RFC6230] + + The following information MUST be provided in an RFC in order to + register a new Channel Framework header field: + + o The header field name. + + o The RFC number in which the method is registered. + +13.5. Control Framework Port + + The Control Framework uses TCP port 7563, from the "registered" port + range. Usage of this value is described in Section 4.1. + +13.6. Media Type Registrations + + 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]. + + + + +Boulton, et al. Standards Track [Page 40] + +RFC 6230 Media Control Channel Framework May 2011 + + +13.6.1. Registration of MIME Media Type application/cfw + + Type name: application + + Subtype name: cfw + + Required parameters: None + + Optional parameters: None + + Encoding considerations: Binary and see Section 4 of RFC 6230 + + Security considerations: See Section 12 of RFC 6230 + + Interoperability considerations: + Endpoints compliant to this specification must + use this MIME type. Receivers who cannot support + this specification will reject using appropriate + protocol mechanism. + + Published specification: RFC 6230 + + Applications that use this media type: + Applications compliant with Media Control Channels. + + Additional Information: + Magic number(s): (none) + File extension(s): (none) + Macintosh file type code(s): (none) + + Person & email address to contact for further information: + Chris Boulton <chris@ns-technologies.com> + + Intended usage: COMMON + + Restrictions on usage: + Should be used only in conjunction with this specification, + RFC 6230. + + Author: Chris Boulton + + Change controller: + IETF MEDIACTRL working group, delegated from the IESG. + + + + + + + + +Boulton, et al. Standards Track [Page 41] + +RFC 6230 Media Control Channel Framework May 2011 + + +13.6.2. Registration of MIME Media Type application/ + framework-attributes+xml + + Type name: application + + Subtype name: framework-attributes+xml + + Required parameters: (none) + + Optional parameters: Same as charset parameter of application/xml as + specified in RFC 3023 [RFC3023]. + + Encoding considerations: Same as encoding considerations of + application/xml as specified in RFC 3023 [RFC3023]. + + Security considerations: No known security considerations outside + of those provided by core Media Control Channel Framework. + + Interoperability considerations: This content type provides common + constructs for related Media Control Channel packages. + + Published specification: RFC 6230 + + Applications that use this media type: Implementations of + appropriate Media Control Channel packages. + + Additional information: + Magic number(s): (none) + File extension(s): (none) + Macintosh file type code(s): (none) + + Person & email address to contact for further information: + Chris Boulton <chris@ns-technologies.com> + + Intended usage: LIMITED USE + + Author/Change controller: The IETF + + Other information: None. + +13.7. 'cfw-id' SDP Attribute + + Contact name: Chris Boulton <chris@ns-technologies.com> + + Attribute name: "cfw-id". + + Type of attribute Media level. + + + + +Boulton, et al. Standards Track [Page 42] + +RFC 6230 Media Control Channel Framework May 2011 + + + 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. + + Allowed attribute values: A token. + +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]. + + URI: urn:ietf:params:xml:ns:control:framework-attributes + + Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, + Chris Boulton <chris@ns-technologies.com>. + + 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 + +13.9. XML Schema Registration + + This section registers an XML schema as per the guidelines in RFC + 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:control:framework-attributes + + + + + +Boulton, et al. Standards Track [Page 43] + +RFC 6230 Media Control Channel Framework May 2011 + + + Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>, + Chris Boulton <chris@ns-technologies.com>. + + Schema: The XML for this schema can be found in Appendix A.1 of this + document. + +14. Contributors + + Asher Shiratzky from Radvision provided valuable support and + contributions to the early versions of this document. + +15. Acknowledgments + + The authors would like to thank Ian Evans of Avaya, Michael + Bardzinski and John Dally of NS-Technologies, Adnan Saleem of + Radisys, and Dave Morgan for useful review and input to this work. + Eric Burger contributed to the early phases of this work. + + Expert review was also provided by Spencer Dawkins, Krishna Prasad + Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided + expert guidance on the dialog association mechanism. Lorenzo Miniero + has constantly provided excellent feedback based on his work. + + Ben Campbell carried out the RAI expert review on this document and + provided a great deal of invaluable input. Brian Weis carried out a + thorough security review. Jonathan Lennox carried out a thorough SDP + review that provided some excellent modifications. Text from Eric + Burger was used in the introduction in the explanation for using SIP. + +16. References + +16.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of + Provisional Responses in Session Initiation Protocol + (SIP)", RFC 3262, June 2002. + + + +Boulton, et al. Standards Track [Page 44] + +RFC 6230 Media Control Channel Framework May 2011 + + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + June 2002. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. + + [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) + UPDATE Method", RFC 3311, October 2002. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in + the Session Description Protocol (SDP)", RFC 4145, + September 2005. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4574] Levin, O. and G. Camarillo, "The Session Description + Protocol (SDP) Label Attribute", RFC 4574, August 2006. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, February 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + + + + +Boulton, et al. Standards Track [Page 45] + +RFC 6230 Media Control Channel Framework May 2011 + + + [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain + Certificates in the Session Initiation Protocol (SIP)", + RFC 5922, June 2010. + +16.2. Informative References + + [MSCL-THOUGHTS] + Burger, E., "Media Server Control Language and Protocol + Thoughts", Work in Progress, June 2006. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. + Camarillo, "Best Current Practices for Third Party Call + Control (3pcc) in the Session Initiation Protocol (SIP)", + BCP 85, RFC 3725, April 2004. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, August 2004. + + [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller + Preferences for the Session Initiation Protocol (SIP)", + RFC 3841, August 2004. + + [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", + RFC 5125, February 2008. + + [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol + Requirements", RFC 5167, March 2008. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + + + + + + + + + + + +Boulton, et al. Standards Track [Page 46] + +RFC 6230 Media Control Channel Framework May 2011 + + +Appendix A. Common Package Components + + During the creation of the Control Framework, it has become clear + that there are a number of components that are common across multiple + packages. It has become apparent that it would be useful to collect + such reusable components in a central location. In the short term, + this appendix provides the placeholder for the utilities, and it is + the intention that this section will eventually form the basis of an + initial 'Utilities Document' that can be used by Control Packages. + +A.1. Common Dialog/Multiparty Reference Schema + + The following schema provides some common attributes for allowing + Control Packages to apply specific commands to a particular SIP media + dialog (also referred to as "Connection") or conference. If used + within a Control Package, the Connection and multiparty attributes + will be imported and used appropriately to specifically identify + either a SIP dialog or a conference instance. If used within a + package, the value contained in the 'connectionid' attribute MUST be + constructed by concatenating the 'Local' and 'Remote' SIP dialog + identifier tags as defined in [RFC3261]. They MUST then be separated + using the ':' character. So the format would be: + + 'Local Dialog tag' + ':' + 'Remote Dialog tag' + + As an example, for an entity that has a SIP Local dialog identifier + of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the + 'connectionid' attribute for a Control Framework command would be: + + 7HDY839: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. + + 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. + + + +Boulton, et al. Standards Track [Page 47] + +RFC 6230 Media Control Channel Framework May 2011 + + + It should be noted that the values contained in both the + 'connectionid' and 'conferenceid' identifiers MUST be compared in a + case-sensitive manner. + + The full schema follows: + + <?xml version="1.0" encoding="UTF-8"?> + + <xsd:schema + targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" + xmlns:xsd="http://www.w3.org/2001/XMLSchema" + xmlns="urn:ietf:params:xml:ns::control:framework-attributes" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + + <xsd:attributeGroup name="framework-attributes"> + <xsd:annotation> + <xsd:documentation> + SIP Connection and Conf Identifiers + </xsd:documentation> + </xsd:annotation> + + <xsd:attribute name="connectionid" type="xsd:string"/> + + <xsd:attribute name="conferenceid" type="xsd:string"/> + + </xsd:attributeGroup> + </xsd:schema> + + + + + + + + + + + + + + + + + + + + + + + + +Boulton, et al. Standards Track [Page 48] + +RFC 6230 Media Control Channel Framework May 2011 + + +Authors' Addresses + + Chris Boulton + NS-Technologies + + EMail: chris@ns-technologies.com + + + Tim Melanchuk + Rainwillow + + EMail: timm@rainwillow.com + + + Scott McGlashan + Hewlett-Packard + Gustav III:s boulevard 36 + SE-16985 Stockholm, Sweden + + EMail: smcg.stds01@mcglashan.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Boulton, et al. Standards Track [Page 49] + |