Network Working Group C. Boulton Internet-Draft
AvayaNS-Technologies Expires: June 6,August 23, 2009 T. Melanchuk Rain Willow Communications S. McGlashan Hewlett-Packard December 3, 2008February 19, 2009 Media Control Channel Framework draft-ietf-mediactrl-sip-control-framework-08draft-ietf-mediactrl-sip-control-framework-09 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6,August 23, 2009. Copyright Notice Copyright (c) 2009 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. 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- locatedco-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 distributed, centralized conference system, as defined by the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 45 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 45 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 1011 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 1011 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 Behaviour for Constructing Requests . . . . . . . 17 6.2. General Behaviour for Constructing Responses . . . . . . 1718 6.3. Transaction Processing . . . . . . . . . . . . . . . . . 18 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . 24 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. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Control Package Name . . . . . . . . . . . . . . . . . . 26 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 27 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 27 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37 11.2. Transport Level Protection . . . . . . . . . . . . . . . 37 11.3. Control Channel Policy Management . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Control Packages Registration Information . . . . . . . . 38 12.1.1. Control Package Registration Template . . . . . . . . 39 12.2. Control Framework Method Names . . . . . . . . . . . . . 39 12.3. Control Framework Status Codes . . . . . . . . . . . . . 40 12.4. Control Framework Header Fields . . . . . . . . . . . . . 40 12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41 12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41 12.8. URN Sub-Namespace for urn:ietf:params:xml:ns:control:framework-attributes . . . 42 12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42 12.10. MIME Media Type Registration for 'application/framework-attributes+xml' . . . . . . . . . 43 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.1. Changes from 0708 Version . . . . . . . . . . . . . . . . . 43 13.2. Changes from 0607 Version . . . . . . . . . . . . . . . . . 44 13.3. Changes from 0506 Version . . . . . . . . . . . . . . . . . 44 13.4. Changes from 0405 Version . . . . . . . . . . . . . . . . . 44 13.5. Changes from 0304 Version . . . . . . . . . . . . . . . . . 44 13.6. Changes from 0203 Version . . . . . . . . . . . . . . . . . 44 13.7. Changes from 0102 Version . . . . . . . . . . . . . . . . . 45 13.8. Changes from 0001 Version . . . . . . . . . . . . . . . . . 45 14. Contributors13.9. Changes from 00 Version . . . . . . . . . . . . . . . . . 45 14. Contributors . . . . . . . . 45 15. Acknowledgments. . . . . . . . . . . . . . . . . 46 15. Acknowledgments . . . . . . . . . 46 16. Appendix A. . . . . . . . . . . . . . 46 16. Appendix: Common Package Components . . . . . . . . . . . . . 46 16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 17.1. Normative References . . . . . . . . . . . . . . . . . . 48 17.2. Informative References . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 511. 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 the 'Media Server Control Protocol Requirements' document[RFC5167]. While the Framework is not media server control specific, it is the primary driver and use case for this work. It is intended that the framework contained in this document can be used for a variety of device control scenarios (for example, conference control). This document does not define a particular SIP protocol drivenextension that can be used directlyfor the direct control of external components. The framework mechanism is extended byRather, other documents that aredocuments, known as "Control Packages". APackages," extend the control framework described by this document. Section 8 provides a comprehensive set of guidelines for creating "Control Packages" is described in Section 8.such Control Packages. Current IETF device control protocols, such as megaco [RFC3525], while excellent for controlling media gateways that bridge separate networks, are troublesome for supporting media-rich applications in SIP networks,networks. This is because they duplicatemegaco duplicates many of the functions inherent in SIP. Rather than relying onusing a single protocol for session establishment,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 In this document, BCP 14 [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In addition, BCP 15 indicates requirement levels for compliant implementations. 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,mixing; announcement; tone detection and generation,generation; and play and record services. The Control Server in this case,has a direct 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 maymight 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:Framework Transaction: A framework transactionFramework Transaction is defined as a sequence composed of a control framework message originated by either a Control Client or Control Server and responded to with a control Framework response code message. Note that the control framework has no "provisional" responses. A control framework transaction MUST complete within 5 seconds and is referenced throughout the draft as 'Transaction-Timeout'. extended transaction lifetime: An extended transaction lifetime is used to extend the lifetime ofTransaction-Timeout: The maximum allowed time between a CONTROL method transaction when theControl Command it carries cannot be completed within 'Transaction-Timeout'. A Server extends the lifetime of a CONTROL method transaction by sending a 202 response code followed by one or more REPORT transactions as specified in Section 6.3.2. Extended transaction lifetimes allow command failures to be discovered at the transaction layer. Transaction-Timeout: the maximum allowed time between a controlClient or Server issuing a framework message and receiving a corresponding response. The value for the timeout should be based on a multiple of the network RTT plus an appropriate number milliseconds to allow for message parsing and processing. The value for'Transaction-Timeout' is 5 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 [I-D.burger-mscl-thoughts], established the following. One might ask, "If all we are doing is establishing a TCP connection to control the media server, what do we need SIP for?" This is a reasonable question. The key is to be usingwe 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.comsip:myserver.example.com may resolve to sip: server21.farm12.northeast.example.net,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 forto negotiate the control-channel provides many inherent capabilities which include: o Service location - Use SIP Proxies orand Back-to-Back User Agents for discoveringlocating Control Servers. o Security mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication. 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 at both 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 dialogs to be establishedbetween 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 agnosticorthogonal to any given media sessions.session. Specific media session information can beare incorporated in control interaction commands (whichcommands, which themselves are defined in external packages)packages, using the XML schema defined in Section 16. 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. The Client constructs and sends a standard SIP INVITE request, as defined in [RFC3261], to the external Server. The SDP payload includes the required information for control channel negotiation and is the primary mechanism for conveying support for this specification (through the media type). The 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 willalso includeincludes the 'cfw-id' SDP attribute, as defined in this specificationspecification, which is 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=z9hG4bK72dhjsU Call-ID: 7823987HJHG6 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 7575 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. The 'cfw-id' SDP attribute is copied from the original 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=z9hG4bK72dhjsU Call-ID: 7823987HJHG6 CSeq: 1 INVITE Contact: <sip:External-Server@servermachine.example.com> Content-Type: application/sdp Content-Length: [..] v=0 o=originator 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:H839quwhjdhegvdga 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'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 setup, media sessions can be established using standard SIP third party call control. Figure 2 provides a simplified example where the framework is used to control a User Agent's RTP session. The link (1) in brackets represents the SIP dialog and dedicated control channel previously described in this overview section. +--------Control SIP Dialog(1)---------+ | | v v +-----+ +--+--+ +------(2)------>| SIP |---------------(2)------------->| SIP | | |Stack| |Stack| | +---+-----+---+ +---+-----+---+ | | | | | | | Control |<--Control Channel(1)-->| | | | Client | | Control | | +-------------+ | Server | +--+--+ | | |User | | | |Agent|<=====================RTP(2)===================>| | +-----+ +-------------+ Figure 2: Participant Architecture The link (2) from Figure 2 represents the User Agent SIP dialog interactions and associated media flow. A User Agent would createcreates a SIP dialog with the Control Client entity. The Control Client entity will also createthen creates a related dialog to the Control Server (B2BUAServer, using B2BUA type functionality).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 Third Party Call Control [RFC3725]. 4. Control Channel Setup This section describes the setup, using SIP, of the dedicated control.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, asetup. The UAC MUST construct the protocol messageINVITE request as defined in [RFC3261]. If a reliable response is received (as defined [RFC3261] and [RFC3262]), the mechanisms defined in this document are applicable to the newly created dialog. 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] (*note - SIP also allows an 'offer-less' INVITE which is also maintained by this specification).[RFC4566], unless the Control Client does not have the SDP of the far (non-Control Server) end of the session yet. The following information defines the composition of somespecific elements of the SDP payload thatthe Client MUST be adhered to for compliancyadhere to this specificationwhen used in an SIP SDP offer. 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 supplies a representation of the SDP originators address, for example dns/IP representation. The address will beis the networkaddress used for connections in this specification.connections. Example: c=IN IP4 controller.example.com The SDP MUST contain a corresponding Media Description entry for compliance to this specification:entry: m=<media> <port> <proto> 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 constructing client can't receive incoming connections it MUST still enter a valid port rangeentry. The use of the port value '0' has the same meaning as defined in the SDP specification[RFC4566].a SIP Offer/Answer exchange[RFC3264]. The Control Framework has an IANA-registered recommended port defined in Section 12.5. This value is not a default as a client is free to choose explicit port numbers. However, SDP SHOULD be configured so thatuse the recommendedregistered port is used whenever appropriate. This makes life easier fornumber, unless local policy prohibits its use. Using the registered port number allows network administrators who needto manage firewall policy for Control Framework interactions. The third sub-field, <proto>, MUST equal a transport value defined in Section 12.6. All implementations compliant to this specification MUST support the value "TCP/CFW", "TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in Section 12.6 of this document. 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. Control Framework implementations MAY support SCTP as a transport protocol. When an entity identifies one of the transport values defined in Section 12.6 but is not willing to establish the session, it MUST respond using the appropriate SIP mechanism. 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. A client conforming to this specification SHOULD support all the possible values defined for media attributes from the COMEDIA [RFC4145] specification but MAY choose not to support values if it can definitely determine they will never be used (for example will only everused. For example, the client may naver initiate outgoing connections).incoming connections and thus does not need to support the incoming connection 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 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 dialog 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 dialog. This attribute MUST containbe globally unique over space and time (using an appropriately random value of at least 64 bits of randomness thatappropriate algorithm) and will not clash with other offer/answer exchanges that will take place and is globally unique over space and time.place. The value chosen for the 'cfw-id' attribute MUST be used for the entire duration of the associated SIP dialog and not be changed during updates to the offer/answer exchange. This applies tospecifically 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 shouldMUST use the value of 'existing' in the 'connection' attribute (for example, a=connection: existing).a=connection:existing). If it has noted that a connection has failed and wants to re-establish,re-establish the connection, it usesMUST use 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 does notMUST NOT change. You areOne 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 dialog. A non-2xx class final SIP response (4xx, 5xx and 6xx) SIP responsereceived for the INVITE request indicates that no SIP dialog 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 likesuch 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 should indicateindicates 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. 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". 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 Sessions Description of the offer message and identifying support for the appropriate media type. 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], 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]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 illustrated below: 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 exactly copy the value which appeared in the initial offer. 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 externalExternal Server UAS entities. The newly established connection is now available to exchange control command primitives. The state of the SIP Dialog and the associated Control channel are now implicitly linked. If either party wishes to terminate a Control channel it simply issues a SIP termination request (for example a SIP BYE request, or appropriate response in an early dialog). The Control Channel therefore lives for the duration of the SIP dialog. If the SIP UAS does not support the extension defined in this document, as identified by the media contained in the Session Description, it should respond as detailed in [RFC3261] with a "SIP 488" response code. If multiple media descriptions exist it might choose to continue processing the request and mark the port field equal to "0".A SIP entityUAS receiving a SIP OPTIONS request MUST respond appropriately as defined in [RFC3261]. This involves providing information relating to supported SIP extensions and media types in a 200 OK response. For this extensionThe UAS MUST include the media types supported MUST be includedin the SIP 200 OK response in a SIP "Accept" header to indicate athe valid media type.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 dialogs (media dialogs) with the samegiven a given remote server. For example, to applythe Control Server might send a command to generate audio media (such as an announcement) on an RTP sessionstream between a User Agent and a Media Server. SIP 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 SHOULDMUST 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=). A Control Client constructing the SDP MAY choose not to include the media label SDP attribute if it does not require direct control on a per media stream basis.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 repetitive specifying of dialog reference language. The schema can be found in Section 16.1 in Appendix A. 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 re-used, for example playing a prompt to all participants in a Conference. The schema for such operations can also be found in Section 16.1 in Appendix A. Support for both the common attributes described here is specified as part of each Control Package definition, as detailed in Section 8. 6. Control Framework Interactions The use of the COMEDIA specification in this document 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 the control channel with the SIP dialog used 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 dialog 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 (defined asthat is, the UA with the 'active' role in COMEDIA)COMEDIA, to identify the associated SIP dialog that triggered the connection. These steps SHOULD be carriedUnless 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. An alternative dialog association mechanism MAY be specified in extensions to this document.o Once the connection has been established, the UA acting in the active role (active UA) to initiate the connection MUST immediately send a Control Framework SYNC request. The SYNC request MUST be constructed as defined in Section 9.1 and MUST contain the message header, 'Dialog-ID', which contains the SIP dialog information. o The 'Dialog-ID' message header value is the value contained in the 'cfw-id' SDP media level attribute. This allows for a correlation between the control channel and its associated SIP dialog. 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 18.104.22.168. 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 active UA MUST then send the SYNC request. It MUST then wait for a period of at least 'Transaction-Timeout' to receive a response. It MAY choose a longer time to wait but it MUST notNOT be shorter than 'Transaction-Timeout'. o If no response is received for the SYNC control message, a timeout occurs and the control channel is terminated along with the associated SIP dialog (issuedialog. The active UA MUST issue a BYE request).request to terminate the SIP dialog. o If the active UA receives a 481 response,response from the passive UA, this implies thatmeans the SYNC request was received but no associated SIP dialog exists. This also results in the control channel being terminated along withthe associated SIP dialog (issue a BYE request). o All other error responses received forspecified in the SYNC request are treatedmessage does not exists. The active client MUST terminate the control channel. The active UA MUST issue a SIPBYE request to terminate the SIP dialog. 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 dialog (issuedialog. The active UA MUST issue a BYE request).request to terminate the SIP dialog. o The receipt of a 200 response to a SYNC message implies that the SIP dialog 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"Keep-Alive and "Dialog-ID"Dialog-ID headers MUST notNOT change. New values of the "Keep-Alive"Keep-Alive and "Dialog-ID"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 Section 4.1 and Section 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 behaviour for constructing control framework requests and responses. Section 6.3 specifies the core Control Framework methods and their transaction processing. 6.1. General Behaviour 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:9. Note that either entity can act as a control client depending on individual package requirements).requirements. Control Commands MUST also adhere to the syntax defined by the Control Packages negotiated in Section 4.1 and Section 4.2 of this document. A Control Client MUST create a unique control message 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 (astype, as defined in the ABNF in Section 9).9. The first line starts with the "CFW" token for the purpose of easily extracting the transaction identifier. The transaction identifier MUST be globally unique over space and time with at least 64 bits of randomness.(using an appropriate algorithm). This unique property helps in the avoidance of 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 control message 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 control message discussed in Section 22.214.171.124. Any framework message that contains an associated payload MUST also include a 'Content-Type' and 'Content-Length' message header which representsis the size of the message body in decimal number of octets. The 'Content-Type' header representsis the MIME type of the payload to be used asspecified by the individual control framework packages. If no associated payload is to be added to the message, athe 'Content-Length' header withMUST have a value of '0' is considered the same as one not being present. When all of the headers have been included in the framework message, it is sent down the control channel.'0'. A Server receiving sucha framework message request needs toMUST respond quicklywith an appropriate response (as defined in Section 6.2). Control Clients MUST wait for a minimum of '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 Behaviour for Constructing Responses An entity acting as a Control Server, on receiving a request, MUST generate a response within the 'Transaction-Time'.'Transaction-Time', 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 first line of the request, as defined in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' message headers, and these MUST be ignored if received by a Client in a response. A Control Server MUST theninclude a status code in the first line of the constructedresponse. A Control Framework request (like CONTROL) that has been received, and either the actions specified by the request have completed or a control command errorIf there is detected, usesno error, the Server responds with a 200 Control Framework status codecode, as defined in Section 7.1 in the response. A7.1. The 200 response MAY include message bodies. If a 200the response does containcontains a payload itpayload, the message MUST include the Content-Length and Content-Type headers. A 200 is the only response defined in this specification that allows a message body to be included. The 'Content-Type' header represents the MIME payload to be used as specified byWhen the individual control framework packages. A client receivingControl Client receives a 200 class response then considers200-class response, the control command transaction completed. Ais complete. If the Control Framework request (like CONTROL)Server receives a request, like CONTROL, that is received and understoodthe Server understands, but requiresthe Server knows processing that extends beyond 'Transaction-Timeout'the command will result in a 202exceed the Transaction-Timeout, then the Server MUST respond with a 202 status code in the first line of the response. ThisFollowing the initial response, the server will be followed bysend one or more REPORT messages as defineddescribed in Section 6.3.2. A Control Package SHOULDMUST explicitly define the circumstances under which eitherthe server sends 200 orand 202 with subsequent processing takes place.messages. If a Control Server encounters problems with a Control Framework request (like REPORT or CONTROL), an appropriate error code shouldMUST 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 state and resources shouldMUST 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 allthese four methods. Future extensions to this document MAY define new methods and responses.The following sub-sections specify each Control Framework method and its associated transaction processing. 6.3.1. CONTROL Transactions A 'CONTROL'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'CONTROL message which is permitted to be sent in either direction between two participants in a session, carrying the appropriate payload for an event. The message is constructed in the same way as any standard Control Framework message, as discussed previously 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. TheseSeparate 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 indicatingContent-Type header. The payload MUST be one of the payload typetypes defined by the control package. AIndividual packages MAY allow a CONTROL message that does not contain a payload should be dealt with in the individual package.payload. This could in fact be a valid message exchange within a specific package and if not an appropriate package levelpackage-level error message shouldMUST be generated. 6.3.2. REPORT Transactions A 'REPORT' message is used by a Control Server when processing of a CONTROL Command extends beyond a 'Transaction-Timeout'.the Transaction-Timeout, as measured from the Client. In this case the Server returns a 202 response is returned. Statusresponse. The Server returns status updates and the final results of the command are then returnedin 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 allowscorrelates extended transactions to be correlatedwith the original CONTROL transaction. A REPORT message containing a payload MUST include a 'Content-Lengththe Content-Type and 'Content-Type' headerContent-Length headers indicating the payload MIME[RFC2045]MIME type [RFC2045] defined by the control package and its length.the length of the payload, respectively. 126.96.36.199. Reporting the Status of Extended Transactions On receiving a CONTROL message, a Control Server MUST respond within 'Transaction-Timeout'Transaction-Timeout with a status code for the request, as specified in Section 6.2. If the command completedcompletes within that time, a 200 response code would have beenMUST be sent. If the command diddoes not complete within that time, the response code 202 would have beenMUST 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. A Control Server issuing a 202 response MUST contain a 'Timeout'Timeout message header. This header will containMUST have a value in seconds that representsis 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 (no corresponding REPORT message arrived).state. The initial REPORT message MUST contain a 'Seq' (Sequence) message header with a value equal to '1' (It should be noted that'1'. Note - the 'Seq' numbers at both Control Client and Control Server for framework messages are independent).independent. All REPORT messages for an extended CONTROL transaction MUST contain a 'Timeout' message header. This header will contain a value in seconds that representsis 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 with no intended REPORT messages being 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 aused. For example, if the timeout period ofis 10 secondsseconds, the Server would be refreshedrefresh 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. They 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 9.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. 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. 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 will includeincludes 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 (NAT) and Firewalls. A keep alivekeep-alive mechanism enables the control channel to be kept active during times of inactivity (for example, mostinactivity. This is because many Firewalls have a timeout period after which connections are closed).closed. This mechanism also provides the ability for application level failure detection. It should be noted that the following procedures apply explicitly to the control channel being created. For details relating to athe SIP keep alive mechanism, implementers should seek guidance from SIP Outbound [I-D.ietf-sip-outbound]. The following keep alivekeep-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 in-activity.inactivity. Once the SIP dialog has been established and the underlying control channel has been set-up (includingset-up, including the initial correlation handshake using SYNC as discussed in Section 6),6, both entities acting in the 'active' and 'passive' roles (asroles, as defined in COMEDIA [RFC4145])[RFC4145], MUST start a keep alive timer equal to the value negotiated during the control channel SYNC request/response exchange (theexchange. This is the value from the 'Keep-Alive' header in seconds).seconds. 188.8.131.52. Behaviour for an Entity in an Active Role When acting in an 'active'active role, a 'K-ALIVE'K-ALIVE Control Framework message MUST be generated before the local keep alive timer fires. An active entity is free to send the K-ALIVE Control Framework message whenever it chooses. A guideline ofIt is recommended for the entity to issue a K-ALIVE message after 80% of the local keep alive timer is suggested.keep-alive timer. On receiving a 200 OK Control Framework message for the K-ALIVE request, the 'active' entity MUST reset the local keep alive timer. If no 200 OK response is received to the K-ALIVE Control Framework message (ormessage, or a transport level problem is detected by some other means)means, before the local keep alive timer fires, the 'active' entity SHOULDMAY use COMEDIA renegotiation procedures to recover the connection. Otherwise, the 'active' entity MUST tear down the SIP dialog and recover the associated control channel resources. The 'active' entity MAY choose to try and recover the connection by renegotiation using COMEDIA.184.108.40.206. Behaviour for an Entity in ana Passive Role When acting as a 'passive'passive entity, a 'K-ALIVE'K-ALIVE Control Framework 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.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 SHOULDMUST tear down the SIP dialog and recover the associated control channel resources. The 'active' entity MAY try to and recover the connection by renegotiating using COMEDIA.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. 220.127.116.11. 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 SHOULDMUST be followed for the initial SYNC request: o If the Client initiating the SDP "Offer"Offer has a COMEDIA 'setup'setup attribute equal to 'active',active, the 'Keep-Alive'Keep-Alive header MUST be included in the SYNC message generated by the offerer. The value of the 'Keep-Alive'Keep-Alive header SHOULD be in the range of 95 andto 120 seconds (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]). The client that generated the SDP "Answer" ('passive'(the passive client) MUST copy the 'Keep-Alive'Keep-Alive header into the 200 response to the SYNC message with the same value. o If the Client initiating the SDP "Offer"Offer has a COMEDIA 'setup'setup attribute equal to 'passive',passive, the 'Keep-Alive'Keep-Alive header parameter MUST be included in the SYNC message generated by the answerer. The value of the 'Keep-Alive'Keep-Alive header SHOULD be in the range of 95 andto 120 seconds. The client that generated the SDP "Offer" ('passive'Offer (the passive client) MUST copy the 'Keep-Alive'Keep-Alive header into the 200 response to the SYNC message with the same value. o If the Client initiating the SDP "Offer"Offer has a COMEDIA 'setup'setup attribute equal to 'actpass',actpass, the 'Keep-Alive'Keep-Alive header parameter MUST be included in the SYNC message of the entity who is the 'Active'active participant in the SDP session. If the client generating the subsequent SDP 'Answer'answer places a value of 'active'active in the COMEDIA SDP 'setup'setup attribute, it will generate the SYNC request and include the 'Keep-Alive'Keep-Alive header. The value SHOULD be in the range 95 to 120 seconds. If the client generating the subsequent SDP 'Answer'answer places a value of 'passive'passive in the COMDEDIA 'setup'setup attribute, the original 'Offerer'UA making the SDP will generate the SYNC request and include the 'Keep-Alive'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'setup attribute equal to 'holdconn',holdconn, the initial SYNC mechanism will occur when the offer/answer exchange is updated and active/ passiveactive/passive roles are delegatedresolved using COMEDIA. The previous steps ensures 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'K-ALIVE Control Framework level messages. Once negotiated, the keep alivekeep-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"Keep-Alive header MUST NOT be included in subsequent SYNC messages and if it is received it MUST be ignored. 18.104.22.168. Package Negotiation As part of the SYNC message exchange a client generating the request MUST include a "Packages"Packages header, as defined in Section 9. The "Packages"Packages header will containcontains a list of all Control Framework packages that can be supported within this control session (fromsession, from the perspective of the client creating the SYNC message).message. All tokens MUST beChannel Framework packagespackage names MUST be tokens that adhere to the rules set out in Section 8. The "Packages"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"Packages header. If the server supports at least one of the packages listed in the request, it MUST respond with a 200 response code. The response MUST contain a "Packages"Packages header that lists the supported packages that are in common with those from the "Packages"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"Packages header of the SYNC request, MAY be placed in the "Supported"Supported header of the response. This provides a hint to the client that generated the SYNC request of theadditional 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"Supported header indicating the packages that are supported. The initiating client can then choose to either re-submitre- submit a new SYNC message based on the 422 response or consider the interaction as a failure. This would lead to termination of the associated SIP 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 Control Framework 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"Dialog-ID and "Keep-Alive"Keep-Alive Control Framework headers that appeared in the original SYNC negotiation. AnyAn entity MAY honor Control Framework commands relating to a Control Package that isit no longer supported by the session which are receivedsupports after package re-negotiation SHOULD be responded to with a 420 response. Anre-negotiation. When the entity MAY choosedoes not wish to honor such commands forcommands, it MUST respond to the request with a limited period of time but this is implementation specific.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 transactionsFramework Transactions only. Success or error indications for control commands MUST be treated as the result of a control command and returned in either a 200 response or REPORT message. 7.1. 200 Response Code The 200 response code indicates the completion of a successful framework protocol transaction. 7.2. 202 Response Code The 202 response code indicates the completion of a successful framework protocol transaction with additional information to be provided at a later time through the REPORT mechanism defined in Section 6.3.2. 7.3. 400 Response Code The 400 response code indicates that the request was syntactically incorrect. 7.4. 403 Response Code The server understood the request, but is refusing to fulfill it. The request SHOULD NOT be repeated.client should not repeat the request. 7.5. 405 Response Code Method not allowed. The primitive is not supported. 7.6. 420 Response Code Intended target of the request is for a Control Package that is not valid for the current session. 7.7. 421 Response Code Recipient does not wish to re-negotiate Control Packages at this moment in time. 7.8. 422 Response Code Recipient does not support any Control Packages listed in the SYNC message. 7.9. 423 Response Code Recipient has an existing transaction with the same transaction ID. 7.10. 481 Response Code The 481 response indicates that the transaction of the request does not exist. In response to a SYNC request, it indicates that the corresponding SIP dialog does not exist. 7.11. 500 Response Code The 500 response indicates that the recipient does not understand the request 8. Control Packages "Control Packages" are intended toControl Packages specify behavior that extends the thecapability defined in this document. "Control Packages" are not allowed toControl Packages MUST NOT weaken "MUST"MUST and "SHOULD"SHOULD strength statements that are detailedin this document. A "Control Package"Control Package MAY strengthen "SHOULD""SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified by the specific usage of the framework. In addition to normalthe usual sections expected in a standards-track RFC and SIP extension documents, authors of "Control Packages"Control Packages need to address each of the issues detailed in the following subsections. The following sections MUST be used as a template and included appropriately in all Control-Packages. To reiterate, the following sections do not solely form the basis of all Control-Package structure but are included as a minimum to provide essential package level information. A Control-Package can take any valid form it wishes as long as it includes at least the following sections are additionally included.following. 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 12. The package name MUST also register a version number for the package which is separated with a '/' symbol e.g. package_name/1.0. This enables updates to the package to be registered where appropriate. An initial version of a package MUST start with the value '1.0'. Subsequent versions MUST increment this number if the same package name is to be used. The exact increment is left to the discretion of the package author. It is RECOMMENDED that package authors make a clear statement on backwards compatibility with any new version. 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 shouldMUST explicitly detail the control messages that can be used as well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type. 8.3. Common XML Support 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 Section 16.1 in Appendix A. The Control Package will make strong statements (using language from RFC 2119 [RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is to be supported. If only part of the schema is required (for example just 'connectionid' or just conferenceid), the Control Package will make equally strong (using language from RFC 2119 [RFC2119]) statements. 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 (or6, or that no control package body is required).required. This section shouldMUST 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, stating such 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 (or6, or that no report package body is required).required. This section shouldMUST 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. 8.6. Audit Auditing of various control package propertiesFor 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 (meta package level information) is extremely useful. Such meta-data usually has no direct impact on control framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information. This section should include information including: o If an auditing capability is available in this package. o How auditing information is triggered (for example, using 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 [RFC2234].[RFC5234]. 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 transact-id SP method CRLF control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF comment = utf8text pCFW = %x43.46.57; CFW in caps transact-id = alpha-num-token method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mREPORT = %x22.214.171.124F.52.54; REPORT in caps mSYNC = %x53.59.4E.43; SYNC in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps other-method = 1*UPALPHA status-code = 3*DIGIT ; any code defined in this and other documents headers = header-name CRLF header-name = (Content-Length /Content-Type /Control-Package /Status /Seq /Timeout /Dialog-id /Packages /Supported /Keep-alive /ext-header) CRLFContent-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 supported-alphanum *(COMMA supported-alphanum) Keep-alive = "Keep-Alive:" SP kalive-seconds dialog-id-string = alpha-num-token package-name = alpha-num-token supported-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 *( ";" gen-param ) type = token subtype = token gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E) ; token is compared case-insensitive 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) UPALPHA = %x41-5A UTF8-NONASCII = %xC0-DF UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-FB 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF The following table details a summary of the headers that can be contained in Control Framework interactions. The "where" columns details where headers can be used: R: header field may only appear in requests; r: header field may only appear in responses; Blank indicates the header field may appear in either requests or responses. 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; An empty entry in the "where" column indicates that the header field may be present in all requests and responses. The remaining columns list the specified methods and the presence of a specific header: m: The header field is mandatory. o: The header field is optional. -: The header field is not applicable (ignored if present). 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 - - Figure 3: Table 1 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 dialog is then terminated. Control Client Control Server | | | (1) SIP INVITE | | ----------------------------------------> | | | | (2) SIP 200 | | <--------------------------------------- | | | | (3) SIP ACK | | ----------------------------------------> | | | |==>=======================================>==| | Control Channel Established | |==>=======================================>==| | | | (4) SYNC | | ----------------------------------------> | | | | (5) 200 | | <--------------------------------------- | | | | (6) CONTROL | | ----------------------------------------> | | | | (7) 202 | | <--------------------------------------- | | | | (8) REPORT (update) | | <---------------------------------------- | | | | (9) 200 | | ----------------------------------------> | | | | (10) REPORT (update) | | <---------------------------------------- | | | | (11) 200 | | ----------------------------------------> | | | | (12) REPORT (terminate) | | <---------------------------------------- | | | | (13) 200 | | ----------------------------------------> | | | | (14) SIP BYE | | ----------------------------------------> | | | | (15) SIP 200 | | <--------------------------------------- | |=============================================| | Control Channel Terminated | |=============================================| | | 1. Control Client->Control Server (SIP): INVITE sip:email@example.com INVITE sip:firstname.lastname@example.org SIP/2.0 To: <sip:email@example.com> From: <sip:firstname.lastname@example.org>;tag=8937498 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 CSeq: 1 INVITE Call-ID: email@example.com Contact: <sip:firstname.lastname@example.org> Content-Type: application/sdp Cotent-Length: [..] v=0 o=originator 2890844526 2890842808 IN IP4 controller.example,com s=- c=IN IP4 control-client.example.com m=application 7575 TCP/CFW * a=setup:active a=connection:new a=cfw-id:fndskuhHKsd783hjdla 2. Control Server->Control Client (SIP): 200 OK SIP/2.0 200 OK To: <sip:email@example.com>;tag=023983774 From: <sip:firstname.lastname@example.org>;tag=8937498 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 CSeq: 1 INVITE Call-ID: email@example.com Contact: <sip:firstname.lastname@example.org> Content-Type: application/sdp Content-Length: [..] v=0 o=originator 2890844526 2890842808 IN IP4 controller.example,com s=- c=IN IP4 control-server.example.com m=application 7575 TCP/CFW * a=setup:passive a=connection:new a=cfw-id:fndskuhHKsd783hjdla 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 K-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 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 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:email@example.com SIP/2.0 To: <sip:firstname.lastname@example.org> From: <sip:email@example.com>;tag=8937498 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 CSeq: 2 BYE Call-ID: firstname.lastname@example.org 15. Control Server->Control Client (SIP): 200 OK SIP/2.0 200 OK To: <sip:email@example.com>;tag=023983774 From: <sip:firstname.lastname@example.org>;tag=8937498 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 CSeq: 2 BYE Call-ID: email@example.com 11. 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. The Channel Framework in design complies with the security-related requirements documented in the control protocol requirements document[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 subsections. 11.1. Session Establishment Channel Framework sessions are established as media sessions described by SDP within the context of a SIP 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 the SIP protocol. 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[RFC4346]TLS[RFC5246] and SMIME[RFC3851], when deployed in open networks. 11.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 for the data. To ensure control channel protection, Control Framework clients and servers MUST support TLS and SHOULD use it by default unless alternative control channel protection is used or a protected environment is guaranteed by the deployeradministrator of the network. Alternative control channel protection MAY be used if desired (e.g.IPSEC).(e.g.IPsec). 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 [RFC4366].[RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other cipher-suites MAY also be supported. 11.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 specifically carry any specific mechanism to overcome such conflicts but will provide a summary of how it can be achieved. It can be determined that access to resources and use of control channels relates 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 either using SIP digest or TLS authentication allows entities to protect resources and ensure the required level of granularity. Such policy can be applied at the package level or even as low as a structure like a conference instance (control channel X is not permitted to issue commands for control package y OR control channel A is not permitted to issue commands for conference instance B). Systems should ensure that if required, an appropriate policy framework is adopted to satisfy the requirements for implemented packages. The most robust form of policy can be achieved using a strong authentication mechanism such as mutual TLS authentication on the control channel. This specification provide a control channel response code(403) to indicate to the issuer of a command that it is not permitted. 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. 12. IANA Considerations This specification instructs IANA to create a new registry for SIP Control Framework parameters. The Channel Framework Parameter registry is a container for sub-registries. This section further introduces sub-registries for Channel Framework packages, method names, status codes, header field names, port and transport protocol. Additionally, Section 12.6 registers new parameters in existing IANA registries. 12.1. Control Packages Registration Information This specification establishes the Control Packages sub-registry under Control Framework Packages. New parameters in this sub- registry must be published in an RFC (either as an IETF submission or RFC Editor submission), 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; it also demonstrates all three possible permutations of package type, contact, and reference. The table below lists the control packages defined in the "Media Control Channel Framework". Package Name Contact Reference ------------ ------- --------- example1 [Boulton] example2 [Boulton] [RFCXXX] example3 [RFCXXX] 12.1.1. Control Package Registration Template To: firstname.lastname@example.org Subject: Registration of new Channel Framework package Package Name: (Package names must conform to the syntax described in section 8.1.) Published Specification(s): (Control packages require a published RFC.). Person & email address to contact for further information: 12.2. Control Framework Method Names This specification establishes the Methods sub-registry under Control Framework Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). CONTROL - [RFCXXX] REPORT - [RFCXXX] SYNC - [RFCXXX] The following information MUST be provided in an RFC publication in o The method name. o The RFC number in which the method is registered. 12.3. Control Framework Status Codes This specification establishes the Status-Code sub-registry under Channel Framework Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined in Section 9. It takes the following format: Code [RFC Number] The following information MUST be provided in an RFC publication 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. 12.4. Control Framework Header Fields This specification establishes the header field-Field sub-registry under Channel Framework Parameters. New parameters in this sub- registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined as follows: Control-Package - [RFCXXXX] Status - [RFCXXXX] Seq - [RFCXXXX] Timeout - [RFCXXXX] Dialog-id - [RFCXXXX] Packages - [RFCXXXX] Supported - [RFCXXXX] Keep-Alive - [RFCXXXX] Content-Type - [RFCXXXX] Content-Length - [RFCXXXX] The following information MUST be provided in an RFC publication 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. 12.5. Control Framework Port The Control Framework uses TCP port XXXX, from the "registered" port range. Usage of this value is described in Section 4.1. 12.6. SDP Transport Protocol The Channel Framework defines the new SDP protocol field values 'TCP/ CFW', 'TCP/TLS/CFW', 'SCTP/CFW' and 'SCTP/TLS/CFW", which should be registered in the sdp-parameters registry under "proto". The values have the following meaning: o TCP/CFW: Indicates the SIP Channel Framework when TCP is used as an underlying transport for the control channel. o TCP/TLS/CFW: Indicates the Channel Framework when TLS over TCP is used as an underlying transport for the control channel. o SCTP/CFW: Indicates the Channel Framework when SCTP is used as an underlying transport for the control channel. o SCTP/TLS/CFW: Indicates the Channel Framework when TLS over SCTP is used as an underlying transport for the control channel. Specifications defining new protocol values must define the rules for the associated media format namespace. The 'TCP/CFW', 'TCP/TLS/CFW', 'SCTP/CFW' and 'SCTP/TLS/CFW' protocol values allow only one value in the format field (fmt), which is a single occurrence of "*". Actual format determination is made using the control package extension specific payloads. 12.7. 'cfw-id' SDP Attribute Contact name: Chris Boulton email@example.com. Attribute name: "cfw-id". Type of attribute Media level. Subject to charset: Not. Purpose of attribute: The 'cfw-id' attribute indicates an identifier that can be used to correlate the control channel with the SIP dialog used to negotiate it, when the attribute value is used within the control channel. Allowed attribute values: A token. 12.8. URN Sub-Namespace for urn:ietf:params:xml:ns:control:framework-attributes This section registers 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, (firstname.lastname@example.org), Chris Boulton (email@example.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> [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] <p>See RFCXXXX</p> </body> </html> END 12.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 Registrant Contact: IETF, MEDIACTRL working group, (firstname.lastname@example.org), Chris Boulton (email@example.com). Schema: The XML for this schema can be found as the entirety of Section 16 of this document. 12.10. MIME Media Type Registration for 'application/ framework-attributes+xml' This section registers the "application/framework-attributes+xml" MIME type. To: firstname.lastname@example.org Subject: Registration of MIME media type application/framework-attributes+xml MIME media type name: application MIME subtype name: framework-attributes+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], section 3.2. 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 XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Applications which use this media type: Implementations of appropriate Media Control Channel packages. Additional Information: Magic Number(s): (none) File extension(s): .xml Macintosh File Type Code(s): (none) Person & email address to contact for further information: Chris Boulton <email@example.com> Intended usage: LIMITED USE Author/Change controller: The IETF Other information: None. 13. Changes Note to RFC Editor: Please remove this whole section. 13.1. Changes from 08 Version o Altered definition of 'Transaction-Timeout'. o Removed 'random' reference in preference for globally unique. o Clarified passive entity behavior on Keep-Alive timeout. o Input of Chair comments for final publication. o Removed extra CRLF in ABNF after 'headers'. o Clarified 481 behavior. o Removed definition for extended transaction lifetime 13.2. Changes from 07 Version o Added '*' to SDP 'm=' line in examples. 126.96.36.199. Changes from 06 Version o Added 202 Timeout entry to table. o Fixed some general nits and language. o Fixed ABNF to be 'control-content = *OCTET'. o Added general qualifier to sections 188.8.131.52 and 184.108.40.206 so that rules for either tearing down or reconnecting are applied. 220.127.116.11. Changes from 05 Version o Reworded 'must' used in Introduction. o Added urn namespace definition in IANA section. o Added XML schema registration in IANA section. o Added MIME registration in IANA section. 18.104.22.168. Changes from 04 Version o Fixed nits as reported by Brian Weis. o Amended Security text as per secdir review. o Removed optional 'label' part of dialog identifier as per interim call. o Added clarifying text at the beginning of section 4 to help describe what the section is about. o Added text at the beginning of section 8 clarifying that the template is not the basis for packages BUT only needs to be included as part of a Control Package. 22.214.171.124. Changes from 03 Version o Removed comment from XML schema in appendix. o Changed dialog-id-string in section 9.1 to be dialog-id-string = alpha-num-token. o Changed status-code in section 9.1 to status-code = 3*DIGIT o Aligned use of Keep-Alive header terms in document. o Added text to clarify connection and session relationship - as per thread with Roni on use of 'new' and 'existing'. o Use of K-Alive control message now aligned. o Clarified that a CONTROL with no payload should be dealt with at the package level. o Scrubbed ABNF + XML. 126.96.36.199. Changes from 02 Version o RAI review version. See comments. o Fixed broken IANA subsections ordering + naming. 188.8.131.52. Changes from 01 Version o Restructured text for readability. o Changed SYNCH method name to SYNC. o Removed 'pending' state to be replaced by 'update' with no payload. o Replaced construction of dialog-id with new SDP parameter and revised text. o Removed problem with K-Alive mechanism. K-Alive timers are now separate from any other Control messages as the delay in processing allows for un-sync on both sides. o Added transaction timeout of 5 seconds - as per meeting. o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Content-Type to table and missing examples etc. o Simplified Security Section as per meeting feedback. o Added proposed 'holdconn' text. o Added Default port text - as per meeting. o Added Audit text. 184.108.40.206. Changes from 00 Version o Aligned tokens to be 'CFW' (removed ESCS). o Content-Length not mandatory for messages with no payload. o Corrected changes to call flows from legacy versions. o Use of term 'Active UA' in section 7 + others. o Added 'notify' to status header of ABNF. o Changed 481 to be transaction specific. o Added '423' duplicate transaction ID response. o Added '405' method not allowed. o Added IANA section. o Added Security Considerations section (used MSRP and MRCPv2 as a template). o Removed noisy initial REPORT message - *Lorenzo please check text*. o Fixed ABNF - PLEASE CHECK. o Removed separate event mechanism and now all tied to CONTROL transaction (extended). o General scrub of text. o Organised 'Editors Notes' for discussion on the mailing list. o Fixed ABNF in relation to extra CRLF on Content-Type. 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 and Michael Bardzinski of Avaya, 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 draft and provided a great deal of invaluable input. Brian Weis carried out a thorough security review. Text from Eric Burger was used in the introduction in the explanation for using SIP. 16. Appendix AAppendix: Common Package Components During the creation of the Control Framework it has become clear that there are number of components that are common across multiple packages. It has become apparent that it would be useful to collect such re-usable components in a central location. In the short term this appendix provides the place holder 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. 16.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 also 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 'conf' 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. 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> 17. References 17.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. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 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. [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. [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 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. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 17.2. Informative References [I-D.burger-mscl-thoughts] Burger, E., "Media Server Control Language and Protocol Thoughts", draft-burger-mscl-thoughts-01 (work in progress), June 2006. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-16 (work in progress), October 2008. [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [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. Authors' Addresses Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EANS-Technologies Email: firstname.lastname@example.org@ns-technologies.com Tim Melanchuk Rain Willow Communications Email: email@example.com Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.