draft-ietf-mediactrl-sip-control-framework-12.txt   rfc6230.txt 
Network Working Group C. Boulton Internet Engineering Task Force (IETF) C. Boulton
Internet-Draft NS-Technologies Request for Comments: 6230 NS-Technologies
Intended status: Standards Track T. Melanchuk Category: Standards Track T. Melanchuk
Expires: March 7, 2011 Rain Willow Communications ISSN: 2070-1721 Rainwillow
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
September 3, 2010 May 2011
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-12
Abstract Abstract
This document describes a framework and protocol for application This document describes a framework and protocol for application
deployment where the application programming logic and media deployment where the application programming logic and media
processing are distributed. This implies that application processing are distributed. This implies that application
programming logic can seamlessly gain access to appropriate resources programming logic can seamlessly gain access to appropriate resources
that are not co-located on the same physical network entity. The that are not co-located on the same physical network entity. The
framework uses the Session Initiation Protocol (SIP) to establish an framework uses the Session Initiation Protocol (SIP) to establish an
application-level control mechanism between application servers and application-level control mechanism between application servers and
associated external servers such as media servers. associated external servers such as media servers.
The motivation for the creation of this framework is to provide an The motivation for the creation of this framework is to provide an
interface suitable to meet the requirements of a centralized interface suitable to meet the requirements of a centralized
conference system, where the conference system can be distributed, as conference system, where the conference system can be distributed, as
defined by the XCON Work Group in the IETF. It is not, however, defined by the XCON working group in the IETF. It is not, however,
limited to this scope. limited to this scope.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 7, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6230.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 11 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 11 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 14 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 16 6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 18 6.1. General Behavior for Constructing Requests . . . . . . . . 17
6.2. General Behaviour for Constructing Responses . . . . . . 19 6.2. General Behavior for Constructing Responses . . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . 19 6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 20 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 20 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 22 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 23 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 25 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 27 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . 27 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 27 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 28 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 28 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 28 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 29 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 32 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. Session Establishment . . . . . . . . . . . . . . . . . . 38 12.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
12.2. Transport Level Protection . . . . . . . . . . . . . . . 38 12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
12.3. Control Channel Policy Management . . . . . . . . . . . . 39 12.3. Control Channel Policy Management . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. Control Packages Registration Information . . . . . . . . 40 13.1. Control Packages Registration Information . . . . . . . . 38
13.1.1. Control Package Registration Template . . . . . . . . 41 13.1.1. Control Package Registration Template . . . . . . . . 39
13.2. Control Framework Method Names . . . . . . . . . . . . . 41 13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
13.3. Control Framework Status Codes . . . . . . . . . . . . . 42 13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
13.4. Control Framework Header Fields . . . . . . . . . . . . . 42 13.4. Control Framework Header Fields . . . . . . . . . . . . . 40
13.5. Control Framework Port . . . . . . . . . . . . . . . . . 43 13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
13.6. Media Type Registration . . . . . . . . . . . . . . . . . 43 13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
13.6.1. Registration of MIME Media Type application/cfw . . . 44 13.6.1. Registration of MIME Media Type application/cfw . . . 41
13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 45 13.6.2. Registration of MIME Media Type
13.8. URN Sub-Namespace for application/framework-attributes+xml . . . . . . . . . 42
urn:ietf:params:xml:ns:control:framework-attributes . . . 45 13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 46 13.8. URN Sub-Namespace for
13.10. MIME Media Type Registration for urn:ietf:params:xml:ns:control:framework-attributes . . . 43
'application/framework-attributes+xml' . . . . . . . . . 46 13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 43
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.1. Changes from 11 Version . . . . . . . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
14.2. Changes from 10 Version . . . . . . . . . . . . . . . . . 47 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.3. Changes from 09 Version . . . . . . . . . . . . . . . . . 48 16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
14.4. Changes from 08 Version . . . . . . . . . . . . . . . . . 48 16.2. Informative References . . . . . . . . . . . . . . . . . . 46
14.5. Changes from 07 Version . . . . . . . . . . . . . . . . . 48 Appendix A. Common Package Components . . . . . . . . . . . . . . 47
14.6. Changes from 06 Version . . . . . . . . . . . . . . . . . 48 A.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 47
14.7. Changes from 05 Version . . . . . . . . . . . . . . . . . 48
14.8. Changes from 04 Version . . . . . . . . . . . . . . . . . 49
14.9. Changes from 03 Version . . . . . . . . . . . . . . . . . 49
14.10. Changes from 02 Version . . . . . . . . . . . . . . . . . 49
14.11. Changes from 01 Version . . . . . . . . . . . . . . . . . 49
14.12. Changes from 00 Version . . . . . . . . . . . . . . . . . 50
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
17. Appendix: Common Package Components . . . . . . . . . . . . . 51
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 51
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
18.1. Normative References . . . . . . . . . . . . . . . . . . 52
18.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
Real-time media applications are often developed using an Real-time media applications are often developed using an
architecture where the application logic and media processing architecture where the application logic and media processing
activities are distributed. Commonly, the application logic runs on activities are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers, "application servers", but the processing runs on external servers,
such as "media servers". This document focuses on the framework and such as "media servers". This document focuses on the framework and
protocol between the application server and external processing protocol between the application server and external processing
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
requirements for Media Server Control, which can be found in the requirements for Media Server Control, which can be found in "Media
'Media Server Control Protocol Requirements' document[RFC5167]. Server Control Protocol Requirements" [RFC5167]. While the Framework
While the Framework is not media server control specific, it is the is not specific to media server control, it is the primary driver and
primary driver and use case for this work. It is intended that the use case for this work. It is intended that the framework contained
framework contained in this document can be used for a variety of in this document be able to be used for a variety of device control
device control scenarios (for example, conference control). scenarios (for example, conference control).
This document does not define a particular SIP protocol extension for This document does not define a particular SIP extension for the
the direct control of external components. Rather, other documents, direct control of external components. Rather, other documents,
known as "Control Packages," extend the control framework described known as "Control Packages", extend the Control Framework described
by this document. Section 8 provides a comprehensive set of by this document. Section 8 provides a comprehensive set of
guidelines for creating such Control Packages. guidelines for creating such Control Packages.
Current IETF device control protocols, such as megaco [RFC5125], Current IETF device control protocols, such as Megaco [RFC5125],
while excellent for controlling media gateways that bridge separate while excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in networks, are troublesome for supporting media-rich applications in
SIP networks. This is because megaco duplicates many of the SIP networks. This is because Megaco duplicates many of the
functions inherent in SIP. Rather than using a single protocol for functions inherent in SIP. Rather than using a single protocol for
session establishment and application media processing, application session establishment and application media processing, application
developers need to translate between two separate mechanisms. developers need to translate between two separate mechanisms.
Moreover, the model provided by the framework presented here, using Moreover, the model provided by the framework presented here, using
SIP, better matches the application programming model than does SIP, better matches the application programming model than does
megaco. Megaco.
SIP [RFC3261] provides the ideal rendezvous mechanism for SIP [RFC3261] provides the ideal rendezvous mechanism for
establishing and maintaining control connections to external server establishing and maintaining control connections to external server
components. The control connections can then be used to exchange components. The control connections can then be used to exchange
explicit command/response interactions that allow for media control explicit command/response interactions that allow for media control
and associated command response results. and associated command response results.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 6 skipping to change at page 5, line 8
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119], as document are to be interpreted as described in BCP 14, [RFC2119], as
scoped to those conformance targets. scoped to those conformance targets.
The following additional terms are defined for use in this document: The following additional terms are defined for use in this document:
User Agent Client (UAC): As specified in [RFC3261]. User Agent Client (UAC): As specified in [RFC3261].
User Agent Server (UAS): As specified in [RFC3261]. User Agent Server (UAS): As specified in [RFC3261].
B2BUA: A B2BUA is a Back-to-Back SIP User Agent. B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
Control Server: A Control Server is an entity that performs a Control Server: A Control Server is an entity that performs a
service, such as media processing, on behalf of a Control Client. service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing; announcement; tone For example, a media server offers mixing, announcement, tone
detection and generation; and play and record services. The detection and generation, and play and record services. The
Control Server has a direct Real-Time Transport Protocol (RTP) Control Server has a direct Real-Time Transport Protocol (RTP)
[RFC3550] relationship with the source or sink of the media flow. [RFC3550] relationship with the source or sink of the media flow.
In this document, we often refer to the Control Server simply as In this document, we often refer to the Control Server simply as
"the Server". "the Server".
Control Client: A Control Client is an entity that requests Control Client: A Control Client is an entity that requests
processing from a Control Server. Note that the Control Client processing from a Control Server. Note that the Control Client
might not have any processing capabilities whatsoever. For might not have any processing capabilities whatsoever. For
example, the Control Client may be an Application Server (B2BUA) example, the Control Client may be an application server (B2BUA)
or other endpoint requesting manipulation of a third-party's media or other endpoint requesting manipulation of a third party's media
stream, that terminates on a media server acting in the role of a stream that terminates on a media server acting in the role of a
Control Server. In this document, we often refer to the Control Control Server. In this document, we often refer to the Control
Client simply as "the Client". Client simply as "the Client".
Control Channel: A Control Channel is a reliable connection between Control Channel: A Control Channel is a reliable connection between
a Client and Server that is used to exchange Framework messages. a Client and Server that is used to exchange Framework messages.
The term "Connection" is used synonymously within this document. The term "Connection" is used synonymously within this document.
Framework Message: A Framework Message is a message on a Control
Framework Message: A Framework message is a message on a Control
Channel that has a type corresponding to one of the Methods Channel that has a type corresponding to one of the Methods
defined in this document. A Framework message is often referred defined in this document. A Framework message is often referred
to by its method, such as a "CONTROL message". to by its method, such as a "CONTROL message".
Method: A Method is the type of a framework message. Four Methods
Method: A Method is the type of a Framework message. Four Methods
are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE. are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
Control Command: A Control Command is an application level request
Control Command: A Control Command is an application-level request
from a Client to a Server. Control Commands are carried in the from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in body of CONTROL messages. Control Commands are defined in
separate specifications known as "Control Packages". separate specifications known as "Control Packages".
Framework Transaction: A Framework Transaction is defined as a Framework Transaction: A Framework Transaction is defined as a
sequence composed of a control framework message originated by sequence composed of a Control Framework message originated by
either a Control Client or Control Server and responded to with a either a Control Client or Control Server and responded to with a
control Framework response code message. Note that the control Control Framework response code message. Note that the Control
framework has no "provisional" responses. A control framework Framework has no "provisional" responses. A Control Framework
transaction is referenced throughout the draft as 'Transaction- transaction is referenced throughout the document as a
Timeout'. 'Transaction-Timeout'.
Transaction-Timeout: The maximum allowed time between a Control Transaction-Timeout: The maximum allowed time between a Control
Client or Server issuing a framework message and is arriving at Client or Server issuing a Framework message and it arriving at
the destination. The value for 'Transaction-Timeout' is 10 the destination. The value for 'Transaction-Timeout' is 10
seconds. seconds.
3. Overview 3. Overview
This document details mechanisms for establishing, using, and This document details mechanisms for establishing, using, and
terminating a reliable transport connection channel using SIP and the terminating a reliable transport connection channel using SIP and the
Session Description Protocol offer/answer [RFC3264] exchange. The Session Description Protocol offer/answer [RFC3264] exchange. The
established connection is then used for controlling an external established connection is then used for controlling an external
server. The following text provides a non-normative overview of the server. The following text provides a non-normative overview of the
mechanisms used. Detailed, normative guidelines are provided later mechanisms used. Detailed, normative guidelines are provided later
in the document. in the document.
Control channels are negotiated using standard SIP mechanisms that Control Channels are negotiated using standard SIP mechanisms that
would be used in a similar manner to creating a SIP multimedia would be used in a similar manner to creating a SIP multimedia
session. Figure 1 illustrates a simplified view of the mechanism. session. Figure 1 illustrates a simplified view of the mechanism.
It highlights a separation of the SIP signaling traffic and the It highlights a separation of the SIP signaling traffic and the
associated control channel that is established as a result of the SIP associated Control Channel that is established as a result of the SIP
interactions. interactions.
Initial analysis into the control framework, as documented in Initial analysis into the Control Framework, as documented in
[I-D.burger-mscl-thoughts], established the following. One might [MSCL-THOUGHTS], established the following. One might ask, "If all
ask, "If all we are doing is establishing a TCP connection to control we are doing is establishing a TCP connection to control the media
the media server, what do we need SIP for?" This is a reasonable server, why do we need SIP?" This is a reasonable question. The key
question. The key is we use SIP for media session establishment. If is that we use SIP for media session establishment. If we are using
we are using SIP for media session establishment, then we need to SIP for media session establishment, then we need to ensure the URI
ensure the URI used for session establishment resolves to the same used for session establishment resolves to the same node as the node
node as the node for session control. Using the SIP routing for session control. Using the SIP routing mechanism, and having the
mechanism, and having the server initiate the TCP connection back, server initiate the TCP connection back, ensures this works. For
ensures this works. For example, the URI sip:myserver.example.com example, the URI sip:myserver.example.com may resolve to sip:
may resolve to sip:server21.farm12.northeast.example.net, whereas the server21.farm12.northeast.example.net, whereas the URI
URI http://myserver.example.com may resolve to http://myserver.example.com may resolve to
http://server41.httpfarm.central.example.net. That is, the host part http://server41.httpfarm.central.example.net. That is, the host part
is not necessarily unambiguous. is not necessarily unambiguous.
The use of SIP to negotiate the control-channel provides many The use of SIP to negotiate the Control Channel provides many
inherent capabilities which include: inherent capabilities, which include:
o Service location - Use SIP Proxies and Back-to-Back User Agents o Service location - Use SIP Proxies and Back-to-Back User Agents
for locating Control Servers. for locating Control Servers.
o Security mechanisms - Leverage established security mechanisms o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication. such as Transport Layer Security (TLS) and Client Authentication.
o Connection maintenance - The ability to re-negotiate a connection, o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, and so forth. ensure it is active, and so forth.
o Application agnostic - Generic protocol allows for easy extension. o Application agnostic - Generic protocol allows for easy extension.
As mentioned in the previous list, one of the main benefits of using As mentioned in the previous list, one of the main benefits of using
SIP as the session control protocol is the "Service Location" SIP as the session control protocol is the "Service Location"
facilities provided. This applies at both a routing level, where facilities provided. This applies both at a routing level, where
[RFC3263] provides the physical location of devices, and at the [RFC3263] provides the physical location of devices, and at the
Service level, using Caller Preferences [RFC3840] and Callee service level, using Caller Preferences [RFC3840] and Callee
Capabilities [RFC3841]. The ability to select a Control Server based Capabilities [RFC3841]. The ability to select a Control Server based
on Service level capabilities is extremely powerful when considering on service-level capabilities is extremely powerful when considering
a distributed, clustered architecture containing varying services a distributed, clustered architecture containing varying services
(for example Voice, Video, IM). More detail on locating Control (for example, voice, video, IM). More detail on locating Control
Server resources using these techniques is outlined in Section 4.1 of Server resources using these techniques is outlined in Section 4.1 of
this document. this document.
+--------------SIP Traffic--------------+ +--------------SIP Traffic--------------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
| SIP | | SIP | | SIP | | SIP |
|Stack| |Stack| |Stack| |Stack|
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Control | | Control | | Control | | Control |
| Client |<----Control Channel---->| Server | | Client |<----Control Channel---->| Server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Basic Architecture Figure 1: Basic Architecture
The example from Figure 1 conveys a 1:1 connection between the The example from Figure 1 conveys a 1:1 connection between the
Control Client and the Control Server. It is possible, if required, Control Client and the Control Server. It is possible, if required,
for the client to request multiple control channels using separate for the client to request multiple Control Channels using separate
SIP INVITE dialogs between the Control Client and the Control Server SIP INVITE dialogs between the Control Client and the Control Server
entities. Any of the connections created between the two entities entities. Any of the connections created between the two entities
can then be used for Server control interactions. The control can then be used for Server control interactions. The control
connections are orthogonal to any given media session. Specific connections are orthogonal to any given media session. Specific
media session information are incorporated in control interaction media session information is incorporated in control interaction
commands, which themselves are defined in external packages, using commands, which themselves are defined in external packages, using
the XML schema defined in Section 17. The ability to have multiple the XML schema defined in Appendix A. The ability to have multiple
control channels allows for stronger redundancy and the ability to Control Channels allows for stronger redundancy and the ability to
manage high volumes of traffic in busy systems. manage high volumes of traffic in busy systems.
Consider the following simple example for session establishment Consider the following simple example for session establishment
between a Client and a Server (Note: Some lines in the examples are between a Client and a Server. (Note: Some lines in the examples are
removed for clarity and brevity). Note that the roles discussed are removed for clarity and brevity.) Note that the roles discussed are
logical and can change during a session, if the Control Package logical and can change during a session, if the Control Package
allows. allows.
The Client constructs and sends a standard SIP INVITE request, as The Client constructs and sends a standard SIP INVITE request, as
defined in [RFC3261], to the external Server. The Session defined in [RFC3261], to the external Server. The Session
Description Protocol (SDP) payload includes the required information Description Protocol (SDP) payload includes the required information
for control channel negotiation and is the primary mechanism for for Control Channel negotiation and is the primary mechanism for
conveying support for this specification. The application/cfw MIME conveying support for this specification. The application/cfw MIME
type is defined in this document to convey the appropriate SDP format type is defined in this document to convey the appropriate SDP format
for compliance to this specification. The COMEDIA [RFC4145] for compliance to this specification. The Connection-Oriented Media
specification for setting up and maintaining reliable connections is (COMEDIA) [RFC4145] specification for setting up and maintaining
used as part of the negotiation mechanism (more detail available in reliable connections is used as part of the negotiation mechanism
later sections). The Client also includes the 'cfw-id' SDP (more detail available in later sections). The Client also includes
attribute, as defined in this specification, which is a unique the 'cfw-id' SDP attribute, as defined in this specification, which
identifier used to correlate the underlying Media Control Channel is a unique identifier used to correlate the underlying Media Control
with the offer/answer exchange. Channel with the offer/answer exchange.
Client Sends to External Server: Client Sends to External Server:
INVITE sip:External-Server@example.com SIP/2.0 INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com> To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746 From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
Max-Forwards: 70 Max-Forwards: 70
CSeq: 1 INVITE CSeq: 1 INVITE
skipping to change at page 9, line 33 skipping to change at page 8, line 44
s=- s=-
c=IN IP4 controller.example.com c=IN IP4 controller.example.com
m=application 49153 TCP cfw m=application 49153 TCP cfw
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cfw-id:H839quwhjdhegvdga a=cfw-id:H839quwhjdhegvdga
On receiving the INVITE request, an external Server supporting this On receiving the INVITE request, an external Server supporting this
mechanism generates a 200 OK response containing appropriate SDP and mechanism generates a 200 OK response containing appropriate SDP and
formatted using the application/cfw MIME type specified in this formatted using the application/cfw MIME type specified in this
document. The Server inserts its own unique 'cfw-id' SDP attribute document. The Server inserts its own unique 'cfw-id' SDP attribute,
which differs from the one received in the INVITE (offer). which differs from the one received in the INVITE (offer).
External Server Sends to Client: External Server Sends to Client:
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879 To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746 From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
CSeq: 1 INVITE CSeq: 1 INVITE
skipping to change at page 10, line 26 skipping to change at page 9, line 21
o=responder 2890844526 2890842808 IN IP4 server.example.com o=responder 2890844526 2890842808 IN IP4 server.example.com
s=- s=-
c=IN IP4 mserver.example.com c=IN IP4 mserver.example.com
m=application 7563 TCP cfw m=application 7563 TCP cfw
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=cfw-id:U8dh7UHDushsdu32uha a=cfw-id:U8dh7UHDushsdu32uha
The Control Client receives the SIP 200 OK response and extracts the The Control Client receives the SIP 200 OK response and extracts the
relevant information (also sending a SIP ACK). It creates an relevant information (also sending a SIP ACK). It creates an
outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP outgoing (as specified by the SDP 'setup' attribute of 'active') TCP
connection to the Control Server. The connection address (taken from connection to the Control Server. The connection address (taken from
'c=') and port (taken from 'm=') are used to identify the remote port 'c=') and port (taken from 'm=') are used to identify the remote port
in the new connection. in the new connection.
Once established, the newly created connection can be used to Once established, the newly created connection can be used to
exchange requests and responses as defined in this document. If exchange requests and responses as defined in this document. If
required, after the control channel has been setup, media sessions required, after the Control Channel has been set up, media sessions
can be established using standard SIP Third Party Call Control (3PCC) can be established using standard SIP Third Party Call Control (3PCC)
[RFC3725]. [RFC3725].
Figure 2 provides a simplified example where the framework is used to Figure 2 provides a simplified example where the framework is used to
control a User Agent's RTP session. The link (1) in brackets control a User Agent's RTP session.
represents the SIP INVITE dialog usage and dedicated control channel
previously described in this overview section.
+--------Control SIP Dialog(1)---------+ +--------Control SIP Dialog(1)---------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP | +------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack| | |Stack| |Stack|
| +---+-----+---+ +---+-----+---+ | +---+-----+---+ +---+-----+---+
| | | | | | | | | |
| | Control |<--Control Channel(1)-->| | | | Control |<--Control Channel(1)-->| |
| | Client | | Control | | | Client | | Control |
| +-------------+ | Server | | +-------------+ | Server |
+--+--+ | | +--+--+ | |
|User | | | |User | | |
|Agent|<=====================RTP(2)===================>| | |Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+ +-----+ +-------------+
Figure 2: Participant Architecture Figure 2: Participant Architecture
The link (2) from Figure 2 represents the User Agent SIP INVITE The link (1) represents the SIP INVITE dialog usage and dedicated
dialog usage interactions and associated media flow. A User Agent Control Channel previously described in this overview section. The
creates a SIP INVITE dialog usage with the Control Client entity. link (2) from Figure 2 represents the User Agent SIP INVITE dialog
The Control Client entity then creates a SIP INVITE dialog usage to usage interactions and associated media flow. A User Agent creates a
the Control Server, using B2BUA type functionality. Using the SIP INVITE dialog usage with the Control Client entity. The Control
interaction illustrated by (2), the Control Client negotiates media Client entity then creates a SIP INVITE dialog usage to the Control
capabilities with the Control Server, on behalf of the User Agent, Server, using B2BUA type functionality. Using the interaction
using SIP Third Party Call Control (3PCC) [RFC3725]. illustrated by (2), the Control Client negotiates media capabilities
with the Control Server, on behalf of the User Agent, using SIP 3PCC.
[RFC3725].
4. Control Channel Setup 4. Control Channel Setup
This section describes the setup, using SIP, of the dedicated control This section describes the setup, using SIP, of the dedicated Control
channel. Once the control channel has been established commands can Channel. Once the Control Channel has been established, commands can
be exchanged (as discussed in Section 6). be exchanged (as discussed in Section 6).
4.1. Control Client SIP UAC Behavior 4.1. Control Client SIP UAC Behavior
When a UAC wishes to establish a control channel, it MUST construct When a UAC wishes to establish a Control Channel, it MUST construct
and transmit a new SIP INVITE request for control channel setup. The and transmit a new SIP INVITE request for Control Channel setup. The
UAC MUST construct the INVITE request as defined in [RFC3261]. UAC MUST construct the INVITE request as defined in [RFC3261].
If a reliable response is received (as defined [RFC3261] and If a reliable response is received (as defined in [RFC3261] and
[RFC3262]), the mechanisms defined in this document are applicable to [RFC3262]), the mechanisms defined in this document are applicable to
the newly created SIP INVITE dialog usage. the newly created SIP INVITE dialog usage.
The UAC SHOULD include a valid session description (an 'offer' as The UAC SHOULD include a valid session description (an 'offer' as
defined in [RFC3264]) in an INVITE request using the Session defined in [RFC3264]) in an INVITE request using the Session
Description Protocol defined in [RFC4566] but MAY choose an offer- Description Protocol defined in [RFC4566] but MAY choose an offer-
less INVITE as per [RFC3261]. The SDP SHOULD be formatted in less INVITE as per [RFC3261]. The SDP SHOULD be formatted in
accordance with the steps below which is registered in this document accordance with the steps below and using the MIME type application/
as MIME type application/cfw in Section 13. The following cfw, which is registered in Section 13. The following information
information defines the composition of specific elements of the SDP defines the composition of specific elements of the SDP payload the
payload the offerer MUST adhere to when used in a SIP based offer/ offerer MUST adhere to when used in a SIP-based offer/answer exchange
answer exchange using SDP and the application/cfw MIME type. The SDP using SDP and the application/cfw MIME type. The SDP being
being constructed MUST contain only a single occurrence of a control constructed MUST contain only a single occurrence of a Control
channel definition outlined in this specification but can contain Channel definition outlined in this specification but can contain
other media lines if required. other media lines if required.
The Connection Data line in the SDP payload is constructed as The Connection Data line in the SDP payload is constructed as
specified in [RFC4566]: specified in [RFC4566]:
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The first sub-field, <nettype>, MUST equal the value "IN". The The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The
third sub-field for Connection Data is <connection-address>. This third sub-field for Connection Data is <connection-address>. This
supplies a representation of the SDP originators address, for example supplies a representation of the SDP originator's address, for
dns/IP representation. The address is the address used for example, DNS/IP representation. The address is the address used for
connections. connections.
Example: Example:
c=IN IP4 controller.example.com c=IN IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry: The SDP MUST contain a corresponding Media Description entry:
m=<media> <port> <proto> <fmt> m=<media> <port> <proto> <fmt>
The first "sub-field" <media> MUST equal the value "application". The first "sub-field", <media>, MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the The second sub-field, <port>, MUST represent a port on which the
constructing client can receive an incoming connection if required. constructing client can receive an incoming connection if required.
The port is used in combination with the address specified in the The port is used in combination with the address specified in the
Connection Data line defined previously to supply connection details. Connection Data line defined previously to supply connection details.
If entity constructing the SDP can't receive incoming connections it If the entity constructing the SDP can't receive incoming
must still enter a valid port entry. The use of the port value '0' connections, it must still enter a valid port entry. The use of the
has the same meaning as defined in a SIP Offer/Answer port value '0' has the same meaning as defined in a SIP offer/answer
exchange[RFC3264]. The Control Framework has a default port defined exchange [RFC3264]. The Control Framework has a default port defined
in Section 13.5. This value is default although a client is free to in Section 13.5. This value is default, although a client is free to
choose explicit port numbers. However, SDP SHOULD use the default choose explicit port numbers. However, SDP SHOULD use the default
port number, unless local policy prohibits its use. Using the port number, unless local policy prohibits its use. Using the
default port number allows network administrators to manage firewall default port number allows network administrators to manage firewall
policy for Control Framework interactions. The third sub-field, policy for Control Framework interactions. The third sub-field,
<proto>, compliant to this specification, MUST support the values <proto>, compliant to this specification, MUST support the values
"TCP" and "TCP/TLS". Implementations MUST support TLS as a "TCP" and "TCP/TLS". Implementations MUST support TLS as a
transport-level security mechanism for the control channel, although transport-level security mechanism for the Control Channel, although
use of TLS in specific deployments is optional. Control Framework use of TLS in specific deployments is optional. Control Framework
implementations MUST support TCP as a transport protocol. When an implementations MUST support TCP as a transport protocol. When an
entity identifies a transport value but is not willing to establish entity identifies a transport value but is not willing to establish
the session, it MUST respond using the appropriate SIP mechanism. the session, it MUST respond using the appropriate SIP mechanism.
The <fmt> sub-field MUST contain the value "cfw". The <fmt> sub-field MUST contain the value "cfw".
The SDP MUST also contain a number of SDP media attributes(a=) that The SDP MUST also contain a number of SDP media attributes (a=) that
are specifically defined in the COMEDIA [RFC4145] specification. The are specifically defined in the COMEDIA [RFC4145] specification. The
attributes provide connection negotiation and maintenance parameters. attributes provide connection negotiation and maintenance parameters.
It is RECOMMENDED that a Controlling UAC initiate a connection to an It is RECOMMENDED that a Controlling UAC initiate a connection to an
external Server but that an external Server MAY negotiate and external Server but that an external Server MAY negotiate and
initiate a connection using COMEDIA, if network topology prohibits initiate a connection using COMEDIA, if network topology prohibits
initiating connections in a certain direction. An example of the initiating connections in a certain direction. An example of the
COMEDIA attributes is: COMEDIA attributes is:
a=setup:active a=setup:active
a=connection:new a=connection:new
skipping to change at page 13, line 32 skipping to change at page 12, line 16
from the owner of the SDP payload. The connection details are from the owner of the SDP payload. The connection details are
contained in the SDP answer received from the UAS. A full example of contained in the SDP answer received from the UAS. A full example of
an SDP payload compliant to this specification can be viewed in an SDP payload compliant to this specification can be viewed in
Section 3. Once the SDP has been constructed along with the Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in [RFC3261]), it can remainder of the SIP INVITE request (as defined in [RFC3261]), it can
be sent to the appropriate location. The SIP INVITE dialog usage and be sent to the appropriate location. The SIP INVITE dialog usage and
appropriate control connection is then established. appropriate control connection is then established.
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP A SIP UAC constructing an offer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. The 'cfw-id' attribute attribute as defined in Section 9.2. The 'cfw-id' attribute
indicates an identifier that can be used within the control channel indicates an identifier that can be used within the Control Channel
to correlate the control channel with this SIP INVITE dialog usage. to correlate the Control Channel with this SIP INVITE dialog usage.
The 'cfw-id' attribute MUST be unique in the context of the The 'cfw-id' attribute MUST be unique in the context of the
interaction between the UAC and UAS and MUST NOT clash with instances interaction between the UAC and UAS and MUST NOT clash with instances
of the 'cfw-id' used in other SIP offer/answer exchanges. The value of the 'cfw-id' used in other SIP offer/answer exchanges. The value
chosen for the 'cfw-id' attribute MUST be used for the entire chosen for the 'cfw-id' attribute MUST be used for the entire
duration of the associated SIP INVITE dialog usage and not be changed duration of the associated SIP INVITE dialog usage and not be changed
during updates to the offer/answer exchange. This applies during updates to the offer/answer exchange. This applies
specifically to the 'connection' attribute as defined in [RFC4145]. specifically to the 'connection' attribute as defined in [RFC4145].
If a SIP UAC wants to change some other parts of the SDP but reuse If a SIP UAC wants to change some other parts of the SDP but reuse
the already established connection it uses the value of 'existing' in the already established connection, it uses the value of 'existing'
the 'connection' attribute (for example, a=connection:existing). If in the 'connection' attribute (for example, a=connection:existing).
it has noted that a connection has failed and wants to re-establish If it has noted that a connection has failed and wants to re-
the connection, it uses the value of 'new' in the 'connection' establish the connection, it uses the value of 'new' in the
attribute (for example, a=connection:new). Throughout this the 'connection' attribute (for example, a=connection:new). Throughout
connection identifier specified in the 'cfw-id' SDP parameter MUST this, the connection identifier specified in the 'cfw-id' SDP
NOT change. One is simply negotiating the underlying TCP connection parameter MUST NOT change. One is simply negotiating the underlying
between endpoints but always using the same Control Framework TCP connection between endpoints but always using the same Control
session, which is 1:1 for the lifetime of the SIP INVITE dialog Framework session, which is 1:1 for the lifetime of the SIP INVITE
usage. dialog usage.
A non-2xx class final SIP response (3xx, 4xx, 5xx and 6xx) received A non-2xx-class final SIP response (3xx, 4xx, 5xx, and 6xx) received
for the INVITE request indicates that no SIP INVITE dialog usage has for the INVITE request indicates that no SIP INVITE dialog usage has
been created and is treated as specified by SIP [RFC3261]. been created and is treated as specified by SIP [RFC3261].
Specifically, support of this specification is negotiated through the Specifically, support of this specification is negotiated through the
presence of the media type defined in this specification. The presence of the media type defined in this specification. The
receipt of a SIP error response such as "488" indicates that the receipt of a SIP error response such as "488" indicates that the
offer contained in a request is not acceptable. The inclusion of the offer contained in a request is not acceptable. The inclusion of the
media line associated with this specification in such a rejected media line associated with this specification in such a rejected
offer indicates to the client generating the offer that this could be offer indicates to the client generating the offer that this could be
due to the receiving client not supporting this specification. The due to the receiving client not supporting this specification. The
client generating the offer MUST act as it would normally on client generating the offer MUST act as it would normally on
receiving this response, as per [RFC3261]. Media streams can also be 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 rejected by setting the port to "0" in the "m=" line of the session
description, as defined in [RFC3264]. A client using this description, as defined in [RFC3264]. A client using this
specification MUST be prepared to receive an answer where the "m=" specification MUST be prepared to receive an answer where the "m="
line it inserted for using the Control Framework has been set to "0". 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". In this situation, the client will act as it would for any other
media type with a port set to "0".
4.2. Control Server SIP UAS Behavior 4.2. Control Server SIP UAS Behavior
On receiving a SIP INVITE request, an external Server(SIP UAS) On receiving a SIP INVITE request, an external Server (SIP UAS)
inspects the message for indications of support for the mechanisms inspects the message for indications of support for the mechanisms
defined in this specification. This is achieved through inspection defined in this specification. This is achieved through inspection
of the Sessions Description of the offer message and identifying of the session description of the offer message and identifying
support for the application/cfw MIME type in the SDP. If the SIP UAS support for the application/cfw MIME type in the SDP. If the SIP UAS
wishes to construct a reliable response that conveys support for the wishes to construct a reliable response that conveys support for the
extension, it MUST follow the mechanisms defined in [RFC3261]. If extension, it MUST follow the mechanisms defined in [RFC3261]. If
support is conveyed in a reliable SIP provisional response, the support is conveyed in a reliable SIP provisional response, the
mechanisms in [RFC3262] MUST also be used. It should be noted that 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 the SDP offer is not restricted to the initial INVITE request and MAY
appear in any series of messages that are compliant to [RFC3261], appear in any series of messages that are compliant to [RFC3261],
[RFC3262], [RFC3311] and [RFC3264]. [RFC3262], [RFC3311], and [RFC3264].
When constructing an answer, the SDP payload MUST be constructed When constructing an answer, the SDP payload MUST be constructed
using the semantic (Connection, Media and attribute) defined in using the semantic (connection, media, and attribute) defined in
Section 4.1 using valid local settings and also with full compliance Section 4.1 using valid local settings and also with full compliance
to the COMEDIA [RFC4145] specification. For example, the SDP to the COMEDIA [RFC4145] specification. For example, the SDP
attributes included in the answer constructed for the example offer attributes included in the answer constructed for the example offer
provided in Section 4.1 would look as illustrated below: provided in Section 4.1 would look as follows:
a=setup:passive a=setup:passive
a=connection:new a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP A client constructing an answer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. This attribute MUST be unique attribute as defined in Section 9.2. This attribute MUST be unique
in the context of the interaction between the UAC and UAS and MUST in the context of the interaction between the UAC and UAS and MUST
NOT clash with instances of the 'cfw-id' used in other SIP offer/ NOT clash with instances of the 'cfw-id' used in other SIP offer/
answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id' answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id'
value received in the offer as it is used to uniquely identify and value received in the offer as it is used to uniquely identify and
distinguish between multiple endpoint generating SDP answers. The distinguish between multiple endpoints that generate SDP answers.
value chosen for the 'cfw-id' attribute MUST be used for the entire The value chosen for the 'cfw-id' attribute MUST be used for the
duration of the associated SIP INVITE dialog usage and not be changed entire duration of the associated SIP INVITE dialog usage and not be
during updates to the offer/answer exchange. changed during updates to the offer/answer exchange.
Once the SDP answer has been constructed, it is sent using standard Once the SDP answer has been constructed, it is sent using standard
SIP mechanisms. Depending on the contents of the SDP payloads that SIP mechanisms. Depending on the contents of the SDP payloads that
were negotiated using the Offer/Answer exchange, a reliable were negotiated using the offer/answer exchange, a reliable
connection will be established between the Controlling UAC and connection will be established between the Controlling UAC and
External Server UAS entities. The newly established connection is External Server UAS entities. The newly established connection is
now available to exchange control command primitives. The state of now available to exchange Control Command primitives. The state of
the SIP INVITE Dialog usage and the associated Control channel are the SIP INVITE dialog usage and the associated Control Channel are
now implicitly linked. If either party wishes to terminate a Control now implicitly linked. If either party wishes to terminate a Control
channel it simply issues a SIP termination request (for example a SIP Channel, it simply issues a SIP termination request (for example, a
BYE request, or appropriate response in an early SIP INVITE dialog SIP BYE request or appropriate response in an early SIP INVITE dialog
usage). The Control Channel therefore lives for the duration of the usage). The Control Channel therefore lives for the duration of the
SIP INVITE dialog usage. SIP INVITE dialog usage.
A UAS receiving a SIP OPTIONS request MUST respond appropriately as A UAS receiving a SIP OPTIONS request MUST respond appropriately as
defined in [RFC3261]. The UAS MUST include the media types supported defined in [RFC3261]. The UAS MUST include the media types supported
in the SIP 200 OK response in a SIP "Accept" header to indicate the in the SIP 200 OK response in a SIP 'Accept' header to indicate the
valid media types. valid media types.
5. Establishing Media Streams - Control Client SIP UAC Behavior 5. Establishing Media Streams - Control Client SIP UAC Behavior
It is intended that the Control framework will be used within a It is intended that the Control Framework will be used within a
variety of architectures for a wide range of functions. One of the variety of architectures for a wide range of functions. One of the
primary functions will be the use of the control channel to apply primary functions will be the use of the Control Channel to apply
multiple specific Control package commands to media sessions multiple specific Control Package commands to media sessions
established by SIP INVITE dialogs (media dialogs) with a given remote established by SIP INVITE dialogs (media dialogs) with a given remote
server. For example, the Control Server might send a command to server. For example, the Control Server might send a command to
generate audio media (such as an announcement) on an RTP stream generate audio media (such as an announcement) on an RTP stream
between a User Agent and a Media Server. between a User Agent and a media server.
SIP INVITE dialogs used to establish media sessions (see Figure 2) on SIP INVITE dialogs used to establish media sessions (see Figure 2) on
behalf of User Agents MAY contain more than one Media Description (as behalf of User Agents MAY contain more than one Media Description (as
defined by "m=" in the SDP). The Control Client MUST include a media defined by "m=" in the SDP). The Control Client MUST include a media
label attribute, as defined in [RFC4574], for each "m=" definition label attribute, as defined in [RFC4574], for each "m=" definition
received that is to be directed to an entity using the control received that is to be directed to an entity using the Control
framework. This allows the Control Client to later explicitly direct Framework. This allows the Control Client to later explicitly direct
commands on the control channel at a specific media line (m=). commands on the Control Channel at a specific media line (m=).
This framework identifies the referencing of such associated media This framework identifies the referencing of such associated media
dialogs as extremely important. A connection reference attribute has dialogs as extremely important. A connection reference attribute has
been specified that can optionally be imported into any Control been specified that can optionally be imported into any Control
Package. It is intended that this will reduce repetitive specifying Package. It is intended that this will reduce the repetitive
of dialog reference language. The schema can be found in specifying of dialog reference language. The schema can be found in
Section 17.1 in Appendix A. Appendix A.1.
Similarly, the ability to identify and apply commands to a group of Similarly, the ability to identify and apply commands to a group of
associated media dialogs (multiparty) is also identified as a common associated media dialogs (multiparty) is also identified as a common
structure that could be defined and re-used, for example playing a structure that could be defined and reused, for example, playing a
prompt to all participants in a Conference. The schema for such prompt to all participants in a Conference. The schema for such
operations can also be found in Section 17.1 in Appendix A. operations can also be found in Appendix A.1.
Support for both the common attributes described here is specified as Support for both the common attributes described here is specified as
part of each Control Package definition, as detailed in Section 8. part of each Control Package definition, as detailed in Section 8.
6. Control Framework Interactions 6. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a In this document, the use of the COMEDIA specification allows for a
Control Channel to be set up in either direction as a result of a SIP Control Channel to be set up in either direction as a result of a SIP
INVITE transaction. SIP provides a flexible negotiation mechanism to INVITE transaction. SIP provides a flexible negotiation mechanism to
establish the control channel, but there needs to be a mechanism establish the Control Channel, but there needs to be a mechanism
within the control channel to correlate the control channel with the within the Control Channel to correlate it with the SIP INVITE dialog
SIP INVITE dialog usage used for its establishment. A Control Client usage implemented for its establishment. A Control Client receiving
receiving an incoming connection (whether it be acting in the role of an incoming connection (whether it be acting in the role of UAC or
UAC or UAS) has no way of identifying the associated SIP INVITE UAS) has no way of identifying the associated SIP INVITE dialog usage
dialog usage as it could be simply listening for all incoming as it could be simply listening for all incoming connections on a
connections on a specific port. The following steps, which specific port. The following steps, which implementations MUST
implementations MUST support, allow a connecting UA that is, the UA support, allow a connecting UA (that is, the UA with the active role
with the 'active' role in COMEDIA, to identify the associated SIP in COMEDIA) to identify the associated SIP INVITE dialog usage that
INVITE dialog usage that triggered the connection. Unless there is triggered the connection. Unless there is an alternative dialog
an alternative dialog association mechanism used, the UAs MUST carry association mechanism used, the UAs MUST carry out these steps before
out these steps before any other signaling on the newly created any other signaling on the newly created Control Channel.
Control channel.
o Once the connection has been established, the UA acting in the o Once the connection has been established, the UA acting in the
active role (active UA) to initiate the connection MUST send a active role (active UA) to initiate the connection MUST send a
Control Framework SYNC request. The SYNC request MUST be Control Framework SYNC request. The SYNC request MUST be
constructed as defined in Section 9.1 and MUST contain the constructed as defined in Section 9.1 and MUST contain the
'Dialog-ID' message header. 'Dialog-ID' message header.
o The 'Dialog-ID' message header is populated with the value of the o The 'Dialog-ID' message header is populated with the value of the
local 'cfw-id' media level attribute that was inserted by the same local 'cfw-id' media-level attribute that was inserted by the same
client in the SDP offer/answer exchange to establish the control client in the SDP offer/answer exchange to establish the Control
channel. This allows for a correlation between the control Channel. This allows for a correlation between the Control
channel and its associated SIP INVITE dialog usage. Channel and its associated SIP INVITE dialog usage.
o On creating the SYNC request the active UA MUST follow the o On creating the SYNC request, the active UA MUST follow the
procedures outlined in Section 6.3.3. This provides details of procedures outlined in Section 6.3.3. This provides details of
connection keep alive messages. connection keep-alive messages.
o On creating the SYNC request the active UA MUST also follow the
o On creating the SYNC request, the active UA MUST also follow the
procedures outlined in Section 6.3.4.2. This provides details of procedures outlined in Section 6.3.4.2. This provides details of
the negotiation mechanism used to determine the Protocol Data the negotiation mechanism used to determine the Protocol Data
Units (PDUs) that can be exchanged on the established control Units (PDUs) that can be exchanged on the established Control
channel connection. Channel connection.
o The UA in the active role for the connection creation MUST then o The UA in the active role for the connection creation MUST then
send the SYNC request. If the UA in the active role for the send the SYNC request. If the UA in the active role for the
connection creation is a SIP UAS and has generated its SDP connection creation is a SIP UAS and has generated its SDP
response in a 2XX class SIP response, it MUST wait for incoming response in a 2xx-class SIP response, it MUST wait for an incoming
SIP ACK message before issuing the SYNC. If the UA in the active SIP ACK message before issuing the SYNC. If the UA in the active
role for the connection creation is a SIP UAS and has generated role for the connection creation is a SIP UAS and has generated
its SDP response in a reliable 1XX class SIP response, it MUST its SDP response in a reliable 1XX class SIP response, it MUST
wait for incoming SIP PRACK message before issuing the SYNC. If wait for an incoming SIP PRACK message before issuing the SYNC.
the UA in the active role for the connection creation is a SIP UAC
it MUST send the SYNC message immediately on establishment of the If the UA in the active role for the connection creation is a SIP
control channel. It MUST then wait for a period of at least UAC, it MUST send the SYNC message immediately on establishment of
the Control Channel. It MUST then wait for a period of at least
2*'Transaction-Timeout' to receive a response. It MAY choose a 2*'Transaction-Timeout' to receive a response. It MAY choose a
longer time to wait but it MUST NOT be shorter than 'Transaction- longer time to wait, but it MUST NOT be shorter than 'Transaction-
Timeout'. In general, a control framework transaction MUST Timeout'. In general, a Control Framework transaction MUST
complete within 20 (2*Transaction-Timeout) seconds and is complete within 20 (2*'Transaction-Timeout') seconds and is
referenced throughout the draft as 'Transaction-Timeout'. referenced throughout the document as '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 o If no response is received for the SYNC message, a timeout occurs
associated SIP INVITE dialog usage. The active UA MUST issue a and the Control Channel is terminated along with the associated
BYE request to terminate the SIP INVITE dialog usage. SIP INVITE dialog usage. The active UA MUST issue a BYE request
to terminate the SIP INVITE dialog usage.
o If the active UA receives a 481 response from the passive UA, this o If the active UA receives a 481 response from the passive UA, this
means the SYNC request was received but the associated SIP INVITE means the SYNC request was received, but the associated SIP INVITE
dialog usage specified in the SYNC message does not exists. The dialog usage specified in the SYNC message does not exist. The
active client MUST terminate the control channel. The active UA active client MUST terminate the Control Channel. The active UA
MUST issue a SIP BYE request to terminate the SIP INVITE dialog MUST issue a SIP BYE request to terminate the SIP INVITE dialog
usage. usage.
o All other error responses received for the SYNC request are o All other error responses received for the SYNC request are
treated as detailed in this specification and also result in the treated as detailed in this specification and also result in the
termination of the control channel and the associated SIP INVITE termination of the Control Channel and the associated SIP INVITE
dialog usage. The active UA MUST issue a BYE request to terminate dialog usage. The active UA MUST issue a BYE request to terminate
the SIP INVITE dialog usage. the SIP INVITE dialog usage.
o The receipt of a 200 response to a SYNC message implies that the o The receipt of a 200 response to a SYNC message implies that the
SIP INVITE dialog usage and control connection have been SIP INVITE dialog usage and control connection have been
successfully correlated. The control channel can now be used for successfully correlated. The Control Channel can now be used for
further interactions. further interactions.
SYNC messages can be sent at any point while the Control Channel is SYNC messages can be sent at any point while the Control Channel is
open from either side, once the initial exchange is complete. If open from either side, once the initial exchange is complete. If
present, the contents of the Keep-Alive and Dialog-ID headers MUST present, the contents of the 'Keep-Alive' and 'Dialog-ID' headers
NOT change. New values of the Keep-Alive and Dialog-ID headers have MUST NOT change. New values of the 'Keep-Alive' and 'Dialog-ID'
no relevance as they are negotiated for the lifetime of the Media headers have no relevance as they are negotiated for the lifetime of
Control Channel Framework session. the Media Control Channel Framework session.
Once a successful control channel has been established, as defined in Once a successful Control Channel has been established, as defined in
Section 4.1 and Section 4.2, and the connection has been correlated, Sections 4.1 and 4.2, and the connection has been correlated, as
as described in previous paragraphs, the two entities are now in a described in previous paragraphs, the two entities are now in a
position to exchange control framework messages. The following sub- position to exchange Control Framework messages. The following sub-
sections specify the general behaviour for constructing control sections specify the general behavior for constructing Control
framework requests and responses. Section 6.3 specifies the core Framework requests and responses. Section 6.3 specifies the core
Control Framework methods and their transaction processing. Control Framework methods and their transaction processing.
6.1. General Behaviour for Constructing Requests 6.1. General Behavior for Constructing Requests
An entity acting as a Control Client that constructs and sends An entity acting as a Control Client that constructs and sends
requests on a control channel MUST adhere to the syntax defined in requests on a Control Channel MUST adhere to the syntax defined in
Section 9. Note that either entity can act as a control client Section 9. Note that either entity can act as a Control Client
depending on individual package requirements. Control Commands MUST depending on individual package requirements. Control Commands MUST
also adhere to the syntax defined by the Control Packages negotiated 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 in Sections 4.1 and 4.2 of this document. A Control Client MUST
MUST create a unique control message transaction and associated create a unique transaction and associated identifier for insertion
identifier for insertion in the request. The transaction identifier in the request. The transaction identifier is then included in the
is then included in the first line of a control framework message first line of a Control Framework message along with the method type,
along with the method type, as defined in the ABNF in Section 9. The as defined in the ABNF in Section 9. The first line starts with the
first line starts with the "CFW" token for the purpose of easily "CFW" token for the purpose of easily extracting the transaction
extracting the transaction identifier. The transaction identifier identifier. The transaction identifier MUST be unique in the context
MUST be unique in the context of the interaction between the control of the interaction between the Control Client and Control Server.
client and control server. This unique property helps in the This unique property helps avoid clashes when multiple client
avoidance of clashes when multiple client entities could be creating entities could be creating transactions to be carried out on a single
transactions to be carried out on a single receiving server. All receiving server. All required, mandatory, and optional Control
required, mandatory, and optional control framework headers are then Framework headers are then inserted into the request with appropriate
inserted into the control message with appropriate values (see values (see relevant individual header information for explicit
relevant individual header information for explicit detail). A detail). A 'Control-Package' header MUST also be inserted with the
"Control-Package" header MUST also be inserted with the value value indicating the Control Package to which this specific request
indicating the Control Package to which this specific request applies. Multiple packages can be negotiated per Control Channel
applies. Multiple packages can be negotiated per control channel using the SYNC message discussed in Section 6.3.4.2.
using the SYNC control message discussed in Section 6.3.4.2.
Any framework message that contains an associated payload MUST also Any Framework message that contains an associated payload MUST also
include a 'Content-Type' and 'Content-Length' message header which is include the 'Content-Type' and 'Content-Length' message headers,
the size of the message body represented as a whole decimal number of which indicate the MIME type of the payload specified by the
octets. The 'Content-Type' header is the MIME type of the payload individual Control Framework packages and the size of the message
specified by the individual control framework packages. If no body represented as a whole decimal number of octets, respectively.
associated payload is to be added to the message, the 'Content- If no associated payload is to be added to the message, the 'Content-
Length' header MUST have a value of '0'. Length' header MUST have a value of '0'.
A Server receiving a framework message request MUST respond with an A Server receiving a Framework message request MUST respond with an
appropriate response (as defined in Section 6.2). Control Clients appropriate response (as defined in Section 6.2). Control Clients
MUST wait for a minimum of 2*'Transaction-Timeout' for a response MUST wait for a minimum of 2*'Transaction-Timeout' for a response
before considering the transaction a failure and tidying state before considering the transaction a failure and tidying state
appropriately depending on the extension package being used. appropriately depending on the extension package being used.
6.2. General Behaviour for Constructing Responses 6.2. General Behavior for Constructing Responses
An entity acting as a Control Server, on receiving a request, MUST An entity acting as a Control Server, on receiving a request, MUST
generate a response within the 'Transaction-Time', as measured from generate a response within the 'Transaction-Timeout', as measured
the Control Client. The response MUST conform to the ABNF defined in from the Control Client. The response MUST conform to the ABNF
Section 9. The first line of the response MUST contain the defined in Section 9. The first line of the response MUST contain
transaction identifier used in first line of the request, as defined the transaction identifier used in the first line of the request, as
in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' defined in Section 6.1. Responses MUST NOT include the 'Status' or
message headers, and these MUST be ignored if received by a Client in 'Timeout' message headers, and these MUST be ignored if received by a
a response. Client in a response.
A Control Server MUST include a status code in the first line of the A Control Server MUST include a status code in the first line of the
response. If there is no error, the Server responds with a 200 response. If there is no error, the Server responds with a 200
Control Framework status code, as defined in Section 7.1. The 200 Control Framework status code, as defined in Section 7.1. The 200
response MAY include message bodies. If the response contains a response MAY include message bodies. If the response contains a
payload, the message MUST include the Content-Length and Content-Type payload, the message MUST include the 'Content-Length' and 'Content-
headers. When the Control Client receives a 200-class response, the Type' headers. When the Control Client receives a 2xx-class
control command transaction is complete. response, the Control Command transaction is complete.
If the Control Server receives a request, like CONTROL, that the If the Control Server receives a request, like CONTROL, that the
Server understands, but the Server knows processing the command will Server understands, but the Server knows processing the command will
exceed the Transaction-Timeout, then the Server MUST respond with a exceed the 'Transaction-Timeout', then the Server MUST respond with a
202 status code in the first line of the response. Following the 202 status code in the first line of the response. Following the
initial response, the server will send one or more REPORT messages as initial response, the server will send one or more REPORT messages as
described in Section 6.3.2. A Control Package MUST explicitly define described in Section 6.3.2. A Control Package MUST explicitly define
the circumstances under which the server sends 200 and 202 messages. the circumstances under which the server sends 200 and 202 messages.
If a Control Server encounters problems with a Control Framework If a Control Server encounters problems with a Control Framework
request (like REPORT or CONTROL), an appropriate error code MUST be request (like REPORT or CONTROL), an appropriate error code MUST be
used in the response, as listed in Section 7. The generation of a used in the response, as listed in Section 7. The generation of a
non 2xx class response code to a Control Framework request (like non-2xx-class response code to a Control Framework request (like
CONTROL or REPORT) will indicate failure of the transaction, and all CONTROL or REPORT) will indicate failure of the transaction, and all
associated transaction state and resources MUST be terminated. The associated transaction state and resources MUST be terminated. The
response code may provide an explicit indication of why the response code may provide an explicit indication of why the
transaction failed, which might result in a re-submission of the transaction failed, which might result in a re-submission of the
request depending on the extension package being used. request depending on the extension package being used.
6.3. Transaction Processing 6.3. Transaction Processing
The Control Framework defines four types of requests (methods): The Control Framework defines four types of requests (methods):
CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support
sending and receiving these four methods. sending and receiving these four methods.
The following sub-sections specify each Control Framework method and The following sub-sections specify each Control Framework method and
its associated transaction processing. its associated transaction processing.
6.3.1. CONTROL Transactions 6.3.1. CONTROL Transactions
A CONTROL message is used by the Control Client to pass control A CONTROL message is used by the Control Client to pass control-
related information to a Control Server. It is also used as the related information to a Control Server. It is also used as the
event reporting mechanism in the control framework. Reporting events event-reporting mechanism in the Control Framework. Reporting events
is simply another usage of the CONTROL message which is permitted to is simply another usage of the CONTROL message, which is permitted to
be sent in either direction between two participants in a session, be sent in either direction between two participants in a session,
carrying the appropriate payload for an event. The message is carrying the appropriate payload for an event. The message is
constructed in the same way as any standard Control Framework constructed in the same way as any standard Control Framework
message, as discussed previously in Section 6.1 and defined in message, as discussed in Section 6.1 and defined in Section 9. A
Section 9. A CONTROL message MAY contain a message body. The CONTROL message MAY contain a message body. The explicit Control
explicit control command(s) of the message payload contained in a Command(s) of the message payload contained in a CONTROL message are
CONTROL message are specified in separate Control Package specified in separate Control Package specifications. Separate
specifications. Separate Control Package specifications MUST conform Control Package specifications MUST conform to the format defined in
to the format defined in Section 8.4. A CONTROL message containing a Section 8.4. A CONTROL message containing a payload MUST include a
payload MUST include a Content-Type header. The payload MUST be one 'Content-Type' header. The payload MUST be one of the payload types
of the payload types defined by the control package. Individual defined by the Control Package. Individual packages MAY allow a
packages MAY allow a CONTROL message that does not contain a payload. CONTROL message that does not contain a payload. This could in fact
This could in fact be a valid message exchange within a specific be a valid message exchange within a specific package; if it's not,
package and if not an appropriate package-level error message MUST be an appropriate package-level error message MUST be generated.
generated.
6.3.2. REPORT Transactions 6.3.2. REPORT Transactions
A 'REPORT' message is used by a Control Server when processing of a A 'REPORT' message is used by a Control Server when processing of a
CONTROL Command extends beyond the Transaction-Timeout, as measured CONTROL command extends beyond the 'Transaction-Timeout', as measured
from the Client. In this case the Server returns a 202 response. from the Client. In this case, the Server returns a 202 response.
The Server returns status updates and the final results of the The Server returns status updates and the final results of the
command in subsequent REPORT messages. command in subsequent REPORT messages.
All REPORT messages MUST contain the same transaction ID in the All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL request start line that was present in the original CONTROL
transaction. This correlates extended transactions with the original transaction. This correlates extended transactions with the original
CONTROL transaction. A REPORT message containing a payload MUST CONTROL transaction. A REPORT message containing a payload MUST
include the Content-Type and Content-Length headers indicating the include the 'Content-Type' and 'Content-Length' headers indicating
payload MIME type [RFC2045] defined by the control package and the the payload MIME type [RFC2045] defined by the Control Package and
length of the payload, respectively. the length of the payload, respectively.
6.3.2.1. Reporting the Status of Extended Transactions 6.3.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within On receiving a CONTROL message, a Control Server MUST respond within
Transaction-Timeout with a status code for the request, as specified 'Transaction-Timeout' with a status code for the request, as
in Section 6.2. If the processing of the command completes within specified in Section 6.2. If the processing of the command completes
that time, a 200 response code MUST be sent. If the command does not within that time, a 200 response code MUST be sent. If the command
complete within that time, the response code 202 MUST be sent does not complete within that time, the response code 202 MUST be
indicating that the requested command is still being processed and sent indicating that the requested command is still being processed
the CONTROL transaction is being extended. The REPORT method is then and the CONTROL transaction is being extended. The REPORT method is
used to update and terminate the status of the extended transaction. then used to update and terminate the status of the extended
transaction. The Control Server should not wait until the last
The Control Server should not wait until the last possible possible opportunity to make the decision of issuing a 202 response
opportunity to make the decision of issuing a 202 response code and code and should ensure that it has plenty of time for the response to
should ensure that is has plenty for the response to arrive at the arrive at the Control Client. If it does not have time, transactions
Control Client. Not doing so will result in transactions being will be terminated (timed out) at the Control Client before
terminated (timed out) at the Control Client before completion. completion.
A Control Server issuing a 202 response MUST ensure the message A Control Server issuing a 202 response MUST ensure the message
contains a Timeout message header. This header MUST have a value in contains a 'Timeout' message header. This header MUST have a value
seconds that is the amount of time the recipient of the 202 message in seconds that is the amount of time the recipient of the 202
MUST wait before assuming that there has been a problem and message MUST wait before assuming that there has been a problem and
terminating the extended transaction and associated state. terminating the extended transaction and associated state.
The initial REPORT message MUST contain a 'Seq' (Sequence) message The initial REPORT message MUST contain a 'Seq' (Sequence) message
header with a value equal to '1'. Note - the 'Seq' numbers at both header with a value equal to '1'. Note: the 'Seq' numbers at both
Control Client and Control Server for framework messages are Control Client and Control Server for Framework messages are
independent. independent.
All REPORT messages for an extended CONTROL transaction MUST contain All REPORT messages for an extended CONTROL transaction MUST contain
a 'Timeout' message header. This header will contain a value in a 'Timeout' message header. This header will contain a value in
seconds that is the amount of time the recipient of the REPORT seconds that is the amount of time the recipient of the REPORT
message MUST wait before assuming that there has been a problem and message MUST wait before assuming that there has been a problem and
terminating the extended transaction and associated state. On terminating the extended transaction and associated state. On
receiving a REPORT message with a 'Status' header of 'update', the receiving a REPORT message with a 'Status' header of 'update', the
Control Client MUST reset the timer for the associated extended Control Client MUST reset the timer for the associated extended
CONTROL transaction to the indicated timeout period. If the timeout CONTROL transaction to the indicated timeout period. If the timeout
period approaches with no intended REPORT messages being generated, period approaches and no intended REPORT messages have been
the entity acting as a Control Framework UAS for the interaction MUST generated, the entity acting as a Control Framework UAS for the
generate a REPORT message containing, as defined in this paragraph, a interaction MUST generate a REPORT message containing, as defined in
'Status' header of 'update' with no associated payload. Such a this paragraph, a 'Status' header of 'update' with no associated
message acts as a timeout refresh and in no way impacts the extended payload. Such a message acts as a timeout refresh and in no way
transaction, because no message body or semantics are permitted. It impacts the extended transaction because no message body or semantics
is RECOMMENDED that a minimum value of 10 and a maximum value of 15 are permitted. It is RECOMMENDED that a minimum value of 10 and a
seconds be used for the value of the 'Timeout' message header. It is maximum value of 15 seconds be used for the value of the 'Timeout'
also RECOMMENDED that a Control Server refresh the timeout period of message header. It is also RECOMMENDED that a Control Server refresh
the CONTROL transaction at an interval that is not too close to the the timeout period of the CONTROL transaction at an interval that is
expiry time. A value of 80% of the timeout period could be used. not too close to the expiry time. A value of 80% of the timeout
For example, if the timeout period is 10 seconds, the Server would period could be used. For example, if the timeout period is 10
refresh the transaction after 8 seconds. seconds, the Server would refresh the transaction after 8 seconds.
Subsequent REPORT messages that provide additional information Subsequent REPORT messages that provide additional information
relating to the extended CONTROL transaction MUST also include and relating to the extended CONTROL transaction MUST also include and
increment by 1 the 'Seq' header value. A REPORT message received increment by 1 the 'Seq' header value. A REPORT message received
that has not been incremented by 1 MUST be responded to with a 406 that has not been incremented by 1 MUST be responded to with a 406
response and consider the extended transaction terminated. On response and the extended transaction MUST be considered terminated.
receiving a 406 response the extended transaction MUST be terminated. On receiving a 406 response, the extended transaction MUST be
REPORT messages MUST also include a 'Status' header with a value of terminated. REPORT messages MUST also include a 'Status' header with
'update'. These REPORT messages sent to update the extended CONTROL a value of 'update'. These REPORT messages sent to update the
transaction status MAY contain a message body, as defined by extended CONTROL transaction status MAY contain a message body, as
individual Control Packages and specified in Section 9.5. A REPORT defined by individual Control Packages and specified in Section 8.5.
message sent updating the extended transaction also acts as a timeout A REPORT message sent updating the extended transaction also acts as
refresh, as described earlier in this section. This will result in a a timeout refresh, as described earlier in this section. This will
transaction timeout period at the initiator of the original CONTROL result in a transaction timeout period at the initiator of the
request being reset to the interval contained in the 'Timeout' original CONTROL request being reset to the interval contained in the
message header. 'Timeout' message header.
When all processing for an extended CONTROL transaction has taken When all processing for an extended CONTROL transaction has taken
place, the entity acting as a Control Server MUST send a terminating place, the entity acting as a Control Server MUST send a terminating
REPORT message. The terminating REPORT message MUST increment the REPORT message. The terminating REPORT message MUST increment the
value in the 'Seq' message header by the value of '1' from 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 previous REPORT message. It MUST also include a 'Status' header with
a value of 'terminate' and MAY contain a message body. It MUST also a value of 'terminate' and MAY contain a message body. It MUST also
contain a 'Timeout' message header with a valid value. The inclusion contain a 'Timeout' message header with a valid value. The inclusion
of the 'Timeout' header is for consistency and its value is ignored. of the 'Timeout' header is for consistency, and its value is ignored.
A Control Framework UAC can then clean up any pending state A Control Framework UAC can then clean up any pending state
associated with the original control transaction. associated with the original CONTROL transaction.
6.3.3. K-ALIVE Transactions 6.3.3. K-ALIVE Transactions
The protocol defined in this document may be used in various network The protocol defined in this document may be used in various network
architectures. This includes a wide range of deployments where the architectures. This includes a wide range of deployments where the
clients could be co-located in a secured, private domain, or spread clients could be co-located in a secured, private domain, or spread
across disparate domains that require traversal of devices such as across disparate domains that require traversal of devices such as
Network Address Translators (NAT) and Firewalls. A keep-alive Network Address Translators (NATs) and firewalls. A keep-alive
mechanism enables the control channel to be kept active during times mechanism enables the Control Channel to be kept active during times
of inactivity. This is because many Firewalls have a timeout period of inactivity. This is because many firewalls have a timeout period
after which connections are closed. This mechanism also provides the after which connections are closed. This mechanism also provides the
ability for application level failure detection. It should be noted ability for application-level failure detection. It should be noted
that the following procedures apply only to the control channel being that the following procedures apply only to the Control Channel being
created. For details relating to the SIP keep alive mechanism, created. For details relating to the SIP keep-alive mechanism,
implementers should seek guidance from SIP Outbound [RFC5626]. implementers should seek guidance from SIP Outbound [RFC5626].
The following keep-alive procedures MUST be implemented. Specific The following keep-alive procedures MUST be implemented. Specific
deployments MAY choose not to use the keep alive mechanism if both 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 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- the keep-alive mechanism defined in this section, even when in a co-
located architecture, will reduce the ability to detect application located architecture, will reduce the ability to detect application-
level errors - especially during long periods of inactivity. level errors, especially during long periods of inactivity.
Once the SIP INVITE dialog usage has been established and the Once the SIP INVITE dialog usage has been established and the
underlying control channel has been set-up, including the initial underlying Control Channel has been set up, including the initial
correlation handshake using SYNC as discussed in Section 6, both correlation handshake using SYNC as discussed in Section 6, both
entities acting in the 'active' and 'passive' roles, as defined in entities acting in the active and passive roles, as defined in
COMEDIA [RFC4145], MUST start a keep alive timer equal to the value COMEDIA [RFC4145], MUST start a keep-alive timer equal to the value
negotiated during the control channel SYNC request/response exchange. negotiated during the Control Channel SYNC request/response exchange.
This is the value from the 'Keep-Alive' header in seconds. This is the value from the 'Keep-Alive' header in seconds.
6.3.3.1. Behaviour for an Entity in an Active Role 6.3.3.1. Behavior for an Entity in an Active Role
When acting in an active role, a K-ALIVE Control Framework message When in an active role, a K-ALIVE message MUST be generated before
MUST be generated before the local keep alive timer fires. An active the local keep-alive timer fires. An active entity is free to send
entity is free to send the K-ALIVE Control Framework message whenever the K-ALIVE message whenever it chooses. It is RECOMMENDED for the
it chooses. It is RECOMMENDED for the entity to issue a K-ALIVE entity to issue a K-ALIVE message after 80% of the local keep-alive
message after 80% of the local keep-alive timer. On receiving a 200 timer. On receiving a 200 OK Control Framework message for the
OK Control Framework message for the K-ALIVE request, the 'active' K-ALIVE request, the active entity MUST reset the local keep-alive
entity MUST reset the local keep alive timer. If no 200 OK response timer. If no 200 OK response is received to the K-ALIVE message, or
is received to the K-ALIVE Control Framework message, or a transport a transport-level problem is detected by some other means, before the
level problem is detected by some other means, before the local keep local keep-alive timer fires, the active entity MAY use COMEDIA re-
alive timer fires, the 'active' entity MAY use COMEDIA renegotiation negotiation procedures to recover the connection. Otherwise, the
procedures to recover the connection. Otherwise, the 'active' entity active entity MUST tear down the SIP INVITE dialog and recover the
MUST tear down the SIP INVITE dialog and recover the associated associated Control Channel resources.
control channel resources.
6.3.3.2. Behaviour for an Entity in a Passive Role 6.3.3.2. Behavior for an Entity in a Passive Role
When acting as a passive entity, a K-ALIVE Control Framework message When acting as a passive entity, a K-ALIVE message must be received
must be received before the local keep alive timer fires. When a before the local keep-alive timer fires. When a K-ALIVE request is
K-ALIVE request is received, the 'passive' entity MUST generate a 200 received, the passive entity MUST generate a 200 OK Control Framework
OK control framework response and reset the local keep alive-timer. response and reset the local keep-alive timer. No other Control
No other Control Framework response is valid. If no K-ALIVE message Framework response is valid. If no K-ALIVE message is received (or a
is received (or a transport level problem is detected by some other transport level problem is detected by some other means) before the
means) before the local keep alive timer fires, the 'passive' entity local keep-alive timer fires, the passive entity MUST tear down the
MUST tear down the SIP INVITE dialog and recover the associated SIP INVITE dialog and recover the associated Control Channel
control channel resources. resources.
6.3.4. SYNC Transactions 6.3.4. SYNC Transactions
The initial SYNC request on a control channel is used to negotiate The initial SYNC request on a Control Channel is used to negotiate
the timeout period for the control-channel keep alive mechanism and the timeout period for the Control Channel keep-alive mechanism and
to allow clients and servers to learn the Control Packages that each to allow clients and servers to learn the Control Packages that each
supports. Subsequent SYNC requests MAY be used to change the set of supports. Subsequent SYNC requests MAY be used to change the set of
Control Packages that can be used on the control-channel. Control Packages that can be used on the Control Channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction 6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the control- The initial SYNC request allows the timeout period for the Control
channel keep alive mechanism to be negotiated. The following rules Channel keep-alive mechanism to be negotiated. The following rules
MUST be followed for the initial SYNC request: MUST be followed for the initial SYNC request:
o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to active, the Keep-Alive header MUST be included o If the Client initiating the SDP offer has a COMEDIA 'setup'
in the SYNC message generated by the offerer. The value of the attribute equal to active, the 'Keep-Alive' header MUST be
Keep-Alive header SHOULD be in the range of 95 to 120 seconds included in the SYNC message generated by the offerer. The value
(this is consistent with SIP Outbound[RFC5626]). The value of the of the 'Keep-Alive' header SHOULD be in the range of 95 to 120
Keep-Alive header MUST NOT exceed 600 seconds. The client that seconds (this is consistent with SIP Outbound [RFC5626]). The
generated the SDP "Answer" (the passive client) MUST copy the value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The
Keep-Alive header into the 200 response to the SYNC message with client that generated the SDP "Answer" (the passive client) MUST
the same value. copy the 'Keep-Alive' header into the 200 response to the SYNC
o If the Client initiating the SDP Offer has a COMEDIA setup message with the same value.
attribute equal to passive, the Keep-Alive header parameter MUST
o If the Client initiating the SDP offer has a COMEDIA 'setup'
attribute equal to passive, the 'Keep-Alive' header parameter MUST
be included in the SYNC message generated by the answerer. The be included in the SYNC message generated by the answerer. The
value of the Keep-Alive header SHOULD be in the range of 95 to 120 value of the 'Keep-Alive' header SHOULD be in the range of 95 to
seconds. The client that generated the SDP Offer (the passive 120 seconds. The client that generated the SDP offer (the passive
client) MUST copy the Keep-Alive header into the 200 response to client) MUST copy the 'Keep-Alive' header into the 200 response to
the SYNC message with the same value. the SYNC message with the same value.
o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to actpass, the Keep-Alive header parameter MUST
be included in the SYNC message of the entity who is the active
participant in the SDP session. If the client generating the
subsequent SDP answer places a value of active in the COMEDIA SDP
setup attribute, it will generate the SYNC request and include the
Keep-Alive header. The value SHOULD be in the range 95 to 120
seconds. If the client generating the subsequent SDP answer
places a value of passive in the COMDEDIA setup attribute, the
original UA making the SDP will generate the SYNC request and
include the Keep-Alive header. The value SHOULD be in the range
95 to 120 seconds.
o If the initial negotiated offer/answer results in a COMEDIA setup
attribute equal to holdconn, the initial SYNC mechanism will occur
when the offer/answer exchange is updated and active/passive roles
are resolved using COMEDIA.
The previous steps ensures that the entity initiating the control o If the Client initiating the SDP offer has a COMEDIA 'setup'
channel connection is always the one specifying the keep alive attribute equal to 'actpass', the 'Keep-Alive' header parameter
MUST be included in the SYNC message of the entity who is the
active participant in the SDP session. If the client generating
the subsequent SDP answer places a value of 'active' in the
COMEDIA SDP 'setup' attribute, it will generate the SYNC request
and include the 'Keep-Alive' header. The value SHOULD be in the
range 95 to 120 seconds. If the client generating the subsequent
SDP answer places a value of 'passive' in the COMEDIA 'setup'
attribute, the original UA making the SDP will generate the SYNC
request and include the 'Keep-Alive' header. The value SHOULD be
in the range 95 to 120 seconds.
o If the initial negotiated offer/answer results in a COMEDIA
'setup' attribute equal to 'holdconn', the initial SYNC mechanism
will occur when the offer/answer exchange is updated and the
active/passive roles are resolved using COMEDIA.
The previous steps ensure that the entity initiating the Control
Channel connection is always the one specifying the keep-alive
timeout period. It will always be the initiator of the connection timeout period. It will always be the initiator of the connection
who generates the K-ALIVE Control Framework level messages. who generates the K-ALIVE messages.
Once negotiated, the keep-alive timeout applies for the remainder of Once negotiated, the keep-alive timeout applies for the remainder of
the Control Framework session. Any subsequent SYNC messages the Control Framework session. Any subsequent SYNC messages
generated in the control channel do not impact the negotiated keep generated in the Control Channel do not impact the negotiated keep-
alive property of the session. The Keep-Alive header MUST NOT be alive property of the session. The 'Keep-Alive' header MUST NOT be
included in subsequent SYNC messages and if it is received it MUST be included in subsequent SYNC messages, and if it is received, it MUST
ignored. be ignored.
6.3.4.2. Package Negotiation 6.3.4.2. Package Negotiation
As part of the SYNC message exchange a client generating the request As part of the SYNC message exchange, a client generating the request
MUST include a Packages header, as defined in Section 9. The MUST include a 'Packages' header, as defined in Section 9. The
Packages header contains a list of all Control Framework packages 'Packages' header contains a list of all Control Framework packages
that can be supported within this control session, from the that can be supported within this control session, from the
perspective of the client creating the SYNC message. All Channel perspective of the client creating the SYNC message. All Channel
Framework package names MUST be tokens that adhere to the rules set Framework package names MUST be tokens that adhere to the rules set
out in Section 8. The Packages header of the initial SYNC message out in Section 8. The 'Packages' header of the initial SYNC message
MUST contain at least one value. MUST contain at least one value.
A server receiving the initial SYNC request MUST examine the contents A server receiving the initial SYNC request MUST examine the contents
of the Packages header. If the server supports at least one of the of the 'Packages' header. If the server supports at least one of the
packages listed in the request, it MUST respond with a 200 response packages listed in the request, it MUST respond with a 200 response
code. The response MUST contain a Packages header that lists the code. The response MUST contain a 'Packages' header that lists the
supported packages that are in common with those from the Packages supported packages that are in common with those from the 'Packages'
header of the request (either all or a subset). This list forms a header of the request (either all or a subset). This list forms a
common set of Control Packages that are supported by both parties. common set of Control Packages that are supported by both parties.
Any Control Packages supported by the server that are not listed in Any Control Packages supported by the server that are not listed in
the Packages header of the SYNC request, MAY be placed in the the 'Packages' header of the SYNC request MAY be placed in the
Supported header of the response. This provides a hint to the client 'Supported' header of the response. This provides a hint to the
that generated the SYNC request of additional packages supported by client that generated the SYNC request about additional packages
the server. supported by the server.
If no common packages are supported by the server receiving the SYNC If no common packages are supported by the server receiving the SYNC
message, it MUST respond with a 422 error response code. The error message, it MUST respond with a 422 error response code. The error
response MUST contain a Supported header indicating the packages that response MUST contain a 'Supported' header indicating the packages
are supported. The initiating client can then choose to either re- that are supported. The initiating client can then choose to either
submit a new SYNC message based on the 422 response or consider the re-submit a new SYNC message based on the 422 response or consider
interaction as a failure. This would lead to termination of the the interaction a failure. This would lead to termination of the
associated SIP INVITE dialog by sending a SIP BYE request, as per associated SIP INVITE dialog by sending a SIP BYE request, as per
[RFC3261]. [RFC3261].
Once the initial SYNC transaction is completed, either client MAY Once the initial SYNC transaction is completed, either client MAY
choose to send a subsequent new SYNC Control Framework message to re- choose to send a subsequent new SYNC message to re-negotiate the
negotiate the packages that are supported within the control channel. packages that are supported within the Control Channel. A new SYNC
A new SYNC message whose Packages header has different values from message whose 'Packages' header has different values from the
the previous SYNC message can effectively add and delete the packages previous SYNC message can effectively add and delete the packages
used in the control channel. If a client receiving a subsequent SYNC 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 message does not wish to change the set of packages, it MUST respond
with a 421 Control Framework response code. Subsequent SYNC messages with a 421 Control Framework response code. Subsequent SYNC messages
MUST NOT change the value of the Dialog-ID and Keep-Alive Control MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control
Framework headers that appeared in the original SYNC negotiation. Framework headers that appeared in the original SYNC negotiation.
An entity MAY honour Control Framework commands relating to a Control An entity MAY honor Control Framework commands relating to a Control
Package it no longer supports after package re-negotiation. When the Package it no longer supports after package re-negotiation. When the
entity does not wish to honour such commands, it MUST respond to the entity does not wish to honor such commands, it MUST respond to the
request with a 420 response. request with a 420 response.
7. Response Code Descriptions 7. Response Code Descriptions
The following response codes are defined for transaction responses to The following response codes are defined for transaction responses to
methods defined in Section 6.1. All response codes in this section 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 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 REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message. to a REPORT message.
Note that these response codes apply to Framework Transactions only. Note that these response codes apply to Framework Transactions only.
Success or error indications for Control Commands MUST be treated as
Success or error indications for control commands MUST be treated as the result of a Control Command and returned in either a 200 response
the result of a control command and returned in either a 200 response
or REPORT message. or REPORT message.
7.1. 200 Response Code 7.1. 200 Response Code
The 200 response code indicates the completion of a successful The framework protocol transaction completed successfully.
framework protocol transaction.
7.2. 202 Response Code 7.2. 202 Response Code
The 202 response code indicates the completion of a successful The framework protocol transaction completed successfully and
framework protocol transaction with additional information to be additional information will be provided at a later time through the
provided at a later time through the REPORT mechanism defined in REPORT mechanism defined in Section 6.3.2.
Section 6.3.2.
7.3. 400 Response Code 7.3. 400 Response Code
The 400 response code indicates that the request was syntactically The request was syntactically incorrect.
incorrect.
7.4. 403 Response Code 7.4. 403 Response Code
The server understood the request, but is refusing to fulfil it. The The server understood the request, but is refusing to fulfill it.
client SHOULD NOT repeat the request. The client SHOULD NOT repeat the request.
7.5. 405 Response Code 7.5. 405 Response Code
Method not allowed. The primitive is not supported. Method not allowed. The primitive is not supported.
7.6. 406 Response Code 7.6. 406 Response Code
Message out of sequence. Message out of sequence.
7.7. 420 Response Code 7.7. 420 Response Code
skipping to change at page 27, line 11 skipping to change at page 26, line 7
Recipient does not support any Control Packages listed in the SYNC Recipient does not support any Control Packages listed in the SYNC
message. message.
7.10. 423 Response Code 7.10. 423 Response Code
Recipient has an existing transaction with the same transaction ID. Recipient has an existing transaction with the same transaction ID.
7.11. 481 Response Code 7.11. 481 Response Code
The 481 response indicates that the transaction of the request does The transaction of the request does not exist. In response to a SYNC
not exist. In response to a SYNC request, it indicates that the request, the 481 response code indicates that the corresponding SIP
corresponding SIP INVITE dialog usage does not exist. INVITE dialog usage does not exist.
7.12. 500 Response Code 7.12. 500 Response Code
The 500 response indicates that the recipient does not understand the The recipient does not understand the request.
request
8. Control Packages 8. Control Packages
Control Packages specify behavior that extends the capability defined Control Packages specify behavior that extends the capability defined
in this document. Control Packages MUST NOT weaken MUST and SHOULD in this document. Control Packages MUST NOT weaken statements of
strength statements in this document. A Control Package MAY "MUST" and "SHOULD" strength in this document. A Control Package MAY
strengthen "SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified
by the specific usage of the framework. by the specific usage of the framework.
In addition to the usual sections expected in a standards-track RFC In addition to the usual sections expected in Standards-Track RFCs
and SIP extension documents, authors of Control Packages need to and SIP extension documents, authors of Control Packages need to
address each of the issues detailed in the following subsections. address each of the issues detailed in the following sub-sections.
The following sections MUST be used as a template and included The following sections MUST be used as a template and included
appropriately in all Control-Packages specifications. To reiterate, appropriately in all Control-Package specifications. To reiterate,
the following sections do not solely form the basis of all Control- the following sections do not solely form the basis of all Control-
Package specification but are included as a minimum to provide Package specifications but are included as a minimum to provide
essential package level information. A Control-Package specification essential package-level information. A Control-Package specification
can take any valid form it wishes as long as it includes at least the can take any valid form it wishes as long as it includes at least the
following information listed in this section. following information listed in this section.
8.1. Control Package Name 8.1. Control Package Name
This section MUST be present in all extensions to this document and This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the include information that appears in the IANA registration of the
token. Information on registering control package tokens is token. Information on registering Control Package tokens is
contained in Section 13. contained in Section 13.
8.2. Framework Message Usage 8.2. Framework Message Usage
The Control Framework defines a number of message primitives that can The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no be used to exchange commands and information. There are no
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document MUST Control Channel. This section of a Control Package document MUST
explicitly detail the control messages that can be used as well as explicitly detail the types of Framework messages (Methods) that can
provide an indication of directionality between entities. This will be used as well as provide an indication of directionality between
include which role type is allowed to initiate a request type. entities. This will include which role type is allowed to initiate a
request type.
8.3. Common XML Support 8.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required, as attributes for media dialog or conference reference are required, as
defined and discussed in Section 17.1 in Appendix A. The Control defined and discussed in Appendix A.1. The Control Package will make
Package will make strong statements (using language from RFC 2119 strong statements (using language from RFC 2119 [RFC2119]) if the XML
[RFC2119]) if the XML schema defined in Section 17.1 in Appendix A is schema defined in Appendix A.1 is to be supported. If only part of
to be supported. If only part of the schema is required (for example the schema is required (for example, just 'connectionid' or
just 'connectionid' or just conferenceid), the Control Package will 'conferenceid'), the Control Package will make equally strong
make equally strong (using language from RFC 2119 [RFC2119]) statements (using language from RFC 2119 [RFC2119]).
statements.
8.4. CONTROL Message Bodies 8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 6, or that no control package body is required. This section Section 6, or that no Control Package body is required. This section
MUST indicate the location of detailed syntax definitions and MUST indicate the location of detailed syntax definitions and
semantics for the appropriate MIME[RFC2045] body type that apply to a semantics for the appropriate MIME [RFC2045] body type that apply to
CONTROL command request and optionally the associated 200 response. a CONTROL command request and, optionally, the associated 200
For Control Packages that do not have a control package body, stating response. For Control Packages that do not have a Control Package
such satisfies the MUST strength of this section in the Control body, making such a statement satisfies the "MUST" strength of this
Package document. section in the Control Package document.
8.5. REPORT Message Bodies 8.5. REPORT Message Bodies
This mandatory section of a Control Package defines the REPORT body This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in that can be contained within a REPORT command request, as defined in
Section 6, or that no report package body is required. This section Section 6, or that no report package body is required. This section
MUST indicate the location of detailed syntax definitions and MUST indicate the location of detailed syntax definitions and
semantics for the appropriate MIME[RFC2045] body type. It should be semantics for the appropriate MIME [RFC2045] body type. It should be
noted that the Control Framework specification does allow for noted that the Control Framework specification does allow for
payloads to exist in 200 responses to CONTROL messages (as defined in payloads to exist in 200 responses to CONTROL messages (as defined in
this document). An entity that is prepared to receive a payload type 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 REPORT message MUST also be prepared to receive the same payload
in a 200 response to a CONTROL message. For Control Packages that do in a 200 response to a CONTROL message. For Control Packages that do
not have a control package body, stating such satisfies the MUST not have a Control Package body, stating such satisfies the "MUST"
strength of this section in the Control Package document. strength of this section in the Control Package document.
8.6. Audit 8.6. Audit
Auditing of various control package properties such as capabilities Auditing of various Control Package properties such as capabilities
and resources (meta package level information) is extremely useful. and resources (package-level meta-information) is extremely useful.
Such meta-data usually has no direct impact on Control Framework
Such meta-data usually has no direct impact on control framework
interactions but allows for contextual information to be learnt. interactions but allows for contextual information to be learnt.
Control Packages are encouraged to make use of Control Framework Control Packages are encouraged to make use of Control Framework
interactions to provide relevant package audit information. interactions to provide relevant package audit information.
This section SHOULD include information including: This section SHOULD include the following information:
o If an auditing capability is available in this package. 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 o How auditing information is triggered (for example, using a
Framework 200 response). 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 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 payload (for example, it could be a separate XML schema OR part of
a larger XML schema). a larger XML schema).
8.7. Examples 8.7. Examples
It is strongly RECOMMENDED that Control Packages provide a range of It is strongly RECOMMENDED that Control Packages provide a range of
message flows that represent common flows using the package and this message flows that represent common flows using the package and this
framework document. framework document.
9. Formal Syntax 9. Formal Syntax
9.1. Control Framework Formal Syntax 9.1. Control Framework Formal Syntax
The Control Framework interactions use the UTF-8 transformation The Control Framework interactions use the UTF-8 transformation
format as defined in [RFC3629]. The syntax in this section uses the format as defined in [RFC3629]. The syntax in this section uses the
Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including
types 'DIGIT', 'CRLF', 'ALPHA', . types 'DIGIT', 'CRLF', and 'ALPHA'.
Unless otherwise stated in the definition of a particular header Unless otherwise stated in the definition of a particular header
field, field values, parameter names, and parameter values are case field, field values, parameter names, and parameter values are not
in-sensitive case-sensitive.
control-req-or-resp = control-request / control-response control-req-or-resp = control-request / control-response
control-request = control-req-start *headers CRLF [control-content] control-request = control-req-start *headers CRLF [control-content]
control-response = control-resp-start *headers CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content]
control-req-start = pCFW SP trans-id SP method CRLF control-req-start = pCFW SP trans-id SP method CRLF
control-resp-start = pCFW SP trans-id SP status-code CRLF control-resp-start = pCFW SP trans-id SP status-code CRLF
pCFW = %x43.46.57; CFW in caps pCFW = %x43.46.57; CFW in caps
trans-id = alpha-num-token trans-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps
mSYNC = %x53.59.4E.43; SYNC in caps mSYNC = %x53.59.4E.43 ; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45; K-ALIVE in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF headers = header-name CRLF
header-name = (Content-Length header-name = (Content-Length
/Content-Type /Content-Type
/Control-Package /Control-Package
/Status /Status
/Seq /Seq
/Timeout /Timeout
/Dialog-ID /Dialog-ID
/Packages /Packages
skipping to change at page 30, line 43 skipping to change at page 29, line 40
supprtd-alphanum = alpha-num-token supprtd-alphanum = alpha-num-token
kalive-seconds = 1*DIGIT kalive-seconds = 1*DIGIT
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/" alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
control-content = *OCTET control-content = *OCTET
Content-Type = "Content-Type:" SP media-type Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *(SP ";" gen-param ) media-type = type "/" subtype *(SP ";" gen-param )
type = token ;section 4.2 of RFC 4288 type = token ; Section 4.2 of RFC 4288
subtype = token ;section 4.2 of RFC 4288 subtype = token ; Section 4.2 of RFC 4288
gen-param = pname [ "=" pval ] gen-param = pname [ "=" pval ]
pname = token pname = token
pval = token / quoted-string pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E) / %x30-39 / %x41-5A / %x5E-7E)
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
skipping to change at page 31, line 20 skipping to change at page 30, line 20
UPALPHA = %x41-5A UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT ALPHANUM = ALPHA / DIGIT
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
hname = ALPHA *token hname = ALPHA *token
hval = utf8text hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UPALPHA = %x41-5A UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4; From RFC 3629
The following table details a summary of the headers that can be The following table details a summary of the headers that can be
contained in Control Framework interactions. The "where" columns contained in Control Framework interactions.
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 Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________ ___________________________________________________________
Content-Length o o - - Content-Length o o - -
Control-Package R m - - - Control-Package R m - - -
Seq - m - - Seq - m - -
Status R - m - - Status R - m - -
Timeout R - m - - Timeout R - m - -
Timeout 202 - m - - Timeout 202 - m - -
Dialog-ID R - - m - Dialog-ID R - - m -
Packages - - m - Packages - - m -
Supported r - - o - Supported r - - o -
Keep-Alive R - - o - Keep-Alive R - - o -
Content-Type o o - - Content-Type o o - -
Figure 3: Table 1 Table 1: Summary of Headers in Control Framework Interactions
The notation used in Table 1 is as follows:
R: header field may only appear in requests.
r: header field may only appear in responses.
2xx, 4xx, etc.: response codes with which the header field can be used.
[blank]: header field may appear in either requests or responses.
m: header field is mandatory.
o: header field is optional.
-: header field is not applicable (ignored if present).
9.2. Control Framework Dialog Identifier SDP Attribute 9.2. Control Framework Dialog Identifier SDP Attribute
This specification defines a new media-level value attribute: This specification defines a new media-level value attribute:
'cfw-id'. Its formatting in SDP is described by the following 'cfw-id'. Its formatting in SDP is described by the following ABNF
ABNF[RFC5234]. [RFC5234].
cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF
cfw-id-name = token cfw-id-name = token
token = 1*(token-char) token = 1*(token-char)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E / %x41-5A / %x5E-7E
The token-char and token elements are defined in [RFC4566] but The token-char and token elements are defined in [RFC4566] but
included here to provide support for the implementer of this SDP included here to provide support for the implementer of this SDP
feature. feature.
10. Examples 10. Examples
The following examples provide an abstracted flow of Control Channel The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document. Control Framework interactions defined in this document.
In this example, the Control Client establishes a control channel, In this example, the Control Client establishes a Control Channel,
SYNCs with the Control Server, and issues a CONTROL request that SYNCs with the Control Server, and issues a CONTROL request that
can't be completed within the 'Transaction-Timeout', so the Control can't be completed within the 'Transaction-Timeout', so the Control
Server returns a 202 response code to extend the transaction. The Server returns a 202 response code to extend the transaction. The
Control Server then follows with REPORTs until the requested action Control Server then follows with REPORTs until the requested action
has been completed. The SIP INVITE dialog is then terminated. has been completed. The SIP INVITE dialog is then terminated.
Control Client Control Server Control Client Control Server
| | | |
| (1) SIP INVITE | | (1) SIP INVITE |
| ----------------------------------------> | | ----------------------------------------> |
skipping to change at page 33, line 33 skipping to change at page 32, line 29
| | | |
| (4) SYNC | | (4) SYNC |
| ----------------------------------------> | | ----------------------------------------> |
| | | |
| (5) 200 | | (5) 200 |
| <--------------------------------------- | | <--------------------------------------- |
| | | |
| (6) CONTROL | | (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 (1) Control Client-->Control Server (SIP): INVITE
sip:control-server@example.com sip:control-server@example.com
INVITE sip:control-server@example.com SIP/2.0 INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@example.com> To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com> Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 206 Content-Length: 206
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 controller.example.com o=originator 2890844526 2890842808 IN IP4 controller.example.com
s=- s=-
c=IN IP4 control-client.example.com c=IN IP4 control-client.example.com
m=application 49153 TCP cfw m=application 49153 TCP cfw
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cfw-id:fndskuhHKsd783hjdla a=cfw-id:fndskuhHKsd783hjdla
(2) Control Server-->Control Client (SIP): 200 OK
2. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc2.example.com> Contact: <sip:control-server@pc2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 203 Content-Length: 203
v=0 v=0
o=responder 2890844600 2890842900 IN IP4 controller.example.com o=responder 2890844600 2890842900 IN IP4 controller.example.com
s=- s=-
c=IN IP4 control-server.example.com c=IN IP4 control-server.example.com
m=application 49153 TCP cfw m=application 49153 TCP cfw
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=cfw-id:7JeDi23i7eiysi32 a=cfw-id:7JeDi23i7eiysi32
3. Control Client->Control Server (SIP): ACK (3) Control Client-->Control Server (SIP): ACK
4. Control Client opens a TCP connection to the Control Server.
The connection can now be used to exchange control framework (4) Control Client opens a TCP connection to the Control Server.
messages. Control Client-->Control Server (Control Framework The connection can now be used to exchange Control Framework
Message): SYNC. messages. Control Client-->Control Server (Control Framework
message): SYNC.
CFW 8djae7khauj SYNC CFW 8djae7khauj SYNC
Dialog-ID: fndskuhHKsd783hjdla Dialog-ID: fndskuhHKsd783hjdla
Keep-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
5. Control Server-->Control Client (Control Framework Message): (5) Control Server-->Control Client (Control Framework message):
200. 200.
CFW 8djae7khauj 200 CFW 8djae7khauj 200
Keep-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/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 (6) Once the SYNC process has completed, the connection can now be
used to exchange control framework messages. Control used to exchange Control Framework messages. Control
Client-->Control Server (Control Framework Message): CONTROL. Client-->Control Server (Control Framework message): CONTROL.
CFW i387yeiqyiq CONTROL CFW i387yeiqyiq CONTROL
Control-Package: <package-name> Control-Package: <package-name>
Content-Type: example_content/example_content Content-Type: example_content/example_content
Content-Length: 11 Content-Length: 11
<XML BLOB/> <XML BLOB/>
7. Control Server-->Control Client (Control Framework Message): (7) Control Server-->Control Client (Control Framework message):
202. 202.
CFW i387yeiqyiq 202 CFW i387yeiqyiq 202
Timeout: 10 Timeout: 10
8. Control Server-->Control Client (Control Framework Message): (8) Control Server-->Control Client (Control Framework message):
REPORT. REPORT.
CFW i387yeiqyiq REPORT CFW i387yeiqyiq REPORT
Seq: 1 Seq: 1
Status: update Status: update
Timeout: 10 Timeout: 10
9. Control Client-->Control Server (Control Framework Message): (9) Control Client-->Control Server (Control Framework message):
200. 200.
CFW i387yeiqyiq 200 CFW i387yeiqyiq 200
Seq: 1 Seq: 1
10. Control Server-->Control Client (Control Framework Message): (10) Control Server-->Control Client (Control Framework message):
REPORT. REPORT.
CFW i387yeiqyiq REPORT CFW i387yeiqyiq REPORT
Seq: 2 Seq: 2
Status: update Status: update
Timeout: 10 Timeout: 10
Content-Type: example_content/example_content Content-Type: example_content/example_content
Content-Length: 11 Content-Length: 11
<XML BLOB/> <XML BLOB/>
11. Control Client-->Control Server (Control Framework Message): (11) Control Client-->Control Server (Control Framework message):
200. 200.
CFW i387yeiqyiq 200 CFW i387yeiqyiq 200
Seq: 2 Seq: 2
12. Control Server-->Control Client (Control Framework Message):
REPORT. (12) Control Server-->Control Client (Control Framework message):
REPORT.
CFW i387yeiqyiq REPORT CFW i387yeiqyiq REPORT
Seq: 3 Seq: 3
Status: terminate Status: terminate
Timeout: 10 Timeout: 10
Content-Type: example_content/example_content Content-Type: example_content/example_content
Content-Length: 11 Content-Length: 11
<XML BLOB/> <XML BLOB/>
13. Control Client-->Control Server (Control Framework Message): (13) Control Client-->Control Server (Control Framework message):
200. 200.
CFW i387yeiqyiq 200 CFW i387yeiqyiq 200
Seq: 3 Seq: 3
14. Control Client->Control Server (SIP): BYE (14) Control Client-->Control Server (SIP): BYE
BYE sip:control-server@pc2.example.com SIP/2.0 BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498 From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE CSeq: 2 BYE
Max-Forwards: 70 Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com> Contact: <sip:control-client@pc1.example.com>
Content-Length: 0 Content-Length: 0
15. Control Server->Control Client (SIP): 200 OK (15) Control Server-->Control Client (SIP): 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498 From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5
CSeq: 2 BYE CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc1.example.com> Contact: <sip:control-server@pc1.example.com>
Content-Length: 0 Content-Length: 0
11. Extensibility 11. Extensibility
The Media Control Channel Framework was designed to be only minimally The Media Control Channel Framework was designed to be only minimally
extensible. New methods, header fields, and status codes can be extensible. New methods, header fields, and status codes can be
defined in standards-track RFCs. The Media Control Channel Framework defined in Standards-Track RFCs. The Media Control Channel Framework
does not contain a version number or any negotiation mechanism to does not contain a version number or any negotiation mechanism to
require or discover new features. If an extension is specified in require or discover new features. If an extension is specified in
the future that requires negotiation, the specification will need to the future that requires negotiation, the specification will need to
describe how the extension is to be negotiated in the encapsulating describe how the extension is to be negotiated in the encapsulating
signaling protocol. If a non-interoperable update or extension signaling protocol. If a non-interoperable update or extension
occurs in the future, it will be treated as a new protocol, and MUST occurs in the future, it will be treated as a new protocol, and it
describe how its use will be signaled. MUST describe how its use will be signaled.
In order to allow extension header fields without breaking In order to allow extension header fields without breaking
interoperability, if an Media Control Channel device receives a interoperability, if a Media Control Channel device receives a
request or response containing a header field that it does not request or response containing a header field that it does not
understand, it MUST ignore the header field and process the request understand, it MUST ignore the header field and process the request
or response as if the header field was not present. If a Media or response as if the header field was not present. If a Media
Control Channel device receives a request with an unknown method, it Control Channel device receives a request with an unknown method, it
MUST return a 500 response. MUST return a 500 response.
12. Security Considerations 12. Security Considerations
The Channel Framework provides confidentiality and integrity for the The Channel Framework provides confidentiality and integrity for the
messages it transfers. It also provides assurances that the messages it transfers. It also provides assurances that the
connected host is the host that it meant to connect to and that the connected host is the host that it meant to connect to and that the
connection has not been hijacked, as discussed in the remainder of connection has not been hijacked, as discussed in the remainder of
this section. this section.
The Channel Framework in design complies with the security-related In design, the Channel Framework complies with the security-related
requirements documented in the control protocol requirements requirements documented in "Media Server Control Protocol
document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12 Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12,
REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by
the Channel Framework are summarized in the following subsections. the Channel Framework are summarized in the following sub-sections.
12.1. Session Establishment 12.1. Session Establishment
Channel Framework sessions are established as media sessions Channel Framework sessions are established as media sessions
described by SDP within the context of a SIP INVITE dialog. In order described by SDP within the context of a SIP INVITE dialog. In order
to ensure secure rendezvous between Control Framework clients and to ensure secure rendezvous between Control Framework clients and
servers, the Media Channel Control Framework should make full use of servers, the Media Channel Control Framework should make full use of
mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP mechanisms provided by SIP. The use of the 'cfw-id' SDP attribute
attribute results in important session information being carried results in important session information being carried across the SIP
across the SIP network. For this reason SIP clients using this network. For this reason, SIP clients using this specification MUST
specification MUST use appropriate security mechanisms, such as use appropriate security mechanisms, such as TLS [RFC5246] and SMIME
TLS[RFC5246] and SMIME[RFC5751], when deployed in open networks. [RFC5751], when deployed in open networks.
12.2. Transport Level Protection 12.2. Transport-Level Protection
When using only TCP connections, the Channel Framework security is When using only TCP connections, the Channel Framework security is
weak. Although the Channel Framework requires the ability to protect weak. Although the Channel Framework requires the ability to protect
this exchange, there is no guarantee that the protection will be used 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 all the time. If such protection is not used, anyone can see data
exchanges. exchanges.
Sensitive data, such as private and financial data, is carried over Sensitive data, such as private and financial data, is carried over
the Control Framework channel. Clients and servers must be properly the Control Framework channel. Clients and servers must be properly
authenticated/authorized and the control channel must permit the use authenticated/authorized and the Control Channel must permit the use
of confidentiality, replay protection and integrity for the data. To of confidentiality, replay protection, and integrity protection for
ensure control channel protection, Control Framework clients and the data. To ensure Control Channel protection, Control Framework
servers MUST support TLS and SHOULD use it by default unless clients and servers MUST support TLS and SHOULD use it by default
alternative control channel protection is used or a protected unless alternative Control Channel protection is used or a protected
environment is guaranteed by the administrator of the network. environment is guaranteed by the administrator of the network.
Alternative control channel protection MAY be used if desired Alternative Control Channel protection MAY be used if desired (e.g.,
(e.g.IPsec[RFC5246]). IPsec [RFC5246]).
TLS is used to authenticate devices and to provide integrity, replay TLS is used to authenticate devices and to provide integrity, replay
protection and confidentiality for the header fields being protection, and confidentiality for the header fields being
transported on the control channel. Channel Framework elements MUST transported on the Control Channel. Channel Framework elements MUST
implement TLS and MUST also implement the TLS ClientExtendedHello implement TLS and MUST also implement the TLS ClientExtendedHello
extended hello information for server name indication as described in extended hello information for server name indication as described in
[RFC5246]. A TLS cipher-suite of [RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other [RFC3261] MUST be supported. Other cipher-suites MAY also be
cipher-suites MAY also be supported. supported.
When a TLS client establishes a connection with a server, it is When a TLS client establishes a connection with a server, it is
presented with the server's X.509 certificate. Authentication presented with the server's X.509 certificate. Authentication
proceeds as described in Section 7.3 ("Client behavior") of RFC 5922 proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922
[RFC5922]. [RFC5922].
A TLS server conformant to this specification MUST ask for a client A TLS server conformant to this specification MUST ask for a client
certificate; if the client possesses a certificate, it will be certificate; if the client possesses a certificate, it will be
presented to the server for mutual authentication, and authentication presented to the server for mutual authentication, and authentication
proceeds as described in Section 7.4 ("Server behavior") of RFC 5922 proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922
[RFC5922]. [RFC5922].
12.3. Control Channel Policy Management 12.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control This specification permits the establishment of a dedicated Control
channel using SIP. It is also permitted for entities to create Channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create general solution, the ability for multiple entities to create
connections and have access to resources could be the cause of connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to this document does not carry any specific mechanism to overcome such
overcome such conflicts but will provide a summary of how it can be conflicts but will provide a summary of how to do so.
achieved.
It can be determined that access to resources and use of control It can be determined that access to resources and use of Control
channels relates to policy. It can be considered implementation and Channels relate to policy. It can be considered implementation and
deployment detail that dictates the level of policy that is adopted. deployment detail that dictates the level of policy that is adopted.
The authorization and associated policy of a Control Channel can be
The authorization and associated policy of a control channel can be
linked to the authentication mechanisms described in this section. linked to the authentication mechanisms described in this section.
For example, strictly authenticating a control channel using TLS For example, strictly authenticating a Control Channel using TLS
authentication allows entities to protect resources and ensure the authentication allows entities to protect resources and ensure the
required level of granularity. Such policy can be applied at the required level of granularity. Such policy can be applied at the
package level or even as low as a structure like a conference package level or even as low as a structure like a conference
instance (control channel X is not permitted to issue commands for instance (Control Channel X is not permitted to issue commands for
control package y OR control channel A is not permitted to issue Control Package y OR Control Channel A is not permitted to issue
commands for conference instance B). Systems should ensure that if commands for conference instance B). Systems should ensure that, if
required, an appropriate policy framework is adopted to satisfy the required, an appropriate policy framework is adopted to satisfy the
requirements for implemented packages. The most robust form of requirements for implemented packages. The most robust form of
policy can be achieved using a strong authentication mechanism such policy can be achieved using a strong authentication mechanism such
as mutual TLS authentication on the control channel. This as mutual TLS authentication on the Control Channel. This
specification provide a control channel response code(403) to specification provides a Control Channel response code (403) to
indicate to the issuer of a command that it is not permitted. The indicate to the issuer of a command that it is not permitted. The
403 response MUST be issued to control framework requests that are 403 response MUST be issued to Control Framework requests that are
not permitted under the implemented policy. If a 403 response is not permitted under the implemented policy. If a 403 response is
received a control framework client MAY choose to re-submit the received, a Control Framework client MAY choose to re-submit the
request with differing requirements or the request is abandoned. The request with differing requirements or to abandon the request. The
403 response does not provide any additional information on the 403 response does not provide any additional information on the
policy failure due to the generic nature of this specification. policy failure due to the generic nature of this specification.
Individual control packages can supply additional information if Individual Control Packages can supply additional information if
required. The mechanism for providing such additional information is required. The mechanism for providing such additional information is
not mandated in this specification. It should be noted that not mandated in this specification. It should be noted that
additional policy requirements to those covered in this section might additional policy requirements to those covered in this section might
be defined and applied in individual packages that specify a finer be defined and applied in individual packages that specify a finer
granularity for access to resources etc. granularity for access to resources, etc.
13. IANA Considerations 13. IANA Considerations
This specification instructs IANA to create a new registry for SIP IANA has created a new registry for SIP Control Framework parameters.
Control Framework parameters. The Channel Framework Parameter The "Media Control Channel Framework Parameters" registry is a
registry is a container for sub-registries. This section further container for sub-registries. This section further introduces sub-
introduces sub-registries for Channel Framework packages, method registries for control packages, method names, status codes, header
names, status codes, header field names, port and transport protocol. field names, and port and transport protocol.
Additionally, Section 13.6 registers a new new MIME type for use with Additionally, Section 13.6 registers a new MIME type for use with
SDP.. SDP.
For all registries and sub-registries created by this document, the
policy applied when creating a new registration is also applied when
changing an existing registration.
13.1. Control Packages Registration Information 13.1. Control Packages Registration Information
This specification establishes the Control Packages sub-registry This specification establishes the Control Packages sub-registry
under Control Framework Packages. New parameters in this sub- under Media Control Channel Framework Packages. New parameters in
registry must be published in an RFC (either as an IETF submission or this sub-registry must be published in an RFC (either in the IETF
RFC Editor submission), using the IANA policy [RFC5226] "RFC stream or Independent Submission stream), using the IANA policy
Required". [RFC5226] "RFC Required".
As this document specifies no package or template-package names, the As this document specifies no package or template-package names, the
initial IANA registration for control packages will be empty. 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 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 information to be maintained by the IANA.
three possible permutations of package type, contact, and reference.
The table below lists the control packages defined in the "Media The table below lists the Control Packages defined in the "Media
Control Channel Framework". Control Channel Framework".
Package Name Reference Package Name Reference
------------ --------- ------------ ---------
example1 [RFCXXXX] example1 [RFCXXXX]
13.1.1. Control Package Registration Template 13.1.1. Control Package Registration Template
Package Name: Package Name:
(Package names must conform to the syntax described in (Package names must conform to the syntax described in
section 8.1.) Section 8.1.)
Published Specification(s): Published Specification(s):
(Control packages require a published RFC.). (Control Packages require an RFC.)
Person & email address to contact for further information: Person & email address to contact for further information:
13.2. Control Framework Method Names 13.2. Control Framework Method Names
This specification establishes the Methods sub-registry under Control This specification establishes the Method Names sub-registry under
Framework Parameters and initiates its population as follows. New Media Control Channel Framework Parameters and initiates its
parameters in this sub-registry must be published in an RFC (either population as follows. New parameters in this sub-registry must be
as an IETF submission or RFC Editor submission). published in an RFC (either in the IETF stream or Independent
Submission stream).
CONTROL - [RFCXXXX] CONTROL - [RFC6230]
REPORT - [RFCXXXX] REPORT - [RFC6230]
SYNC - [RFCXXXX] SYNC - [RFC6230]
K-ALIVE - [RFCXXXX] K-ALIVE - [RFC6230]
The following information MUST be provided in an RFC in order to
register a new Control Framework method:
The following information MUST be provided in an RFC publication in
order to register a new Control Framework method:
o The method name. o The method name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
13.3. Control Framework Status Codes 13.3. Control Framework Status Codes
This specification establishes the Status-Code sub-registry under This specification establishes the Status Code sub-registry under
Channel Framework Parameters. New parameters in this sub-registry Media Control Channel Framework Parameters. New parameters in this
must be published in an RFC (either as an IETF submission or RFC sub-registry must be published in an RFC (either in the IETF stream
Editor submission). Its initial population is defined in Section 9. or Independent Submission stream). Its initial population is defined
It takes the following format: in Section 9. It takes the following format:
Code [RFC Number] Description Code Description Reference
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC in order to
order to register a new Control Framework status code: register a new Control Framework status code:
o The status code number. o The status code number.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
o A brief desciption of the status code.
o A brief description of the status code.
13.4. Control Framework Header Fields 13.4. Control Framework Header Fields
This specification establishes the header field-Field sub-registry This specification establishes the Header Field sub-registry under
under Channel Framework Parameters. New parameters in this sub- Media Control Channel Framework Parameters. New parameters in this
registry must be published in an RFC (either as an IETF submission or sub-registry must be published in an RFC (either in the IETF stream
RFC Editor Independent submission). Its initial population is or Independent Submission stream). Its initial population is defined
defined as follows: as follows:
Control-Package - [RFCXXXX] Control-Package - [RFC6230]
Status - [RFCXXXX] Status - [RFC6230]
Seq - [RFCXXXX] Seq - [RFC6230]
Timeout - [RFCXXXX] Timeout - [RFC6230]
Dialog-ID - [RFCXXXX] Dialog-ID - [RFC6230]
Packages - [RFCXXXX] Packages - [RFC6230]
Supported - [RFCXXXX] Supported - [RFC6230]
Keep-Alive - [RFCXXXX] Keep-Alive - [RFC6230]
Content-Type - [RFCXXXX] Content-Type - [RFC6230]
Content-Length - [RFCXXXX] Content-Length - [RFC6230]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC in order to
order to register a new Channel Framework header field: register a new Channel Framework header field:
o The header field name. o The header field name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
13.5. Control Framework Port 13.5. Control Framework Port
The Control Framework uses TCP port XXXX, from the "registered" port The Control Framework uses TCP port 7563, from the "registered" port
range. Usage of this value is described in Section 4.1. range. Usage of this value is described in Section 4.1.
13.6. Media Type Registration 13.6. Media Type Registrations
This section describes the media types and names associated with this This section describes the media types and names associated with
payload format. The registration uses the templates defined in payload formats used by the Control Framework. The registration uses
[RFC4288]. It follows [RFC4855]. the templates defined in [RFC4288]. It follows [RFC4855].
13.6.1. Registration of MIME Media Type application/cfw 13.6.1. Registration of MIME Media Type application/cfw
MIME media type name: application Type name: application
MIME subtype name: cfw
Required parameters: None
Optional parameters: None
Encoding considerations: Binary and see section 4 of RFC XXXX
Security considerations: See Section 12 of RFC XXXX.
Interoperability considerations:
Endpoint compliant to this specification must
use this MIME type. Receivers who cannot support
this specification will reject using appropriate
protocol mechanism.
Published specification: RFC XXXX
Applications that use this media type:
Media Control Channel compliant applications.
Additional Information: Magic Number(s): (none)
File extension(s): (none)
Macintosh File Type Code(s): (none)
Person and email address to contact for further information:
Chris Boulton: chris@ns-technologies.com
Intended usage: COMMON
Restrictions on usage:
Should be used only in conjunction with this specification,
RFC XXXX.
Author: Chris Boulton
Change controller:
IETF MediaCtrl working group, delegated from the IESG.
13.7. 'cfw-id' SDP Attribute Subtype name: cfw
Contact name: Chris Boulton chris@ns-technologies.com. Required parameters: None
Attribute name: "cfw-id". Optional parameters: None
Type of attribute Media level. Encoding considerations: Binary and see Section 4 of RFC 6230
Subject to charset: Not. Security considerations: See Section 12 of RFC 6230
Purpose of attribute: The 'cfw-id' attribute indicates Interoperability considerations:
an identifier that can be used to correlate the control Endpoints compliant to this specification must
channel with the SIP INVITE dialog used to negotiate it, use this MIME type. Receivers who cannot support
when the attribute value is used within the control this specification will reject using appropriate
channel. protocol mechanism.
Allowed attribute values: A token. Published specification: RFC 6230
13.8. URN Sub-Namespace for Applications that use this media type:
urn:ietf:params:xml:ns:control:framework-attributes Applications compliant with Media Control Channels.
This section registers a new XML namespace, Additional Information:
"urn:ietf:params:xml:ns:control:framework-attributes", per the Magic number(s): (none)
guidelines in RFC 3688 [RFC3688]. File extension(s): (none)
Macintosh file type code(s): (none)
URI: urn:ietf:params:xml:ns:control:framework-attributes Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Registrant Contact: IETF, MEDIACTRL working group, Intended usage: COMMON
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
XML:
BEGIN Restrictions on usage:
<?xml version="1.0"?> Should be used only in conjunction with this specification,
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" RFC 6230.
"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
13.9. XML Schema Registration Author: Chris Boulton
This section registers an XML schema as per the guidelines in RFC Change controller:
3688 [RFC3688]. IETF MEDIACTRL working group, delegated from the IESG.
URI: urn:ietf:params:xml:ns:control:framework-attributes 13.6.2. Registration of MIME Media Type application/
Registrant Contact: IETF, MEDIACTRL working group, framework-attributes+xml
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
Schema: The XML for this schema can be found as the entirety of
Section 16 of this document.
13.10. MIME Media Type Registration for 'application/ Type name: application
framework-attributes+xml'
This section registers the "application/framework-attributes+xml" Subtype name: framework-attributes+xml
MIME type.
To: ietf-types@iana.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) Required parameters: (none)
Optional parameters: Same as charset parameter of application/xml as Optional parameters: Same as charset parameter of application/xml as
specified in RFC 3023. specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023. application/xml as specified in RFC 3023 [RFC3023].
Security considerations: No known security considerations outside Security considerations: No known security considerations outside
of those provided by core Media Control Channel Framework. of those provided by core Media Control Channel Framework.
Interoperability considerations: This content type provides common Interoperability considerations: This content type provides common
constructs for related Media Control Channel packages. 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): (none)
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Chris
Boulton <chris@ns-technologies.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: None.
14. Changes
Note to RFC Editor: Please remove this whole section.
14.1. Changes from 11 Version
o Addresses 'nits', 'comments' and 'DISCUSS' from IESG review.
14.2. Changes from 10 Version Published specification: RFC 6230
o Remove To: and Subject from IANA reg section. Applications that use this media type: Implementations of
o Added K-ALIVE message to section 12.2. appropriate Media Control Channel packages.
o Correct K-Alive header to Keep-Alive in examples.
o Fixed multiple SIP call flow nits.
o Reworded sentence relating to 'cfw-id'.
o Clarify text about issuing 202 response.
o Removed .xml from MIME template.
o Added extensibility section. Additional information:
o Changed ~ to a : for connectionid. Magic number(s): (none)
o Add text to formal syntax specifying case in-sensitive unless File extension(s): (none)
otherwise defined. Macintosh file type code(s): (none)
o Added upper bound for value of Keep-Alive header of 600 seconds.
o SDP Review: Alligned terminology with RFC 5057.
o SDP Review: cfw-id is now unique per endpoint in offer/answer and
the local value is inderted in the CFW Dialog-Id header - for SIP
forking pusposes.
o As per issue:1 from the mailing list, alterted SDP format and
included new MIME type for application/cfw - as per SDP review.
14.3. Changes from 09 Version Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
o Editorial fixes for strict idnits checking: RFC status, syntax, Intended usage: LIMITED USE
references, line length.
14.4. Changes from 08 Version Author/Change controller: The IETF
o Altered definition of 'Transaction-Timeout'. Other information: None.
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
14.5. Changes from 07 Version 13.7. 'cfw-id' SDP Attribute
o Added '*' to SDP 'm=' line in examples. Contact name: Chris Boulton <chris@ns-technologies.com>
14.6. Changes from 06 Version Attribute name: "cfw-id".
o Added 202 Timeout entry to table. Type of attribute Media level.
o Fixed some general nits and language.
o Fixed ABNF to be 'control-content = *OCTET'.
o Added general qualifier to sections 6.3.3.1 and 6.3.3.2 so that
rules for either tearing down or reconnecting are applied.
14.7. Changes from 05 Version Subject to charset: Not.
o Reworded 'must' used in Introduction. Purpose of attribute: The 'cfw-id' attribute indicates an
o Added urn namespace definition in IANA section. identifier that can be used to correlate the Control Channel with
o Added XML schema registration in IANA section. the SIP INVITE dialog used to negotiate it, when the attribute
o Added MIME registration in IANA section. value is used within the Control Channel.
14.8. Changes from 04 Version Allowed attribute values: A token.
o Fixed nits as reported by Brian Weis. 13.8. URN Sub-Namespace for
o Amended Security text as per secdir review. urn:ietf:params:xml:ns:control:framework-attributes
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.
14.9. Changes from 03 Version IANA has registered a new XML namespace,
"urn:ietf:params:xml:ns:control:framework-attributes", per the
guidelines in RFC 3688 [RFC3688].
o Removed comment from XML schema in appendix. URI: urn:ietf:params:xml:ns:control:framework-attributes
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.
14.10. Changes from 02 Version Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>,
Chris Boulton <chris@ns-technologies.com>.
o RAI review version. See comments. XML:
o Fixed broken IANA subsections ordering + naming.
14.11. Changes from 01 Version BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt">
RFC 6230</a>.</p>
</body>
</html>
END
o Restructured text for readability. 13.9. XML Schema Registration
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. This section registers an XML schema as per the guidelines in RFC
o Added Default port text - as per meeting. 3688 [RFC3688].
o Added Audit text.
14.12. Changes from 00 Version URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>,
Chris Boulton <chris@ns-technologies.com>.
o Aligned tokens to be 'CFW' (removed ESCS). Schema: The XML for this schema can be found in Appendix A.1 of this
o Content-Length not mandatory for messages with no payload. document.
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.
15. Contributors 14. Contributors
Asher Shiratzky from Radvision provided valuable support and Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document. contributions to the early versions of this document.
16. Acknowledgments 15. Acknowledgments
The authors would like to thank Ian Evans of Avaya, Michael The authors would like to thank Ian Evans of Avaya, Michael
Bardzinski and John Dally of NS-Technologies, Adnan Saleem of Bardzinski and John Dally of NS-Technologies, Adnan Saleem of
Radisys, and Dave Morgan for useful review and input to this work. Radisys, and Dave Morgan for useful review and input to this work.
Eric Burger contributed to the early phases of this work. Eric Burger contributed to the early phases of this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work. has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and Ben Campbell carried out the RAI expert review on this document and
provided a great deal of invaluable input. Brian Weis carried out a provided a great deal of invaluable input. Brian Weis carried out a
thorough security review. Jonathan Lennox carried out a thorough SDP thorough security review. Jonathan Lennox carried out a thorough SDP
review which provided some excellent modifications. Text from Eric review that provided some excellent modifications. Text from Eric
Burger was used in the introduction in the explanation for using SIP. Burger was used in the introduction in the explanation for using SIP.
17. Appendix: Common Package Components 16. References
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.
17.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 'conferenceid' XML container. If used by a
Control Package, any control XML referenced by the attribute applies
to all related media dialogs. Unlike the dialog attribute, the
'conferenceid' attribute does not need to be constructed based on the
overlying SIP dialog. The 'conferenceid' attribute value is system
specific and should be selected with relevant context and uniqueness.
It should be noted that the values contained in both the
'connectionid' and 'conferenceid' identifiers MUST be compared case-
sensitive.
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>
18. References
18.1. Normative References 16.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 54, line 16 skipping to change at page 46, line 9
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010. RFC 5922, June 2010.
18.2. Informative References 16.2. Informative References
[I-D.burger-mscl-thoughts] [MSCL-THOUGHTS]
Burger, E., "Media Server Control Language and Protocol Burger, E., "Media Server Control Language and Protocol
Thoughts", draft-burger-mscl-thoughts-01 (work in Thoughts", Work in Progress, June 2006.
progress), June 2006.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
skipping to change at page 55, line 5 skipping to change at page 47, line 5
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
RFC 5125, February 2008. RFC 5125, February 2008.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
Appendix A. Common Package Components
During the creation of the Control Framework, it has become clear
that there are a number of components that are common across multiple
packages. It has become apparent that it would be useful to collect
such reusable components in a central location. In the short term,
this appendix provides the placeholder for the utilities, and it is
the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages.
A.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing
Control Packages to apply specific commands to a particular SIP media
dialog (also referred to as "Connection") or conference. If used
within a Control Package, the Connection and multiparty attributes
will be imported and used appropriately to specifically identify
either a SIP dialog or a conference instance. If used within a
package, the value contained in the 'connectionid' attribute MUST be
constructed by concatenating the 'Local' and 'Remote' SIP dialog
identifier tags as defined in [RFC3261]. They MUST then be separated
using the ':' character. So the format would be:
'Local Dialog tag' + ':' + 'Remote Dialog tag'
As an example, for an entity that has a SIP Local dialog identifier
of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the
'connectionid' attribute for a Control Framework command would be:
7HDY839:HJKSkyHS
It should be noted that Control Framework requests initiated in
conjunction with a SIP dialog will produce a different 'connectionid'
value depending on the directionality of the request; for example,
Local and Remote tags are locally identifiable.
As with the Connection attribute previously defined, it is useful to
have the ability to apply specific Control Framework commands to a
number of related dialogs, such as a multiparty call. This typically
consists of a number of media dialogs that are logically bound by a
single identifier. The following schema allows for Control Framework
commands to explicitly reference such a grouping through a
'conferenceid' XML container. If used by a Control Package, any
control XML referenced by the attribute applies to all related media
dialogs. Unlike the dialog attribute, the 'conferenceid' attribute
does not need to be constructed based on the overlying SIP dialog.
The 'conferenceid' attribute value is system specific and should be
selected with relevant context and uniqueness.
It should be noted that the values contained in both the
'connectionid' and 'conferenceid' identifiers MUST be compared in a
case-sensitive manner.
The full schema follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com EMail: chris@ns-technologies.com
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rainwillow
Email: tim.melanchuk@gmail.com EMail: timm@rainwillow.com
Scott McGlashan Scott McGlashan
Hewlett-Packard Hewlett-Packard
Gustav III:s boulevard 36 Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden SE-16985 Stockholm, Sweden
Email: smcg.stds01@mcglashan.org EMail: smcg.stds01@mcglashan.org
 End of changes. 313 change blocks. 
1079 lines changed or deleted 912 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/