draft-ietf-mediactrl-sip-control-framework-08.txt   draft-ietf-mediactrl-sip-control-framework-09.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft NS-Technologies
Expires: June 6, 2009 T. Melanchuk Expires: August 23, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
December 3, 2008 February 19, 2009
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-08 draft-ietf-mediactrl-sip-control-framework-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 6, 2009. This Internet-Draft will expire on August 23, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract 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 processing are deployment where the application programming logic and media
distributed. This implies that application programming logic can processing are distributed. This implies that application
seamlessly gain access to appropriate resources that are not co- programming logic can seamlessly gain access to appropriate resources
located on the same physical network entity. The framework uses the that are not co-located on the same physical network entity. The
Session Initiation Protocol (SIP) to establish an application-level framework uses the Session Initiation Protocol (SIP) to establish an
control mechanism between application servers and associated external application-level control mechanism between application servers and
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 distributed, interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the IETF. It is not, centralized conference system, as defined by the IETF. It is not,
however, limited to this scope and it is envisioned that this generic however, limited to this scope and it is envisioned that this generic
Framework will be used for a wide variety of de-coupled control Framework will be used for a wide variety of de-coupled control
architectures between network entities. architectures between network entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 11
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 11
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15 6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 17 6.1. General Behaviour for Constructing Requests . . . . . . . 17
6.2. General Behaviour for Constructing Responses . . . . . . 17 6.2. General Behaviour for Constructing Responses . . . . . . 18
6.3. Transaction Processing . . . . . . . . . . . . . . . . . 18 6.3. Transaction Processing . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 25 skipping to change at page 4, line 17
12.4. Control Framework Header Fields . . . . . . . . . . . . . 40 12.4. Control Framework Header Fields . . . . . . . . . . . . . 40
12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41 12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41
12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41 12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41
12.8. URN Sub-Namespace for 12.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 42 urn:ietf:params:xml:ns:control:framework-attributes . . . 42
12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42 12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42
12.10. MIME Media Type Registration for 12.10. MIME Media Type Registration for
'application/framework-attributes+xml' . . . . . . . . . 43 'application/framework-attributes+xml' . . . . . . . . . 43
13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Changes from 07 Version . . . . . . . . . . . . . . . . . 43 13.1. Changes from 08 Version . . . . . . . . . . . . . . . . . 43
13.2. Changes from 06 Version . . . . . . . . . . . . . . . . . 44 13.2. Changes from 07 Version . . . . . . . . . . . . . . . . . 44
13.3. Changes from 05 Version . . . . . . . . . . . . . . . . . 44 13.3. Changes from 06 Version . . . . . . . . . . . . . . . . . 44
13.4. Changes from 04 Version . . . . . . . . . . . . . . . . . 44 13.4. Changes from 05 Version . . . . . . . . . . . . . . . . . 44
13.5. Changes from 03 Version . . . . . . . . . . . . . . . . . 44 13.5. Changes from 04 Version . . . . . . . . . . . . . . . . . 44
13.6. Changes from 02 Version . . . . . . . . . . . . . . . . . 44 13.6. Changes from 03 Version . . . . . . . . . . . . . . . . . 44
13.7. Changes from 01 Version . . . . . . . . . . . . . . . . . 45 13.7. Changes from 02 Version . . . . . . . . . . . . . . . . . 45
13.8. Changes from 00 Version . . . . . . . . . . . . . . . . . 45 13.8. Changes from 01 Version . . . . . . . . . . . . . . . . . 45
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.9. Changes from 00 Version . . . . . . . . . . . . . . . . . 45
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 46 16. Appendix: Common Package Components . . . . . . . . . . . . . 46
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46 16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
17.1. Normative References . . . . . . . . . . . . . . . . . . 48 17.1. Normative References . . . . . . . . . . . . . . . . . . 48
17.2. Informative References . . . . . . . . . . . . . . . . . 49 17.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51
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 processing activities architecture where the application logic and media processing
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 the
'Media Server Control Protocol Requirements' document[RFC5167]. 'Media Server Control Protocol Requirements' document[RFC5167].
While the Framework is not media server control specific, it is the While the Framework is not media server control specific, it is the
primary driver and use case for this work. It is intended that the primary driver and use case for this work. It is intended that the
framework contained in this document can be used for a variety of framework contained in this document can be used for a variety of
device control scenarios (for example, conference control). device control scenarios (for example, conference control).
This document does not define a SIP protocol driven extension that This document does not define a particular SIP protocol extension for
can be used directly for the control of external components. The the direct control of external components. Rather, other documents,
framework mechanism is extended by other documents that are known as known as "Control Packages," extend the control framework described
"Control Packages". A comprehensive set of guidelines for creating by this document. Section 8 provides a comprehensive set of
"Control Packages" is described in Section 8. guidelines for creating such Control Packages.
Current IETF device control protocols, such as megaco [RFC3525], Current IETF device control protocols, such as megaco [RFC3525],
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, because they duplicate many of the functions inherent SIP networks. This is because megaco duplicates many of the
in SIP. Rather than relying on single protocol session functions inherent in SIP. Rather than using a single protocol for
establishment, application developers need to translate between two session establishment and application media processing, application
separate mechanisms. developers need to translate between two separate mechanisms.
Moreover, the model provided by the framework presented here, using
SIP, better matches the application programming model than does
megaco.
SIP [RFC3261] provides the ideal rendezvous mechanism for 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
In this document, BCP 14 [RFC2119] defines the key words "MUST", In this document, BCP 14 [RFC2119] defines the key words "MUST",
skipping to change at page 5, line 4 skipping to change at page 6, line 6
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST", In this document, BCP 14 [RFC2119] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant addition, BCP 15 indicates requirement levels for compliant
implementations. implementations.
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 in this case, has a direct RTP [RFC3550] Control Server has a direct RTP [RFC3550] relationship with the
relationship with the source or sink of the media flow. In this source or sink of the media flow. In this document, we often
document, we often refer to the Control Server simply as "the refer to the Control Server simply as "the Server".
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
may not have any processing capabilities whatsoever. For example, might not have any processing capabilities whatsoever. For
the Control Client may be an Application Server (B2BUA) or other example, the Control Client may be an Application Server (B2BUA)
endpoint requesting manipulation of a third-party's media stream, or other endpoint requesting manipulation of a third-party's media
that terminates on a media server acting in the role of a Control stream, that terminates on a media server acting in the role of a
Server. In this document, we often refer to the Control Client Control Server. In this document, we often refer to the Control
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 MUST complete within 5 seconds and is referenced transaction MUST complete within 5 seconds and is referenced
throughout the draft as 'Transaction-Timeout'. throughout the draft as 'Transaction-Timeout'.
extended transaction lifetime: An extended transaction lifetime is Transaction-Timeout: The maximum allowed time between a Control
used to extend the lifetime of a CONTROL method transaction when
the Control Command it carries cannot be completed within
'Transaction-Timeout'. A Server extends the lifetime of a CONTROL
method transaction by sending a 202 response code followed by one
or more REPORT transactions as specified in Section 6.3.2.
Extended transaction lifetimes allow command failures to be
discovered at the transaction layer.
Transaction-Timeout: the maximum allowed time between a control
Client or Server issuing a framework message and receiving a Client or Server issuing a framework message and receiving a
corresponding response. The value for the timeout should be based corresponding response. The value for 'Transaction-Timeout' is 5
on a multiple of the network RTT plus an appropriate number seconds.
milliseconds to allow for message parsing and processing. The
value for 'Transaction-Timeout' is 5 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.
skipping to change at page 6, line 33 skipping to change at page 7, line 22
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 [I-D.burger-mscl-thoughts], established the following. One might
ask, "If all we are doing is establishing a TCP connection to control ask, "If all we are doing is establishing a TCP connection to control
the media server, what do we need SIP for?" This is a reasonable the media server, what do we need SIP for?" This is a reasonable
question. The key is to be using SIP for media session question. The key is we use SIP for media session establishment. If
establishment. If we are using SIP for media session establishment, we are using SIP for media session establishment, then we need to
then we need to ensure the URI used for session establishment ensure the URI used for session establishment resolves to the same
resolves to the same node as the node for session control. Using the node as the node for session control. Using the SIP routing
SIP routing mechanism, and having the server initiate the TCP mechanism, and having the server initiate the TCP connection back,
connection back, ensures this works. For example, the URI sip: ensures this works. For example, the URI sip:myserver.example.com
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 for 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 or Back-to-Back User Agents for o Service location - Use SIP Proxies and Back-to-Back User Agents
discovering 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 at both 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
skipping to change at page 7, line 36 skipping to change at page 8, line 22
|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 multiple control channels using separate SIP dialogs to be for the client to request multiple control channels using separate
established between the Control Client and the Control Server SIP 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 agnostic to any media sessions. Specific media connections are orthogonal to any given media session. Specific
session information can be incorporated in control interaction media session information are 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 16. The ability to have multiple the XML schema defined in Section 16. 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 SDP payload defined in [RFC3261], to the external Server. The SDP payload
includes the required information for control channel negotiation and includes the required information for control channel negotiation and
is the primary mechanism for conveying support for this specification is the primary mechanism for conveying support for this specification
(through the media type). The COMEDIA [RFC4145] specification for (through the media type). The COMEDIA [RFC4145] specification for
setting up and maintaining reliable connections is used as part of setting up and maintaining reliable connections is used as part of
the negotiation mechanism (more detail available in later sections). the negotiation mechanism (more detail available in later sections).
The Client will also include the 'cfw-id' SDP attribute, as defined The Client also includes the 'cfw-id' SDP attribute, as defined in
in this specification which is used to correlate the underlying Media this specification, which is used to correlate the underlying Media
Control Channel with the offer/answer exchange. Control 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=z9hG4bK72dhjsU Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
CSeq: 1 INVITE CSeq: 1 INVITE
skipping to change at page 9, line 37 skipping to change at page 10, line 17
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 setup, media sessions
can be established using standard SIP third party call control. can be established using standard SIP third party call control.
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. (1) in brackets represents the control a User Agent's RTP session. The link (1) in brackets
SIP dialog and dedicated control channel previously described in this represents the SIP dialog and dedicated control channel previously
overview section. 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
(2) from Figure 2 represents the User Agent SIP dialog interactions The link (2) from Figure 2 represents the User Agent SIP dialog
and associated media flow. A User Agent would create a SIP dialog interactions and associated media flow. A User Agent creates a SIP
with the Control Client entity. The Control Client entity will also dialog with the Control Client entity. The Control Client entity
create a related dialog to the Control Server (B2BUA type then creates a related dialog to the Control Server, using B2BUA type
functionality). Using the interaction illustrated by (2), the functionality. Using the interaction illustrated by (2), the Control
Control Client negotiates media capabilities with the Control Server, Client negotiates media capabilities with the Control Server, on
on behalf of the User Agent, using SIP Third Party Call Control behalf of the User Agent, using SIP Third Party Call Control
[RFC3725]. [RFC3725].
4. Control Channel Setup 4. Control Channel Setup
This section describes the setup, using SIP, of the dedicated This section describes the setup, using SIP, of the dedicated control
control. 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, a and transmit a new SIP INVITE request for control channel setup. The
UAC MUST construct the protocol message 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 [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 dialog. the newly created dialog.
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] (*note - SIP also allows an Description Protocol defined in [RFC4566], unless the Control Client
'offer-less' INVITE which is also maintained by this specification). does not have the SDP of the far (non-Control Server) end of the
The following information defines the composition of some specific session yet. The following information defines the composition of
elements of the SDP payload that MUST be adhered to for compliancy to specific elements of the SDP payload the Client MUST adhere to when
this specification when used in an SIP SDP offer. used in an SIP SDP offer.
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 originators address, for example
dns/IP representation. The address will be the network address used dns/IP representation. The address is the address used for
for connections in this specification. connections.
Example: Example:
c=IN IP4 controller.example.com c=IN IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry for The SDP MUST contain a corresponding Media Description entry:
compliance to this specification:
m=<media> <port> <proto> m=<media> <port> <proto>
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 'Connection Data line defined previously to supply connection
details. If the constructing client can't receive incoming details. If the constructing client can't receive incoming
connections it MUST still enter a valid port range entry. The use of connections it MUST still enter a valid port entry. The use of the
the port value '0' has the same meaning as defined in the SDP port value '0' has the same meaning as defined in a SIP Offer/Answer
specification[RFC4566]. The Control Framework has an IANA-registered exchange[RFC3264]. The Control Framework has an IANA-registered
recommended port defined in Section 12.5. This value is not a recommended port defined in Section 12.5. This value is not a
default as a client is free to choose explicit port numbers. default as a client is free to choose explicit port numbers.
However, SDP SHOULD be configured so that the recommended port is However, SDP SHOULD use the registered port number, unless local
used whenever appropriate. This makes life easier for network policy prohibits its use. Using the registered port number allows
administrators who need to manage firewall policy for Control network administrators to manage firewall policy for Control
Framework interactions. The third sub-field, <proto>, MUST equal a Framework interactions. The third sub-field, <proto>, MUST equal a
transport value defined in Section 12.6. All implementations transport value defined in Section 12.6. All implementations
compliant to this specification MUST support the value "TCP/CFW", compliant to this specification MUST support the value "TCP/CFW",
"TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in "TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in
Section 12.6 of this document. Implementations MUST support TLS as a Section 12.6 of this document. 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. Control implementations MUST support TCP as a transport protocol. Control
Framework implementations MAY support SCTP as a transport protocol. Framework implementations MAY support SCTP as a transport protocol.
When an entity identifies one of the transport values defined in When an entity identifies one of the transport values defined in
Section 12.6 but is not willing to establish the session, it MUST Section 12.6 but is not willing to establish the session, it MUST
respond using the appropriate SIP mechanism. respond using the appropriate SIP mechanism.
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.
A client conforming to this specification SHOULD support all the A client conforming to this specification SHOULD support all the
possible values defined for media attributes from the COMEDIA possible values defined for media attributes from the COMEDIA
[RFC4145] specification but MAY choose not to support values if it [RFC4145] specification but MAY choose not to support values if it
can definitely determine they will never be used (for example will can definitely determine they will never be used. For example, the
only ever initiate outgoing connections). It is RECOMMENDED that a client may naver initiate incoming connections and thus does not need
Controlling UAC initiate a connection to an external Server but that to support the incoming connection parameters. It is RECOMMENDED
an external Server MAY negotiate and initiate a connection using that a Controlling UAC initiate a connection to an external Server
COMEDIA, if network topology prohibits initiating connections in a but that an external Server MAY negotiate and initiate a connection
certain direction. An example of the attributes is: using COMEDIA, if network topology prohibits initiating connections
in a certain direction. An example of the COMEDIA attributes is:
a=setup:active a=setup:active
a=connection:new a=connection:new
This example demonstrates a new connection that will be initiated This example demonstrates a new connection that will be initiated
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 dialog and appropriate be sent to the appropriate location. The SIP dialog and appropriate
control connection is then established. 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 dialog. This to correlate the control channel with this SIP dialog. This
attribute MUST contain an appropriately random value of at least 64 attribute MUST be globally unique over space and time (using an
bits of randomness that will not clash with other offer/answer appropriate algorithm) and will not clash with other offer/answer
exchanges that will take place and is globally unique over space and exchanges that will take place. The value chosen for the 'cfw-id'
time. The value chosen for the 'cfw-id' attribute MUST be used for attribute MUST be used for the entire duration of the associated SIP
the entire duration of the associated SIP dialog and not be changed dialog and not be changed during updates to the offer/answer
during updates to the offer/answer exchange. This applies to exchange. This applies specifically to the 'connection' attribute as
specifically to the 'connection' attribute as defined in [RFC4145]. defined in [RFC4145]. If a SIP UAC wants to change some other parts
If a SIP UAC wants to change some other parts of the SDP but reuse of the SDP but reuse the already established connection it MUST use
the already established connection it should use the value of the value of 'existing' in the 'connection' attribute (for example,
'existing' in the 'connection' attribute (for example, a=connection: a=connection:existing). If it has noted that a connection has failed
existing). If it has noted that a connection has failed and wants to and wants to re-establish the connection, it MUST use the value of
re-establish, it uses the value of 'new' in the 'connection' 'new' in the 'connection' attribute (for example, a=connection:new).
attribute (for example, a=connection:new). Throughout this the Throughout this the connection identifier specified in the 'cfw-id'
connection identifier specified in the 'cfw-id' SDP parameter does SDP parameter MUST NOT change. One is simply negotiating the
not change. You are simply negotiating the underlying TCP connection underlying TCP connection between endpoints but always using the same
between endpoints but always using the same Control Framework Control Framework session, which is 1:1 for the lifetime of the SIP
session, which is 1:1 for the lifetime of the SIP dialog. dialog.
A non-2xx class final response (4xx, 5xx and 6xx) SIP response A non-2xx class final SIP response (4xx, 5xx and 6xx) received for
received for the INVITE request indicates that no SIP dialog has been the INVITE request indicates that no SIP dialog has been created and
created and is treated as specified [RFC3261]. Specifically, support is treated as specified by SIP [RFC3261]. Specifically, support of
of this specification is negotiated through the presence of the media this specification is negotiated through the presence of the media
type defined in this specification. The receipt of a SIP error type defined in this specification. The receipt of a SIP error
response like "488" indicates that the offer contained in a request response such as "488" indicates that the offer contained in a
is not acceptable. The inclusion of the media line associated with request is not acceptable. The inclusion of the media line
this specification in such a rejected offer should indicate to the associated with this specification in such a rejected offer indicates
client generating the offer that this could be due to the receiving to the client generating the offer that this could be due to the
client not supporting this specification. The client generating the receiving client not supporting this specification. The client
offer MUST act as it would normally on receiving this response, as generating the offer MUST act as it would normally on receiving this
per [RFC3261]. Media streams can also be rejected by setting the response, as per [RFC3261]. Media streams can also be rejected by
port to "0" in the "m=" line of the session description. A client setting the port to "0" in the "m=" line of the session description.
using this specification MUST be prepared to receive an answer where A client using this specification MUST be prepared to receive an
the "m=" line it inserted for using the Control Framework has been answer where the "m=" line it inserted for using the Control
set to "0". In this situation the client will act as it would for Framework has been set to "0". In this situation the client will act
any other media type with a port set to "0". 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 Sessions Description of the offer message and identifying
support for the appropriate media type. If the SIP UAS wishes to support for the appropriate media type. If the SIP UAS wishes to
construct a reliable response that conveys support for the extension, construct a reliable response that conveys support for the extension,
it MUST follow the mechanisms defined in [RFC3261]. If support is it MUST follow the mechanisms defined in [RFC3261]. If support is
skipping to change at page 14, line 14 skipping to change at page 14, line 32
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 exactly attribute as defined in Section 9.2. This attribute MUST exactly
copy the value which appeared in the initial offer. copy the value which appeared in the initial offer.
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 Dialog and the associated Control channel are now implicitly the SIP Dialog and the associated Control channel are now implicitly
linked. If either party wishes to terminate a Control channel it linked. If either party wishes to terminate a Control channel it
simply issues a SIP termination request (for example a SIP BYE simply issues a SIP termination request (for example a SIP BYE
request, or appropriate response in an early dialog). The Control request, or appropriate response in an early dialog). The Control
Channel therefore lives for the duration of the SIP dialog. Channel therefore lives for the duration of the SIP dialog.
If the SIP UAS does not support the extension defined in this A UAS receiving a SIP OPTIONS request MUST respond appropriately as
document, as identified by the media contained in the Session defined in [RFC3261]. The UAS MUST include the media types supported
Description, it should respond as detailed in [RFC3261] with a "SIP in the SIP 200 OK response in a SIP "Accept" header to indicate the
488" response code. If multiple media descriptions exist it might valid media types.
choose to continue processing the request and mark the port field
equal to "0".
A SIP entity receiving a SIP OPTIONS request MUST respond
appropriately as defined in [RFC3261]. This involves providing
information relating to supported SIP extensions and media types in a
200 OK response. For this extension the media types supported MUST
be included in the SIP 200 OK response in a SIP "Accept" header to
indicate a valid media type.
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
specific Control package commands to media sessions established by multiple specific Control package commands to media sessions
SIP dialogs (media dialogs) with the same remote server. For established by SIP dialogs (media dialogs) with given a given remote
example, to apply a command to generate audio media (such as an server. For example, the Control Server might send a command to
announcement) on an RTP session between a User Agent and a Media generate audio media (such as an announcement) on an RTP stream
Server. between a User Agent and a Media Server.
SIP dialogs used to establish media sessions (see Figure 2) on behalf SIP dialogs used to establish media sessions (see Figure 2) on behalf
of User Agents may contain more than one Media Description (as of User Agents may contain more than one Media Description (as
defined by "m=" in the SDP). The Control Client SHOULD include a defined by "m=" in the SDP). The Control Client MUST include a media
media label attribute, as defined in [RFC4574], for each "m=" label attribute, as defined in [RFC4574], for each "m=" definition
definition received that is to be directed to an entity using the received that is to be directed to an entity using the control
control framework. This allows the Control Client to later framework. This allows the Control Client to later explicitly direct
explicitly direct commands on the control channel at a specific media commands on the control channel at a specific media line (m=).
line (m=). A Control Client constructing the SDP MAY choose not to
include the media label SDP attribute if it does not require direct
control on a per media stream basis.
This framework identifies the referencing of such associated media 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 repetitive specifying
of dialog reference language. The schema can be found in of dialog reference language. The schema can be found in
Section 16.1 in Appendix A. Section 16.1 in Appendix A.
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
skipping to change at page 15, line 40 skipping to change at page 15, line 47
The use of the COMEDIA specification in this document allows for a The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of a SIP 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 the control channel with the
SIP dialog used for its establishment. A Control Client receiving an SIP dialog used for its establishment. A Control Client receiving an
incoming connection (whether it be acting in the role of UAC or UAS) incoming connection (whether it be acting in the role of UAC or UAS)
has no way of identifying the associated SIP dialog as it could be has no way of identifying the associated SIP dialog as it could be
simply listening for all incoming connections on a specific port. simply listening for all incoming connections on a specific port.
The following steps, which implementations MUST support, allow a The following steps, which implementations MUST support, allow a
connecting UA (defined as 'active' role in COMEDIA) to identify the connecting UA that is, the UA with the 'active' role in COMEDIA, to
associated SIP dialog that triggered the connection. These steps identify the associated SIP dialog that triggered the connection.
SHOULD be carried out before any other signaling on the newly created Unless there is an alternative dialog association mechanism used, the
Control channel. An alternative dialog association mechanism MAY be UAs MUST carry out these steps before any other signaling on the
specified in extensions to this document. newly created 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 active role (active UA) to initiate the connection MUST
immediately send a Control Framework SYNC request. The SYNC immediately send a Control Framework SYNC request. The SYNC
request MUST be constructed as defined in Section 9.1 and MUST request MUST be constructed as defined in Section 9.1 and MUST
contain the message header, 'Dialog-ID', which contains the SIP contain the message header, 'Dialog-ID', which contains the SIP
dialog information. dialog information.
o The 'Dialog-ID' message header value is the value contained in the o The 'Dialog-ID' message header value is the value contained in the
'cfw-id' SDP media level attribute. This allows for a correlation 'cfw-id' SDP media level attribute. This allows for a correlation
between the control channel and its associated SIP dialog. between the control channel and its associated SIP dialog.
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
skipping to change at page 16, line 18 skipping to change at page 16, line 24
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 active UA MUST then send the SYNC request. It MUST then wait o The active UA MUST then send the SYNC request. It MUST then wait
for a period of at least 'Transaction-Timeout' to receive a for a period of at least 'Transaction-Timeout' to receive a
response. It MAY choose a longer time to wait but it MUST not be response. It MAY choose a longer time to wait but it MUST NOT be
shorter than 'Transaction-Timeout'. shorter than 'Transaction-Timeout'.
o If no response is received for the SYNC control message, a timeout o If no response is received for the SYNC control message, a timeout
occurs and the control channel is terminated along with the occurs and the control channel is terminated along with the
associated SIP dialog (issue a BYE request). associated SIP dialog. The active UA MUST issue a BYE request to
o If the active UA receives a 481 response, this implies that the terminate the SIP dialog.
SYNC request was received but no associated SIP dialog exists. o If the active UA receives a 481 response from the passive UA, this
This also results in the control channel being terminated along means the SYNC request was received but the associated SIP dialog
with the associated SIP dialog (issue a BYE request). specified in the SYNC message does not exists. The active client
MUST terminate the control channel. The active UA MUST issue a
SIPBYE request to terminate the SIP dialog.
o All other error responses received for the SYNC request are 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 dialog termination of the control channel and the associated SIP dialog.
(issue a BYE request). The active UA MUST issue a BYE request to terminate the SIP
dialog.
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 dialog and control connection have been successfully SIP dialog and control connection have been successfully
correlated. The control channel can now be used for further correlated. The control channel can now be used for further
interactions. 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 present, the contents of the Keep-Alive and Dialog-ID headers MUST
MUST not change. New values of the "Keep-Alive" and "Dialog-ID" NOT change. New values of the Keep-Alive and Dialog-ID headers have
headers have no relevance as they are negotiated for the lifetime of no relevance as they are negotiated for the lifetime of the Media
the Media Control Channel Framework session. 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, Section 4.1 and Section 4.2, and the connection has been correlated,
as described in previous paragraphs, the two entities are now in a as 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 behaviour 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 Behaviour 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: either entity can act as a control client depending Section 9. Note that either entity can act as a control client
on individual package requirements). Control Commands MUST also depending on individual package requirements. Control Commands MUST
adhere to the syntax defined by the Control Packages negotiated in also adhere to the syntax defined by the Control Packages negotiated
Section 4.1 and Section 4.2 of this document. A Control Client MUST in Section 4.1 and Section 4.2 of this document. A Control Client
create a unique control message transaction and associated identifier MUST create a unique control message transaction and associated
for insertion in the request. The transaction identifier is then identifier for insertion in the request. The transaction identifier
included in the first line of a control framework message along with is then included in the first line of a control framework message
the method type (as defined in the ABNF in Section 9). The first along with the method type, as defined in the ABNF in Section 9. The
line starts with the "CFW" token for the purpose of easily extracting first line starts with the "CFW" token for the purpose of easily
the transaction identifier. The transaction identifier MUST be extracting the transaction identifier. The transaction identifier
globally unique over space and time with at least 64 bits of MUST be globally unique over space and time (using an appropriate
randomness. This unique property helps in the avoidance of clashes algorithm). This unique property helps in the avoidance of clashes
when multiple client entities could be creating transactions to be when multiple client entities could be creating transactions to be
carried out on a single receiving server. All required mandatory and carried out on a single receiving server. All required mandatory and
optional control framework headers are then inserted into the control optional control framework headers are then inserted into the control
message with appropriate values (see relevant individual header message with appropriate values (see relevant individual header
information for explicit detail). A "Control-Package" header MUST information for explicit detail). A "Control-Package" header MUST
also be inserted with the value indicating the Control Package to also be inserted with the value indicating the Control Package to
which this specific request applies. Multiple packages can be which this specific request applies. Multiple packages can be
negotiated per control channel using the SYNC control message negotiated per control channel using the SYNC control message
discussed in Section 6.3.4.2. 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 include a 'Content-Type' and 'Content-Length' message header which is
represents the size of the message body in decimal number of octets. the size of the message body in decimal number of octets. The
The 'Content-Type' header represents the MIME payload to be used as 'Content-Type' header is the MIME type of the payload specified by
specified by the individual control framework packages. If no the individual control framework packages. If no associated payload
associated payload is to be added to the message, a 'Content-Length' is to be added to the message, the 'Content-Length' header MUST have
header with a value of '0' is considered the same as one not being a value of '0'.
present.
When all of the headers have been included in the framework message,
it is sent down the control channel.
A Server receiving such a request needs to respond quickly 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 'Transaction-Timeout' for a response MUST wait for a minimum of '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 Behaviour 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'. The response MUST generate a response within the 'Transaction-Time', as measured from
conform to the ABNF defined in Section 9. The first line of the the Control Client. The response MUST conform to the ABNF defined in
response MUST contain the transaction identifier used in first line Section 9. The first line of the response MUST contain the
of the request, as defined in Section 6.1. Responses MUST NOT transaction identifier used in first line of the request, as defined
include the 'Status' or 'Timeout' message headers, and these MUST be in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout'
ignored if received by a Client in a response. message headers, and these MUST be ignored if received by a Client in
a response.
A Control Server MUST then include a status code in the first line of A Control Server MUST include a status code in the first line of the
the constructed response. A Control Framework request (like CONTROL) response. If there is no error, the Server responds with a 200
that has been received, and either the actions specified by the Control Framework status code, as defined in Section 7.1. The 200
request have completed or a control command error is detected, uses response MAY include message bodies. If the response contains a
the 200 Control Framework status code as defined in Section 7.1 in payload, the message MUST include the Content-Length and Content-Type
the response. A 200 response MAY include message bodies. If a 200 headers. When the Control Client receives a 200-class response, the
response does contain a payload it MUST include Content-Length and control command transaction is complete.
Content-Type headers. A 200 is the only response defined in this
specification that allows a message body to be included. The If the Control Server receives a request, like CONTROL, that the
'Content-Type' header represents the MIME payload to be used as Server understands, but the Server knows processing the command will
specified by the individual control framework packages. A client exceed the Transaction-Timeout, then the Server MUST respond with a
receiving a 200 class response then considers the control command 202 status code in the first line of the response. Following the
transaction completed. A Control Framework request (like CONTROL) initial response, the server will send one or more REPORT messages as
that is received and understood but requires processing that extends described in Section 6.3.2. A Control Package MUST explicitly define
beyond 'Transaction-Timeout' will result in a 202 status code in the the circumstances under which the server sends 200 and 202 messages.
response. This will be followed by one or more REPORT messages as
defined in Section 6.3.2. A Control Package SHOULD explicitly define
the circumstances under which either 200 or 202 with subsequent
processing takes place.
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 should 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 state and resources should be terminated. The response associated state and resources MUST be terminated. The response code
code may provide an explicit indication of why the transaction may provide an explicit indication of why the transaction failed,
failed, which might result in a re-submission of the request which might result in a re-submission of the request depending on the
depending on the extension package being used. 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 all four methods. Future extensions to this sending and receiving these four methods.
document MAY define new methods and responses.
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 is simply another usage of the CONTROL message which is permitted to
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 previously in Section 6.1 and defined in
Section 9. A CONTROL message MAY contain a message body. The Section 9. A CONTROL message MAY contain a message body. The
explicit control command(s) of the message payload contained in a explicit control command(s) of the message payload contained in a
CONTROL message are specified in separate Control Package CONTROL message are specified in separate Control Package
specifications. These specifications MUST conform to the format specifications. Separate Control Package specifications MUST conform
defined in Section 8.4. A CONTROL message containing a payload MUST to the format defined in Section 8.4. A CONTROL message containing a
include a 'Content-Type' header indicating the payload type defined payload MUST include a Content-Type header. The payload MUST be one
by the control package. A CONTROL message that does not contain a of the payload types defined by the control package. Individual
payload should be dealt with in the individual package. This could packages MAY allow a CONTROL message that does not contain a payload.
in fact be a valid message exchange within a specific package and if This could in fact be a valid message exchange within a specific
not an appropriate package level error message should be generated. package and if not an appropriate package-level error message MUST be
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 a 'Transaction-Timeout'. In this case CONTROL Command extends beyond the Transaction-Timeout, as measured
a 202 response is returned. Status updates and the final results of from the Client. In this case the Server returns a 202 response.
the command are then returned in subsequent REPORT messages. The Server returns status updates and the final results of the
command in subsequent REPORT messages.
All REPORT messages MUST contain the same transaction ID in the 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 allows extended transactions to be correlated with transaction. This correlates extended transactions with the original
the original CONTROL transaction. A REPORT message containing a CONTROL transaction. A REPORT message containing a payload MUST
payload MUST include a 'Content-Length and 'Content-Type' header include the Content-Type and Content-Length headers indicating the
indicating the payload MIME[RFC2045] type defined by the control payload MIME type [RFC2045] defined by the control package and the
package and its length. 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 Transaction-Timeout with a status code for the request, as specified
specified in Section 6.2. If the command completed within that time, in Section 6.2. If the command completes within that time, a 200
a 200 response code would have been sent. If the command did not response code MUST be sent. If the command does not complete within
complete within that time, the response code 202 would have been sent that time, the response code 202 MUST be sent indicating that the
indicating that the requested command is still being processed and requested command is still being processed and the CONTROL
the CONTROL transaction is being extended. The REPORT method is then transaction is being extended. The REPORT method is then used to
used to update and terminate the status of the extended transaction. update and terminate the status of the extended transaction.
A Control Server issuing a 202 response MUST contain a 'Timeout' A Control Server issuing a 202 response MUST contain a Timeout
message header. This header will contain a value in seconds that message header. This header MUST have a value in seconds that is the
represents the amount of time the recipient of the 202 message must amount of time the recipient of the 202 message must wait before
wait before assuming that there has been a problem and terminating assuming that there has been a problem and terminating the extended
the extended transaction and associated state (no corresponding transaction and associated state.
REPORT message arrived).
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' (It should be noted that the 'Seq' header with a value equal to '1'. Note - the 'Seq' numbers at both
numbers at both Control Client and Control Server for framework Control Client and Control Server for framework messages are
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 represents the amount of time the recipient of the seconds that is the amount of time the recipient of the REPORT
REPORT message must wait before assuming that there has been a message must wait before assuming that there has been a problem and
problem and terminating the extended transaction and associated terminating the extended transaction and associated state. On
state. On receiving a REPORT message with a 'Status' header of receiving a REPORT message with a 'Status' header of 'update', the
'update', the Control Client MUST reset the timer for the associated Control Client MUST reset the timer for the associated extended
extended CONTROL transaction to the indicated timeout period. If the CONTROL transaction to the indicated timeout period. If the timeout
timeout period approaches with no intended REPORT messages being period approaches with no intended REPORT messages being generated,
generated, the entity acting as a Control Framework UAS for the the entity acting as a Control Framework UAS for the interaction MUST
interaction MUST generate a REPORT message containing, as defined in generate a REPORT message containing, as defined in this paragraph, a
this paragraph, a 'Status' header of 'update' with no associated 'Status' header of 'update' with no associated payload. Such a
payload. Such a message acts as a timeout refresh and in no way message acts as a timeout refresh and in no way impacts the extended
impacts the extended transaction, because no message body or transaction, because no message body or semantics are permitted. It
semantics are permitted. It is RECOMMENDED that a minimum value of is RECOMMENDED that a minimum value of 10 and a maximum value of 15
10 and a maximum value of 15 seconds be used for the value of the seconds be used for the value of the 'Timeout' message header. It is
'Timeout' message header. It is also RECOMMENDED that a Control also RECOMMENDED that a Control Server refresh the timeout period of
Server refresh the timeout period of the CONTROL transaction at an the CONTROL transaction at an interval that is not too close to the
interval that is not too close to the expiry time. A value of 80% of expiry time. A value of 80% of the timeout period could be used.
the timeout period could be used, for example a timeout period of 10 For example, if the timeout period is 10 seconds, the Server would
seconds would be refreshed after 8 seconds. 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. They MUST also include a increment by 1 the 'Seq' header value. They MUST also include a
'Status' header with a value of 'update'. These REPORT messages sent 'Status' header with a value of 'update'. These REPORT messages sent
to update the extended CONTROL transaction status MAY contain a to update the extended CONTROL transaction status MAY contain a
message body, as defined by individual Control Packages and specified message body, as defined by individual Control Packages and specified
in Section 9.5. A REPORT message sent updating the extended in Section 9.5. A REPORT message sent updating the extended
transaction also acts as a timeout refresh, as described earlier in transaction also acts as a timeout refresh, as described earlier in
this section. This will result in a transaction timeout period at this section. This will result in a transaction timeout period at
skipping to change at page 21, line 13 skipping to change at page 21, line 13
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. A Control a value of 'terminate' and MAY contain a message body. A Control
Framework UAC can then clean up any pending state associated with the Framework UAC can then clean up any pending state associated with the
original control transaction. 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 will include a wide range of deployments where architectures. This includes a wide range of deployments where the
the clients could be co-located in a secured, private domain, or clients could be co-located in a secured, private domain, or spread
spread across disparate domains that require traversal of devices across disparate domains that require traversal of devices such as
such as Network Address Translators (NAT) and Firewalls. A keep Network Address Translators (NAT) and Firewalls. A keep-alive
alive mechanism enables the control channel to be kept active during mechanism enables the control channel to be kept active during times
times of inactivity (for example, most Firewalls have a timeout of inactivity. This is because many Firewalls have a timeout period
period after which connections are closed). This mechanism also after which connections are closed. This mechanism also provides the
provides the ability for application level failure detection. It ability for application level failure detection. It should be noted
should be noted that the following procedures apply explicitly to the that the following procedures apply explicitly to the control channel
control channel being created. For details relating to a SIP keep being created. For details relating to the SIP keep alive mechanism,
alive mechanism, implementers should seek guidance from SIP Outbound implementers should seek guidance from SIP Outbound
[I-D.ietf-sip-outbound]. [I-D.ietf-sip-outbound].
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 in-activity. level errors - especially during long periods of inactivity.
Once the SIP dialog has been established and the underlying control Once the SIP dialog has been established and the underlying control
channel has been set-up (including the initial correlation handshake channel has been set-up, including the initial correlation handshake
using SYNC as discussed in Section 6), both entities acting in the using SYNC as discussed in Section 6, both entities acting in the
'active' and 'passive' roles (as defined in COMEDIA [RFC4145]) MUST 'active' and 'passive' roles, as defined in COMEDIA [RFC4145], MUST
start a keep alive timer equal to the value negotiated during the start a keep alive timer equal to the value negotiated during the
control channel SYNC request/response exchange (the value from the control channel SYNC request/response exchange. This is the value
'Keep-Alive' header in seconds). from the 'Keep-Alive' header in seconds.
6.3.3.1. Behaviour for an Entity in an Active Role 6.3.3.1. Behaviour for an Entity in an Active Role
When acting in an 'active' role, a 'K-ALIVE' Control Framework When acting in an active role, a K-ALIVE Control Framework message
message MUST be generated before the local keep alive timer fires. MUST be generated before the local keep alive timer fires. An active
An active entity is free to send the K-ALIVE Control Framework entity is free to send the K-ALIVE Control Framework message whenever
message whenever it chooses. A guideline of 80% of the local keep it chooses. It is recommended for the entity to issue a K-ALIVE
alive timer is suggested. On receiving a 200 OK Control Framework message after 80% of the local keep-alive timer. On receiving a 200
message for the K-ALIVE request, the 'active' entity MUST reset the OK Control Framework message for the K-ALIVE request, the 'active'
local keep alive timer. If no 200 OK response is received to the entity MUST reset the local keep alive timer. If no 200 OK response
K-ALIVE Control Framework message (or a transport level problem is is received to the K-ALIVE Control Framework message, or a transport
detected by some other means) before the local keep alive timer level problem is detected by some other means, before the local keep
fires, the 'active' entity SHOULD tear down the SIP dialog and alive timer fires, the 'active' entity MAY use COMEDIA renegotiation
recover the associated control channel resources. The 'active' procedures to recover the connection. Otherwise, the 'active' entity
entity MAY choose to try and recover the connection by renegotiation MUST tear down the SIP dialog and recover the associated control
using COMEDIA. channel resources.
6.3.3.2. Behaviour for an Entity in an Passive Role 6.3.3.2. Behaviour for an Entity in a Passive Role
When acting as a 'passive' entity, a 'K-ALIVE' Control Framework When acting as a passive entity, a K-ALIVE Control Framework message
message must be received before the local keep alive timer fires. must be received before the local keep alive timer fires. When a
When a K-ALIVE request is received, the 'passive' entity MUST K-ALIVE request is received, the 'passive' entity MUST generate a 200
generate a 200 OK control framework response and reset the local keep OK control framework response and reset the local keep alive-timer.
alive timer. No other Control Framework response is valid. If no No other Control Framework response is valid. If no K-ALIVE message
K-ALIVE message is received (or a transport level problem is detected is received (or a transport level problem is detected by some other
by some other means) before the local keep alive timer fires, the means) before the local keep alive timer fires, the 'passive' entity
'passive' entity SHOULD tear down the SIP dialog and recover the MUST tear down the SIP dialog and recover the associated control
associated control channel resources. The 'active' entity MAY try to channel resources.
and recover the connection by renegotiating using COMEDIA.
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
SHOULD 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' o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to 'active', the 'Keep-Alive' header MUST be attribute equal to active, the Keep-Alive header MUST be included
included in the SYNC message generated by the offerer. The value in the SYNC message generated by the offerer. The value of the
of the 'Keep-Alive' header SHOULD be in the range of 95 and 120 Keep-Alive header SHOULD be in the range of 95 to 120 seconds
seconds (this is consistent with SIP (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]).
Outbound[I-D.ietf-sip-outbound]). The client that generated the The client that generated the SDP "Answer" (the passive client)
SDP "Answer" ('passive' client) MUST copy the 'Keep-Alive' header MUST copy the Keep-Alive header into the 200 response to the SYNC
into the 200 response to the SYNC message with the same value. message with the same value.
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to 'passive', the 'Keep-Alive' header parameter attribute equal to passive, the Keep-Alive header parameter MUST
MUST be included in the SYNC message generated by the answerer. be included in the SYNC message generated by the answerer. The
The value of the 'Keep-Alive' header SHOULD be in the range of 95 value of the Keep-Alive header SHOULD be in the range of 95 to 120
and 120 seconds. The client that generated the SDP "Offer" seconds. The client that generated the SDP Offer (the passive
('passive' client) MUST copy the 'Keep-Alive' header into the 200 client) MUST copy the Keep-Alive header into the 200 response to
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
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' attribute equal to actpass, the Keep-Alive header parameter MUST
attribute equal to 'actpass', the 'Keep-Alive' header parameter be included in the SYNC message of the entity who is the active
MUST be included in the SYNC message of the entity who is the participant in the SDP session. If the client generating the
'Active' participant in the SDP session. If the client generating subsequent SDP answer places a value of active in the COMEDIA SDP
the subsequent SDP 'Answer' places a value of 'active' in the setup attribute, it will generate the SYNC request and include the
COMEDIA SDP 'setup' attribute, it will generate the SYNC request Keep-Alive header. The value SHOULD be in the range 95 to 120
and include the 'Keep-Alive' header. The value SHOULD be in the seconds. If the client generating the subsequent SDP answer
range 95 to 120 seconds. If the client generating the subsequent places a value of passive in the COMDEDIA setup attribute, the
SDP 'Answer' places a value of 'passive' in the COMDEDIA 'setup' original UA making the SDP will generate the SYNC request and
attribute, the original 'Offerer' will generate the SYNC request include the Keep-Alive header. The value SHOULD be in the range
and include the 'Keep-Alive' header. The value SHOULD be in the 95 to 120 seconds.
range 95 to 120 seconds. o If the initial negotiated offer/answer results in a COMEDIA setup
o If the initial negotiated offer/answer results in a COMEDIA attribute equal to holdconn, the initial SYNC mechanism will occur
'setup' attribute equal to 'holdconn', the initial SYNC mechanism when the offer/answer exchange is updated and active/passive roles
will occur when the offer/answer exchange is updated and active/ are resolved using COMEDIA.
passive roles are delegated using COMEDIA.
The previous steps ensures that the entity initiating the control The previous steps ensures that the entity initiating the control
channel connection is always the one specifying the keep alive 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 Control Framework level 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 be
ignored. 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 will contain a list of all Control Framework Packages header contains a list of all Control Framework packages
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 tokens perspective of the client creating the SYNC message. All Channel
MUST be Channel Framework packages that adhere to the rules set out Framework package names MUST be tokens that adhere to the rules set
in Section 8. The "Packages" header of the initial SYNC message MUST out in Section 8. The Packages header of the initial SYNC message
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 Supported header of the response. This provides a hint to the client
client that generated the SYNC request of the additional packages that generated the SYNC request of additional packages supported by
supported by the server. 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 response MUST contain a Supported header indicating the packages that
that are supported. The initiating client can then choose to either are supported. The initiating client can then choose to either re-
re-submit a new SYNC message based on the 422 response or consider submit a new SYNC message based on the 422 response or consider the
the interaction as a failure. This would lead to termination of the interaction as a failure. This would lead to termination of the
associated SIP dialog by sending a SIP BYE request, as per [RFC3261]. associated SIP dialog by sending a SIP BYE request, as per [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 Control Framework message to re-
negotiate the packages that are supported within the control channel. negotiate the packages that are supported within the control channel.
A new SYNC message whose Packages header has different values from A new SYNC message whose Packages header has different values from
the previous SYNC message can effectively add and delete the packages the 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.
Any Control Framework commands relating to a Control Package that is An entity MAY honor Control Framework commands relating to a Control
no longer supported by the session which are received after package Package it no longer supports after package re-negotiation. When the
re-negotiation SHOULD be responded to with a 420 response. An entity entity does not wish to honor such commands, it MUST respond to the
MAY choose to honor such commands for a limited period of time but request with a 420 response.
this is implementation specific.
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 code indicates the completion of a successful framework The 200 response code indicates the completion of a successful
protocol transaction. framework protocol transaction.
7.2. 202 Response Code 7.2. 202 Response Code
The 202 response code indicates the completion of a successful The 202 response code indicates the completion of a successful
framework protocol transaction with additional information to be framework protocol transaction with additional information to be
provided at a later time through the REPORT mechanism defined in provided at a later time through the 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 indicates that the request was syntactically The 400 response code indicates that 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 fulfill it. The server understood the request, but is refusing to fulfill it.
The request SHOULD NOT be repeated. 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. 420 Response Code 7.6. 420 Response Code
Intended target of the request is for a Control Package that is not Intended target of the request is for a Control Package that is not
valid for the current session. valid for the current session.
skipping to change at page 26, line 12 skipping to change at page 26, line 12
not exist. In response to a SYNC request, it indicates that the not exist. In response to a SYNC request, it indicates that the
corresponding SIP dialog does not exist. corresponding SIP dialog does not exist.
7.11. 500 Response Code 7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
request request
8. Control Packages 8. Control Packages
"Control Packages" are intended to specify behavior that extends the Control Packages specify behavior that extends the capability defined
the capability defined in this document. "Control Packages" are not in this document. Control Packages MUST NOT weaken MUST and SHOULD
allowed to weaken "MUST" and "SHOULD" strength statements that are strength statements in this document. A Control Package MAY
detailed in this document. A "Control Package" MAY strengthen strengthen "SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified
"SHOULD" to "MUST" if justified by the specific usage of the by the specific usage of the framework.
framework.
In addition to normal sections expected in a standards-track RFC and In addition to the usual sections expected in a standards-track RFC
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 subsections.
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. To reiterate, the following appropriately in all Control-Packages. To reiterate, the following
sections do not solely form the basis of all Control-Package sections do not solely form the basis of all Control-Package
structure but are included as a minimum to provide essential package structure but are included as a minimum to provide essential package
level information. A Control-Package can take any valid form it level information. A Control-Package can take any valid form it
wishes as long as the following sections are additionally included. wishes as long as it includes at least the following.
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 12. The package name MUST also register a contained in Section 12. The package name MUST also register a
version number for the package which is separated with a '/' symbol version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be e.g. package_name/1.0. This enables updates to the package to be
skipping to change at page 26, line 50 skipping to change at page 26, line 49
number if the same package name is to be used. The exact increment number if the same package name is to be used. The exact increment
is left to the discretion of the package author. It is RECOMMENDED is left to the discretion of the package author. It is RECOMMENDED
that package authors make a clear statement on backwards that package authors make a clear statement on backwards
compatibility with any new version. compatibility with any new version.
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 should 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 control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. 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 16.1 in Appendix A. The Control defined and discussed in Section 16.1 in Appendix A. The Control
Package will make strong statements (using language from RFC 2119 Package will make strong statements (using language from RFC 2119
[RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is [RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is
to be supported. If only part of the schema is required (for example to be supported. If only part of the schema is required (for example
just 'connectionid' or just conferenceid), the Control Package will just 'connectionid' or just conferenceid), the Control Package will
make equally strong (using language from RFC 2119 [RFC2119]) make equally strong (using language from RFC 2119 [RFC2119])
statements. 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 6, or that no control package body is required. This section
section should indicate the location of detailed syntax definitions MUST indicate the location of detailed syntax definitions and
and semantics for the appropriate MIME[RFC2045] body type that apply semantics for the appropriate MIME[RFC2045] body type that apply to a
to a CONTROL command request and optionally the associated 200 CONTROL command request and optionally the associated 200 response.
response. For Control Packages that do not have a control package body, stating
such satisfies the MUST strength of this section in the Control
Package document.
8.5. REPORT Message Bodies 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
should 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. in a 200 response to a CONTROL message. For Control Packages that do
not have a control package body, stating such satisfies the MUST
strength of this section in the Control Package document.
8.6. Audit 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 (meta package level 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.
skipping to change at page 28, line 25 skipping to change at page 28, line 27
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 [RFC2234]. Augmented Backus-Naur Form (ABNF) as defined in [RFC5234].
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 transact-id SP method CRLF control-req-start = pCFW SP transact-id SP method CRLF
control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pCFW = %x43.46.57; CFW in caps pCFW = %x43.46.57; CFW in caps
transact-id = alpha-num-token transact-id = alpha-num-token
skipping to change at page 29, line 10 skipping to change at page 29, line 13
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
/Supported /Supported
/Keep-alive /Keep-alive
/ext-header) CRLF /ext-header)
Content-Length = "Content-Length:" SP 1*DIGIT Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" ) Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-ID:" SP dialog-id-string Dialog-id = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name) Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supported-alphanum *(COMMA supported-alphanum) Supported = "Supported:" SP supported-alphanum *(COMMA supported-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token dialog-id-string = alpha-num-token
package-name = alpha-num-token package-name = alpha-num-token
supported-alphanum = alpha-num-token supported-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 *( ";" gen-param ) media-type = type "/" subtype *( ";" gen-param )
type = token type = token
subtype = token subtype = token
gen-param = pname [ "=" pval ] gen-param = pname [ "=" pval ]
pname = token pname = token
skipping to change at page 37, line 16 skipping to change at page 37, line 16
11.1. Session Establishment 11.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 dialog. In order to described by SDP within the context of a SIP dialog. In order to
ensure secure rendezvous between Control Framework clients and 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 the SIP protocol. The use of the 'cfw-id' SDP
attribute results in important session information being carried attribute results in important session information being carried
across the SIP network. For this reason SIP clients using this across the SIP network. For this reason SIP clients using this
specification MUST use appropriate security mechanisms, such as specification MUST use appropriate security mechanisms, such as
TLS[RFC4346] and SMIME[RFC3851], when deployed in open networks. TLS[RFC5246] and SMIME[RFC3851], when deployed in open networks.
11.2. Transport Level Protection 11.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 for the data. To
ensure control channel protection, Control Framework clients and ensure control channel protection, Control Framework clients and
servers MUST support TLS and SHOULD use it by default unless servers MUST support TLS and SHOULD use it by default unless
alternative control channel protection is used or a protected alternative control channel protection is used or a protected
environment is guaranteed by the deployer 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.IPSEC). (e.g.IPsec).
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
[RFC4366]. A TLS cipher-suite of [RFC5246]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other
cipher-suites MAY also be supported. cipher-suites MAY also be supported.
11.3. Control Channel Policy Management 11.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
skipping to change at page 43, line 43 skipping to change at page 43, line 43
Person & email address to contact for further information: Chris Person & email address to contact for further information: Chris
Boulton <cboulton@avaya.com> Boulton <cboulton@avaya.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: None. Other information: None.
13. Changes 13. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
13.1. Changes from 07 Version 13.1. Changes from 08 Version
o Altered definition of 'Transaction-Timeout'.
o Removed 'random' reference in preference for globally unique.
o Clarified passive entity behavior on Keep-Alive timeout.
o Input of Chair comments for final publication.
o Removed extra CRLF in ABNF after 'headers'.
o Clarified 481 behavior.
o Removed definition for extended transaction lifetime
13.2. Changes from 07 Version
o Added '*' to SDP 'm=' line in examples. o Added '*' to SDP 'm=' line in examples.
13.2. Changes from 06 Version 13.3. Changes from 06 Version
o Added 202 Timeout entry to table. o Added 202 Timeout entry to table.
o Fixed some general nits and language. o Fixed some general nits and language.
o Fixed ABNF to be 'control-content = *OCTET'. 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 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. rules for either tearing down or reconnecting are applied.
13.3. Changes from 05 Version 13.4. Changes from 05 Version
o Reworded 'must' used in Introduction. o Reworded 'must' used in Introduction.
o Added urn namespace definition in IANA section. o Added urn namespace definition in IANA section.
o Added XML schema registration in IANA section. o Added XML schema registration in IANA section.
o Added MIME registration in IANA section. o Added MIME registration in IANA section.
13.4. Changes from 04 Version 13.5. Changes from 04 Version
o Fixed nits as reported by Brian Weis. o Fixed nits as reported by Brian Weis.
o Amended Security text as per secdir review. o Amended Security text as per secdir review.
o Removed optional 'label' part of dialog identifier as per interim o Removed optional 'label' part of dialog identifier as per interim
call. call.
o Added clarifying text at the beginning of section 4 to help o Added clarifying text at the beginning of section 4 to help
describe what the section is about. describe what the section is about.
o Added text at the beginning of section 8 clarifying that the o Added text at the beginning of section 8 clarifying that the
template is not the basis for packages BUT only needs to be template is not the basis for packages BUT only needs to be
included as part of a Control Package. included as part of a Control Package.
13.5. Changes from 03 Version 13.6. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
13.6. Changes from 02 Version 13.7. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
o Fixed broken IANA subsections ordering + naming. o Fixed broken IANA subsections ordering + naming.
13.7. Changes from 01 Version 13.8. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
13.8. Changes from 00 Version 13.9. Changes from 00 Version
o Aligned tokens to be 'CFW' (removed ESCS). o Aligned tokens to be 'CFW' (removed ESCS).
o Content-Length not mandatory for messages with no payload. o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions. o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others. o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF. o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific. o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response. o Added '423' duplicate transaction ID response.
o Added '405' method not allowed. o Added '405' method not allowed.
o Added IANA section. o Added IANA section.
skipping to change at page 46, line 22 skipping to change at page 46, line 31
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 draft 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. Text from Eric Burger was used in the thorough security review. Text from Eric Burger was used in the
introduction in the explanation for using SIP. introduction in the explanation for using SIP.
16. Appendix A 16. Appendix: Common Package Components
During the creation of the Control Framework it has become clear that During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages. initial 'Utilities Document' that can be used by Control Packages.
16.1. Common Dialog/Multiparty Reference Schema 16.1. Common Dialog/Multiparty Reference Schema
skipping to change at page 48, line 14 skipping to change at page 48, line 35
17.1. Normative References 17.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.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [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.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
17.2. Informative References 17.2. Informative References
[I-D.burger-mscl-thoughts] [I-D.burger-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", draft-burger-mscl-thoughts-01 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
skipping to change at page 50, line 18 skipping to change at page 50, line 28
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Avaya NS-Technologies
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: chris@ns-technologies.com
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rain Willow Communications
Email: tim.melanchuk@gmail.com Email: tim.melanchuk@gmail.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: scott.mcglashan@hp.com Email: scott.mcglashan@hp.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 122 change blocks. 
477 lines changed or deleted 451 lines changed or added

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