Network Working Group C. Boulton
Internet-Draft Avaya
Expires: May 28, 2009 T. Melanchuk
Rain Willow Communications
S. McGlashan
Hewlett-Packard
November 24, 2008
Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 28, 2009.
Abstract
This document describes a Framework and protocol for application
deployment where the application programming logic and processing are
distributed. This implies that application programming logic can
seamlessly gain access to appropriate resources that are not co-
located on the same physical network entity. The framework uses the
Session Initiation Protocol (SIP) to establish an application-level
control mechanism between application servers and associated external
servers such as media servers.
Boulton, et al. Expires May 28, 2009 [Page 1]
Internet-Draft Media Control Channel Framework November 2008
The motivation for the creation of this Framework is to provide an
interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the IETF. It is not,
however, limited to this scope and it is envisioned that this generic
Framework will be used for a wide variety of de-coupled control
architectures between network entities.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 17
6.2. General Behaviour for Constructing Responses . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
Boulton, et al. Expires May 28, 2009 [Page 2]
Internet-Draft Media Control Channel Framework November 2008
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37
11.2. Transport Level Protection . . . . . . . . . . . . . . . 37
11.3. Control Channel Policy Management . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Control Packages Registration Information . . . . . . . . 38
12.1.1. Control Package Registration Template . . . . . . . . 39
12.2. Control Framework Method Names . . . . . . . . . . . . . 39
12.3. Control Framework Status Codes . . . . . . . . . . . . . 40
12.4. Control Framework Header Fields . . . . . . . . . . . . . 40
12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41
12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41
12.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 42
12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42
12.10. MIME Media Type Registration for
'application/framework-attributes+xml' . . . . . . . . . 43
13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Changes from 06 Version . . . . . . . . . . . . . . . . . 43
13.2. Changes from 05 Version . . . . . . . . . . . . . . . . . 44
13.3. Changes from 04 Version . . . . . . . . . . . . . . . . . 44
13.4. Changes from 03 Version . . . . . . . . . . . . . . . . . 44
13.5. Changes from 02 Version . . . . . . . . . . . . . . . . . 44
13.6. Changes from 01 Version . . . . . . . . . . . . . . . . . 44
13.7. Changes from 00 Version . . . . . . . . . . . . . . . . . 45
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.1. Normative References . . . . . . . . . . . . . . . . . . 47
17.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51
Boulton, et al. Expires May 28, 2009 [Page 3]
Internet-Draft Media Control Channel Framework November 2008
1. Introduction
Real-time media applications are often developed using an
architecture where the application logic and processing activities
are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers,
such as "media servers". This document focuses on the framework and
protocol between the application server and external processing
server. The motivation for this framework comes from a set of
requirements for Media Server Control, which can be found in the
'Media Server Control Protocol Requirements' document[RFC5167].
While the Framework is not media server control specific, it is the
primary driver and use case for this work. It is intended that the
framework contained in this document can be used for a variety of
device control scenarios (for example, conference control).
This document does not define a SIP protocol driven extension that
can be used directly for the control of external components. The
framework mechanism is extended by other documents that are known as
"Control Packages". A comprehensive set of guidelines for creating
"Control Packages" is described in Section 8.
Current IETF device control protocols, such as megaco [RFC3525],
while excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in
SIP networks, because they duplicate many of the functions inherent
in SIP. Rather than relying on single protocol session
establishment, application developers need to translate between two
separate mechanisms.
SIP [RFC3261] provides the ideal rendezvous mechanism for
establishing and maintaining control connections to external server
components. The control connections can then be used to exchange
explicit command/response interactions that allow for media control
and associated command response results.
2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant
implementations.
The following additional terms are defined for use in this document:
Boulton, et al. Expires May 28, 2009 [Page 4]
Internet-Draft Media Control Channel Framework November 2008
User Agent Client (UAC): As specified in [RFC3261].
User Agent Server (UAS): As specified in [RFC3261].
B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
Control Server: A Control Server is an entity that performs a
service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing, announcement, tone
detection and generation, and play and record services. The
Control Server in this case, has a direct RTP [RFC3550]
relationship with the source or sink of the media flow. In this
document, we often refer to the Control Server simply as "the
Server".
Control Client: A Control Client is an entity that requests
processing from a Control Server. Note that the Control Client
may not have any processing capabilities whatsoever. For example,
the Control Client may be an Application Server (B2BUA) or other
endpoint requesting manipulation of a third-party's media stream,
that terminates on a media server acting in the role of a Control
Server. In this document, we often refer to the Control Client
simply as "the Client".
Control Channel: A Control Channel is a reliable connection between
a Client and Server that is used to exchange Framework messages.
The term "Connection" is used synonymously within this document.
Framework Message: A Framework Message is a message on a Control
Channel that has a type corresponding to one of the Methods
defined in this document. A Framework message is often referred
to by its method, such as a "CONTROL message".
Method: A Method is the type of a framework message. Four Methods
are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
Control Command: A Control Command is an application level request
from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in
separate specifications known as "Control Packages".
framework transaction: A framework transaction is defined as a
sequence composed of a control framework message originated by
either a Control Client or Control Server and responded to with a
control Framework response code message. Note that the control
framework has no "provisional" responses. A control framework
transaction MUST complete within 5 seconds and is referenced
throughout the draft as 'Transaction-Timeout'.
extended transaction lifetime: An extended transaction lifetime is
used to extend the lifetime 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.
Boulton, et al. Expires May 28, 2009 [Page 5]
Internet-Draft Media Control Channel Framework November 2008
Transaction-Timeout: the maximum allowed time between a control
Client or Server issuing a framework message and receiving a
corresponding response. The value for the timeout should be based
on a multiple of the network RTT plus an appropriate number
milliseconds to allow for message parsing and processing. The
value for 'Transaction-Timeout' is 5 seconds.
3. Overview
This document details mechanisms for establishing, using, and
terminating a reliable transport connection channel using SIP and the
Session Description Protocol offer/answer [RFC3264] exchange. The
established connection is then used for controlling an external
server. The following text provides a non-normative overview of the
mechanisms used. Detailed, normative guidelines are provided later
in the document.
Control channels are negotiated using standard SIP mechanisms that
would be used in a similar manner to creating a SIP multimedia
session. Figure 1 illustrates a simplified view of the mechanism.
It highlights a separation of the SIP signaling traffic and the
associated control channel that is established as a result of the SIP
interactions.
Initial analysis into the control framework, as documented in
[I-D.burger-mscl-thoughts], established the following. One might
ask, "If all we are doing is establishing a TCP connection to control
the media server, what do we need SIP for?" This is a reasonable
question. The key is to be using SIP for media session
establishment. If we are using SIP for media session establishment,
then we need to ensure the URI used for session establishment
resolves to the same node as the node for session control. Using the
SIP routing mechanism, and having the server initiate the TCP
connection back, ensures this works. For example, the URI sip:
myserver.example.com may resolve to sip:
server21.farm12.northeast.example.net, whereas the URI
http://myserver.example.com may resolve to
http://server41.httpfarm.central.example.net. That is, the host part
is NOT NECESSARILY unambiguous.
The use of SIP for to negotiate the control-channel provides many
inherent capabilities which include:
o Service location - Use SIP Proxies or Back-to-Back User Agents for
discovering Control Servers.
o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication.
Boulton, et al. Expires May 28, 2009 [Page 6]
Internet-Draft Media Control Channel Framework November 2008
o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, and so forth.
o Application agnostic - Generic protocol allows for easy extension.
As mentioned in the previous list, one of the main benefits of using
SIP as the session control protocol is the "Service Location"
facilities provided. This applies at both a routing level, where
[RFC3263] provides the physical location of devices, and at the
Service level, using Caller Preferences [RFC3840] and Callee
Capabilities [RFC3841]. The ability to select a Control Server based
on Service level capabilities is extremely powerful when considering
a distributed, clustered architecture containing varying services
(for example Voice, Video, IM). More detail on locating Control
Server resources using these techniques is outlined in Section 4.1 of
this document.
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
The example from Figure 1 conveys a 1:1 connection between the
Control Client and the Control Server. It is possible, if required,
for multiple control channels using separate SIP dialogs to be
established between the Control Client and the Control Server
entities. Any of the connections created between the two entities
can then be used for Server control interactions. The control
connections are agnostic to any media sessions. Specific media
session information can be incorporated in control interaction
commands (which themselves are defined in external packages) using
the XML schema defined in Section 16. The ability to have multiple
control channels allows for stronger redundancy and the ability to
manage high volumes of traffic in busy systems.
Consider the following simple example for session establishment
between a Client and a Server (Note: Some lines in the examples are
removed for clarity and brevity). Note that the roles discussed are
Boulton, et al. Expires May 28, 2009 [Page 7]
Internet-Draft Media Control Channel Framework November 2008
logical and can change during a session, if the Control Package
allows.
The Client constructs and sends a standard SIP INVITE request, as
defined in [RFC3261], to the external Server. The SDP payload
includes the required information for control channel negotiation and
is the primary mechanism for conveying support for this specification
(through the media type). The COMEDIA [RFC4145] specification for
setting up and maintaining reliable connections is used as part of
the negotiation mechanism (more detail available in later sections).
The Client will also include the 'cfw-id' SDP attribute, as defined
in this specification which is used to correlate the underlying Media
Control Channel with the offer/answer exchange.
Client Sends to External Server:
INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:Client@clientmachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 controller.example.com
m=application 7575 TCP/CFW
a=setup:active
a=connection:new
a=cfw-id:H839quwhjdhegvdga
On receiving the INVITE request, an external Server supporting this
mechanism generates a 200 OK response containing appropriate SDP.
The 'cfw-id' SDP attribute is copied from the original offer.
External Server Sends to Client:
Boulton, et al. Expires May 28, 2009 [Page 8]
Internet-Draft Media Control Channel Framework November 2008
SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0
o=originator 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP/CFW
a=setup:passive
a=connection:new
a=cfw-id:H839quwhjdhegvdga
The Control Client receives the SIP 200 OK response and extracts the
relevant information (also sending a SIP ACK). It creates an
outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP
connection to the Control Server. The connection address (taken from
'c=') and port (taken from 'm=')are used to identify the remote port
in the new connection.
Once established, the newly created connection can be used to
exchange requests and responses as defined in this document. If
required, after the control channel has been setup, media sessions
can be established using standard SIP third party call control.
Figure 2 provides a simplified example where the framework is used to
control a User Agent's RTP session. (1) in brackets represents the
SIP dialog and dedicated control channel previously described in this
overview section.
Boulton, et al. Expires May 28, 2009 [Page 9]
Internet-Draft Media Control Channel Framework November 2008
+--------Control SIP Dialog(1)---------+
| |
v v
+-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack|
| +---+-----+---+ +---+-----+---+
| | | | |
| | Control |<--Control Channel(1)-->| |
| | Client | | Control |
| +-------------+ | Server |
+--+--+ | |
|User | | |
|Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+
Figure 2: Participant Architecture
(2) from Figure 2 represents the User Agent SIP dialog interactions
and associated media flow. A User Agent would create a SIP dialog
with the Control Client entity. The Control Client entity will also
create a related dialog to the Control Server (B2BUA type
functionality). Using the interaction illustrated by (2), the
Control Client negotiates media capabilities with the Control Server,
on behalf of the User Agent, using SIP Third Party Call Control
[RFC3725].
4. Control Channel Setup
This section describes the setup, using SIP, of the dedicated
control. Once the control channel has been established commands can
be exchanged (as discussed in Section 6).
4.1. Control Client SIP UAC Behavior
When a UAC wishes to establish a control channel, it MUST construct
and transmit a new SIP INVITE request for control channel setup, a
UAC MUST construct the protocol message as defined in [RFC3261].
If a reliable response is received (as defined [RFC3261] and
[RFC3262]), the mechanisms defined in this document are applicable to
the newly created dialog.
The UAC SHOULD include a valid session description (an 'offer' as
defined in [RFC3264]) in an INVITE request using the Session
Description Protocol defined in [RFC4566] (*note - SIP also allows an
Boulton, et al. Expires May 28, 2009 [Page 10]
Internet-Draft Media Control Channel Framework November 2008
'offer-less' INVITE which is also maintained by this specification).
The following information defines the composition of some specific
elements of the SDP payload that MUST be adhered to for compliancy to
this specification when used in an SIP SDP offer.
The Connection Data line in the SDP payload is constructed as
specified in [RFC4566]:
c=<nettype> <addrtype> <connection-address>
The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The
third sub-field for Connection Data is <connection-address>. This
supplies a representation of the SDP originators address, for example
dns/IP representation. The address will be the network address used
for connections in this specification.
Example:
c=IN IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry for
compliance to this specification:
m=<media> <port> <proto>
The first "sub-field" <media> MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the
constructing client can receive an incoming connection if required.
The port is used in combination with the address specified in the
'Connection Data line defined previously to supply connection
details. If the constructing client can't receive incoming
connections it MUST still enter a valid port range entry. The use of
the port value '0' has the same meaning as defined in the SDP
specification[RFC4566]. The Control Framework has an IANA-registered
recommended port defined in Section 12.5. This value is not a
default as a client is free to choose explicit port numbers.
However, SDP SHOULD be configured so that the recommended port is
used whenever appropriate. This makes life easier for network
administrators who need to manage firewall policy for Control
Framework interactions. The third sub-field, <proto>, MUST equal a
transport value defined in Section 12.6. All implementations
compliant to this specification MUST support the value "TCP/CFW",
"TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in
Section 12.6 of this document. Implementations MUST support TLS as a
transport-level security mechanism for the control channel, although
use of TLS in specific deployments is optional. Control Framework
implementations MUST support TCP as a transport protocol. Control
Boulton, et al. Expires May 28, 2009 [Page 11]
Internet-Draft Media Control Channel Framework November 2008
Framework implementations MAY support SCTP as a transport protocol.
When an entity identifies one of the transport values defined in
Section 12.6 but is not willing to establish the session, it MUST
respond using the appropriate SIP mechanism.
The SDP MUST also contain a number of SDP media attributes(a=) that
are specifically defined in the COMEDIA [RFC4145] specification. The
attributes provide connection negotiation and maintenance parameters.
A client conforming to this specification SHOULD support all the
possible values defined for media attributes from the COMEDIA
[RFC4145] specification but MAY choose not to support values if it
can definitely determine they will never be used (for example will
only ever initiate outgoing connections). It is RECOMMENDED that a
Controlling UAC initiate a connection to an external Server but that
an external Server MAY negotiate and initiate a connection using
COMEDIA, if network topology prohibits initiating connections in a
certain direction. An example of the attributes is:
a=setup:active
a=connection:new
This example demonstrates a new connection that will be initiated
from the owner of the SDP payload. The connection details are
contained in the SDP answer received from the UAS. A full example of
an SDP payload compliant to this specification can be viewed in
Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in [RFC3261]), it can
be sent to the appropriate location. The SIP dialog and appropriate
control connection is then established.
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. The 'cfw-id' attribute
indicates an identifier that can be used within the control channel
to correlate the control channel with this SIP dialog. This
attribute MUST contain an appropriately random value of at least 64
bits of randomness that will not clash with other offer/answer
exchanges that will take place and is globally unique over space and
time. The value chosen for the 'cfw-id' attribute MUST be used for
the entire duration of the associated SIP dialog and not be changed
during updates to the offer/answer exchange. This applies to
specifically to the 'connection' attribute as defined in [RFC4145].
If a SIP UAC wants to change some other parts of the SDP but reuse
the already established connection it should use the value of
'existing' in the 'connection' attribute (for example, a=connection:
existing). If it has noted that a connection has failed and wants to
re-establish, it uses the value of 'new' in the 'connection'
Boulton, et al. Expires May 28, 2009 [Page 12]
Internet-Draft Media Control Channel Framework November 2008
attribute (for example, a=connection:new). Throughout this the
connection identifier specified in the 'cfw-id' SDP parameter does
not change. You are simply negotiating the underlying TCP connection
between endpoints but always using the same Control Framework
session, which is 1:1 for the lifetime of the SIP dialog.
A non-2xx class final response (4xx, 5xx and 6xx) SIP response
received for the INVITE request indicates that no SIP dialog has been
created and is treated as specified [RFC3261]. Specifically, support
of this specification is negotiated through the presence of the media
type defined in this specification. The receipt of a SIP error
response like "488" indicates that the offer contained in a request
is not acceptable. The inclusion of the media line associated with
this specification in such a rejected offer should indicate to the
client generating the offer that this could be due to the receiving
client not supporting this specification. The client generating the
offer MUST act as it would normally on receiving this response, as
per [RFC3261]. Media streams can also be rejected by setting the
port to "0" in the "m=" line of the session description. A client
using this specification MUST be prepared to receive an answer where
the "m=" line it inserted for using the Control Framework has been
set to "0". In this situation the client will act as it would for
any other media type with a port set to "0".
4.2. Control Server SIP UAS Behavior
On receiving a SIP INVITE request, an external Server(SIP UAS)
inspects the message for indications of support for the mechanisms
defined in this specification. This is achieved through inspection
of the Sessions Description of the offer message and identifying
support for the appropriate media type. If the SIP UAS wishes to
construct a reliable response that conveys support for the extension,
it MUST follow the mechanisms defined in [RFC3261]. If support is
conveyed in a reliable SIP provisional response, the mechanisms in
[RFC3262] MUST also be used. It should be noted that the SDP offer
is not restricted to the initial INVITE request and may appear in any
series of messages that are compliant to [RFC3261], [RFC3262], and
[RFC3264].
When constructing an answer, the SDP payload MUST be constructed
using the semantic (Connection, Media and attribute) defined in
Section 4.1 using valid local settings and also with full compliance
to the COMEDIA[RFC4145] specification. For example, the SDP
attributes included in the answer constructed for the example offer
provided in Section 4.1 would look as illustrated below:
a=setup:passive
Boulton, et al. Expires May 28, 2009 [Page 13]
Internet-Draft Media Control Channel Framework November 2008
a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. This attribute MUST exactly
copy the value which appeared in the initial offer.
Once the SDP answer has been constructed, it is sent using standard
SIP mechanisms. Depending on the contents of the SDP payloads that
were negotiated using the Offer/Answer exchange, a reliable
connection will be established between the Controlling UAC and
external Server UAS entities. The newly established connection is
now available to exchange control command primitives. The state of
the SIP Dialog and the associated Control channel are now implicitly
linked. If either party wishes to terminate a Control channel it
simply issues a SIP termination request (for example a SIP BYE
request, or appropriate response in an early dialog). The Control
Channel therefore lives for the duration of the SIP dialog.
If the SIP UAS does not support the extension defined in this
document, as identified by the media contained in the Session
Description, it should respond as detailed in [RFC3261] with a "SIP
488" response code. If multiple media descriptions exist it might
choose to continue processing the request and mark the port field
equal to "0".
A SIP 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
It is intended that the Control framework will be used within a
variety of architectures for a wide range of functions. One of the
primary functions will be the use of the control channel to apply
specific Control package commands to media sessions established by
SIP dialogs (media dialogs) with the same remote server. For
example, to apply a command to generate audio media (such as an
announcement) on an RTP session between a User Agent and a Media
Server.
SIP dialogs used to establish media sessions (see Figure 2) on behalf
of User Agents may contain more than one Media Description (as
defined by "m=" in the SDP). The Control Client SHOULD include a
Boulton, et al. Expires May 28, 2009 [Page 14]
Internet-Draft Media Control Channel Framework November 2008
media label attribute, as defined in [RFC4574], for each "m="
definition received that is to be directed to an entity using the
control framework. This allows the Control Client to later
explicitly direct commands on the control channel at a specific media
line (m=). A Control Client constructing the SDP MAY choose not to
include the media label SDP attribute if it does not require direct
control on a per media stream basis.
This framework identifies the referencing of such associated media
dialogs as extremely important. A connection reference attribute has
been specified that can optionally be imported into any Control
Package. It is intended that this will reduce repetitive specifying
of dialog reference language. The schema can be found in
Section 16.1 in Appendix A.
Similarly, the ability to identify and apply commands to a group of
associated media dialogs (multiparty) is also identified as a common
structure that could be defined and re-used, for example playing a
prompt to all participants in a Conference. The schema for such
operations can also be found in Section 16.1 in Appendix A.
Support for both the common attributes described here is specified as
part of each Control Package definition, as detailed in Section 8.
6. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of a SIP
INVITE transaction. SIP provides a flexible negotiation mechanism to
establish the control channel, but there needs to be a mechanism
within the control channel to correlate the control channel with the
SIP dialog used for its establishment. A Control Client receiving an
incoming connection (whether it be acting in the role of UAC or UAS)
has no way of identifying the associated SIP dialog as it could be
simply listening for all incoming connections on a specific port.
The following steps, which implementations MUST support, allow a
connecting UA (defined as 'active' role in COMEDIA) to identify the
associated SIP dialog that triggered the connection. These steps
SHOULD be carried out before any other signaling on the newly created
Control channel. An alternative dialog association mechanism MAY be
specified in extensions to this document.
o Once the connection has been established, the UA acting in the
active role (active UA) to initiate the connection MUST
immediately send a Control Framework SYNC request. The SYNC
request MUST be constructed as defined in Section 9.1 and MUST
contain the message header, 'Dialog-ID', which contains the SIP
dialog information.
Boulton, et al. Expires May 28, 2009 [Page 15]
Internet-Draft Media Control Channel Framework November 2008
o The 'Dialog-ID' message header value is the value contained in the
'cfw-id' SDP media level attribute. This allows for a correlation
between the control channel and its associated SIP dialog.
o On creating the SYNC request the active UA MUST follow the
procedures outlined in Section 6.3.3. This provides details of
connection keep alive messages.
o On creating the SYNC request the active UA MUST also follow the
procedures outlined in Section 6.3.4.2. This provides details of
the negotiation mechanism used to determine the Protocol Data
Units (PDUs) that can be exchanged on the established control
channel connection.
o The active UA MUST then send the SYNC request. It MUST then wait
for a period of at least 'Transaction-Timeout' to receive a
response. It MAY choose a longer time to wait but it MUST not be
shorter than 'Transaction-Timeout'.
o If no response is received for the SYNC control message, a timeout
occurs and the control channel is terminated along with the
associated SIP dialog (issue a BYE request).
o If the active UA receives a 481 response, this implies that the
SYNC request was received but no associated SIP dialog exists.
This also results in the control channel being terminated along
with the associated SIP dialog (issue a BYE request).
o All other error responses received for the SYNC request are
treated as detailed in this specification and also result in the
termination of the control channel and the associated SIP dialog
(issue a BYE request).
o The receipt of a 200 response to a SYNC message implies that the
SIP dialog and control connection have been successfully
correlated. The control channel can now be used for further
interactions.
SYNC messages can be sent at any point while the Control Channel is
open from either side, once the initial exchange is complete. If
present, the contents of the "Keep-Alive" and "Dialog-ID" headers
MUST not change. New values of the "Keep-Alive" and "Dialog-ID"
headers have no relevance as they are negotiated for the lifetime of
the Media Control Channel Framework session.
Once a successful control channel has been established, as defined in
Section 4.1 and Section 4.2, and the connection has been correlated,
as described in previous paragraphs, the two entities are now in a
position to exchange control framework messages. The following sub-
sections specify the general behaviour for constructing control
framework requests and responses. Section 6.3 specifies the core
Control Framework methods and their transaction processing.
Boulton, et al. Expires May 28, 2009 [Page 16]
Internet-Draft Media Control Channel Framework November 2008
6.1. General Behaviour for Constructing Requests
An entity acting as a Control Client that constructs and sends
requests on a control channel MUST adhere to the syntax defined in
Section 9 (Note: either entity can act as a control client depending
on individual package requirements). Control Commands MUST also
adhere to the syntax defined by the Control Packages negotiated in
Section 4.1 and Section 4.2 of this document. A Control Client MUST
create a unique control message transaction and associated identifier
for insertion in the request. The transaction identifier is then
included in the first line of a control framework message along with
the method type (as defined in the ABNF in Section 9). The first
line starts with the "CFW" token for the purpose of easily extracting
the transaction identifier. The transaction identifier MUST be
globally unique over space and time with at least 64 bits of
randomness. This unique property helps in the avoidance of clashes
when multiple client entities could be creating transactions to be
carried out on a single receiving server. All required mandatory and
optional control framework headers are then inserted into the control
message with appropriate values (see relevant individual header
information for explicit detail). A "Control-Package" header MUST
also be inserted with the value indicating the Control Package to
which this specific request applies. Multiple packages can be
negotiated per control channel using the SYNC control message
discussed in Section 6.3.4.2.
Any framework message that contains an associated payload MUST also
include a 'Content-Type' and 'Content-Length' message header which
represents the size of the message body in decimal number of octets.
The 'Content-Type' header represents the MIME payload to be used as
specified by the individual control framework packages. If no
associated payload is to be added to the message, a 'Content-Length'
header with a value of '0' is considered the same as one not being
present.
When all of the headers have been included in the framework message,
it is sent down the control channel.
A Server receiving such a request needs to respond quickly with an
appropriate response (as defined in Section 6.2). Control Clients
MUST wait for a minimum of 'Transaction-Timeout' for a response
before considering the transaction a failure and tidying state
appropriately depending on the extension package being used.
6.2. General Behaviour for Constructing Responses
An entity acting as a Control Server, on receiving a request, MUST
generate a response within the 'Transaction-Time'. The response MUST
Boulton, et al. Expires May 28, 2009 [Page 17]
Internet-Draft Media Control Channel Framework November 2008
conform to the ABNF defined in Section 9. The first line of the
response MUST contain the transaction identifier used in first line
of the request, as defined in Section 6.1. Responses MUST NOT
include the 'Status' or 'Timeout' message headers, and these MUST be
ignored if received by a Client in a response.
A Control Server MUST then include a status code in the first line of
the constructed response. A Control Framework request (like CONTROL)
that has been received, and either the actions specified by the
request have completed or a control command error is detected, uses
the 200 Control Framework status code as defined in Section 7.1 in
the response. A 200 response MAY include message bodies. If a 200
response does contain a payload it MUST include Content-Length and
Content-Type headers. A 200 is the only response defined in this
specification that allows a message body to be included. The
'Content-Type' header represents the MIME payload to be used as
specified by the individual control framework packages. A client
receiving a 200 class response then considers the control command
transaction completed. A Control Framework request (like CONTROL)
that is received and understood but requires processing that extends
beyond 'Transaction-Timeout' will result in a 202 status code in the
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
request (like REPORT or CONTROL), an appropriate error code should be
used in the response, as listed in Section 7. The generation of a
non 2xx class response code to a Control Framework request (like
CONTROL or REPORT) will indicate failure of the transaction, and all
associated state and resources should be terminated. The response
code may provide an explicit indication of why the transaction
failed, which might result in a re-submission of the request
depending on the extension package being used.
6.3. Transaction Processing
The Control Framework defines four types of requests (methods):
CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support
sending and receiving all four methods. Future extensions to this
document MAY define new methods and responses.
The following sub-sections specify each Control Framework method and
its associated transaction processing.
Boulton, et al. Expires May 28, 2009 [Page 18]
Internet-Draft Media Control Channel Framework November 2008
6.3.1. CONTROL Transactions
A 'CONTROL' message is used by the Control Client to pass control
related information to a Control Server. It is also used as the
event reporting mechanism in the control framework. Reporting events
is simply another usage of the 'CONTROL' message which is permitted
to be sent in either direction between two participants in a session,
carrying the appropriate payload for an event. The message is
constructed in the same way as any standard Control Framework
message, as discussed previously in Section 6.1 and defined in
Section 9. A CONTROL message MAY contain a message body. The
explicit control command(s) of the message payload contained in a
CONTROL message are specified in separate Control Package
specifications. These specifications MUST conform to the format
defined in Section 8.4. A CONTROL message containing a payload MUST
include a 'Content-Type' header indicating the payload type defined
by the control package. A CONTROL message that does not contain a
payload should be dealt with in the individual package. This could
in fact be a valid message exchange within a specific package and if
not an appropriate package level error message should be generated.
6.3.2. REPORT Transactions
A 'REPORT' message is used by a Control Server when processing of a
CONTROL Command extends beyond a 'Transaction-Timeout'. In this case
a 202 response is returned. Status updates and the final results of
the command are then returned in subsequent REPORT messages.
All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL
transaction. This allows extended transactions to be correlated with
the original CONTROL transaction. A REPORT message containing a
payload MUST include a 'Content-Length and 'Content-Type' header
indicating the payload MIME[RFC2045] type defined by the control
package and its length.
6.3.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within
'Transaction-Timeout' with a status code for the request, as
specified in Section 6.2. If the command completed within that time,
a 200 response code would have been sent. If the command did not
complete within that time, the response code 202 would have been sent
indicating that the requested command is still being processed and
the CONTROL transaction is being extended. The REPORT method is then
used to update and terminate the status of the extended transaction.
A Control Server issuing a 202 response MUST contain a 'Timeout'
Boulton, et al. Expires May 28, 2009 [Page 19]
Internet-Draft Media Control Channel Framework November 2008
message header. This header will contain a value in seconds that
represents the amount of time the recipient of the 202 message must
wait before assuming that there has been a problem and terminating
the extended transaction and associated state (no corresponding
REPORT message arrived).
The initial REPORT message MUST contain a 'Seq' (Sequence) message
header with a value equal to '1' (It should be noted that the 'Seq'
numbers at both Control Client and Control Server for framework
messages are independent).
All REPORT messages for an extended CONTROL transaction MUST contain
a 'Timeout' message header. This header will contain a value in
seconds that represents the amount of time the recipient of the
REPORT message must wait before assuming that there has been a
problem and terminating the extended transaction and associated
state. On receiving a REPORT message with a 'Status' header of
'update', the Control Client MUST reset the timer for the associated
extended CONTROL transaction to the indicated timeout period. If the
timeout period approaches with no intended REPORT messages being
generated, the entity acting as a Control Framework UAS for the
interaction MUST generate a REPORT message containing, as defined in
this paragraph, a 'Status' header of 'update' with no associated
payload. Such a message acts as a timeout refresh and in no way
impacts the extended transaction, because no message body or
semantics are permitted. It is RECOMMENDED that a minimum value of
10 and a maximum value of 15 seconds be used for the value of the
'Timeout' message header. It is also RECOMMENDED that a Control
Server refresh the timeout period of the CONTROL transaction at an
interval that is not too close to the expiry time. A value of 80% of
the timeout period could be used, for example a timeout period of 10
seconds would be refreshed after 8 seconds.
Subsequent REPORT messages that provide additional information
relating to the extended CONTROL transaction MUST also include and
increment by 1 the 'Seq' header value. They MUST also include a
'Status' header with a value of 'update'. These REPORT messages sent
to update the extended CONTROL transaction status MAY contain a
message body, as defined by individual Control Packages and specified
in Section 9.5. A REPORT message sent updating the extended
transaction also acts as a timeout refresh, as described earlier in
this section. This will result in a transaction timeout period at
the initiator of the original CONTROL request being reset to the
interval contained in the 'Timeout' message header.
When all processing for an extended CONTROL transaction has taken
place, the entity acting as a Control Server MUST send a terminating
REPORT message. The terminating REPORT message MUST increment the
Boulton, et al. Expires May 28, 2009 [Page 20]
Internet-Draft Media Control Channel Framework November 2008
value in the 'Seq' message header by the value of '1' from the
previous REPORT message. It MUST also include a 'Status' header with
a value of 'terminate' and MAY contain a message body. A Control
Framework UAC can then clean up any pending state associated with the
original control transaction.
6.3.3. K-ALIVE Transactions
The protocol defined in this document may be used in various network
architectures. This will include a wide range of deployments where
the clients could be co-located in a secured, private domain, or
spread across disparate domains that require traversal of devices
such as Network Address Translators (NAT) and Firewalls. A keep
alive mechanism enables the control channel to be kept active during
times of inactivity (for example, most Firewalls have a timeout
period after which connections are closed). This mechanism also
provides the ability for application level failure detection. It
should be noted that the following procedures apply explicitly to the
control channel being created. For details relating to a SIP keep
alive mechanism, implementers should seek guidance from SIP Outbound
[I-D.ietf-sip-outbound].
The following keep alive procedures MUST be implemented. Specific
deployments MAY choose not to use the keep alive mechanism if both
entities are in a co-located domain. Note that choosing not to use
the keep alive mechanism defined in this section, even when in a co-
located architecture, will reduce the ability to detect application
level errors - especially during long periods of in-activity.
Once the SIP dialog has been established and the underlying control
channel has been set-up (including the initial correlation handshake
using SYNC as discussed in Section 6), both entities acting in the
'active' and 'passive' roles (as defined in COMEDIA [RFC4145]) MUST
start a keep alive timer equal to the value negotiated during the
control channel SYNC request/response exchange (the value from the
'Keep-Alive' header in seconds).
6.3.3.1. Behaviour for an Entity in an Active Role
When acting in an 'active' role, a 'K-ALIVE' Control Framework
message MUST be generated before the local keep alive timer fires.
An active entity is free to send the K-ALIVE Control Framework
message whenever it chooses. A guideline of 80% of the local keep
alive timer is suggested. On receiving a 200 OK Control Framework
message for the K-ALIVE request, the 'active' entity MUST reset the
local keep alive timer. If no 200 OK response is received to the
K-ALIVE Control Framework message (or a transport level problem is
detected by some other means) before the local keep alive timer
Boulton, et al. Expires May 28, 2009 [Page 21]
Internet-Draft Media Control Channel Framework November 2008
fires, the 'active' entity SHOULD tear down the SIP dialog and
recover the associated control channel resources. The 'active'
entity MAY choose to try and recover the connection by renegotiation
using COMEDIA.
6.3.3.2. Behaviour for an Entity in an Passive Role
When acting as a 'passive' entity, a 'K-ALIVE' Control Framework
message must be received before the local keep alive timer fires.
When a K-ALIVE request is received, the 'passive' entity MUST
generate a 200 OK control framework response and reset the local keep
alive timer. No other Control Framework response is valid. If no
K-ALIVE message is received (or a transport level problem is detected
by some other means) before the local keep alive timer fires, the
'passive' entity SHOULD tear down the SIP dialog and recover the
associated control channel resources. The 'active' entity MAY try to
and recover the connection by renegotiating using COMEDIA.
6.3.4. SYNC Transactions
The initial SYNC request on a control channel is used to negotiate
the timeout period for the control-channel keep alive mechanism and
to allow clients and servers to learn the Control Packages that each
supports. Subsequent SYNC requests may be used to change the set of
Control Packages that can be used on the control-channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the control-
channel keep alive mechanism to be negotiated. The following rules
SHOULD be followed for the initial SYNC request:
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'active', the 'Keep-Alive' header MUST be
included in the SYNC message generated by the offerer. The value
of the 'Keep-Alive' header SHOULD be in the range of 95 and 120
seconds (this is consistent with SIP
Outbound[I-D.ietf-sip-outbound]). The client that generated the
SDP "Answer" ('passive' client) MUST copy the 'Keep-Alive' header
into the 200 response to the SYNC message with the same value.
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'passive', the 'Keep-Alive' header parameter
MUST be included in the SYNC message generated by the answerer.
The value of the 'Keep-Alive' header SHOULD be in the range of 95
and 120 seconds. The client that generated the SDP "Offer"
('passive' client) MUST copy the 'Keep-Alive' header into the 200
response to the SYNC message with the same value.
Boulton, et al. Expires May 28, 2009 [Page 22]
Internet-Draft Media Control Channel Framework November 2008
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'actpass', the 'Keep-Alive' header parameter
MUST be included in the SYNC message of the entity who is the
'Active' participant in the SDP session. If the client generating
the subsequent SDP 'Answer' places a value of 'active' in the
COMEDIA SDP 'setup' attribute, it will generate the SYNC request
and include the 'Keep-Alive' header. The value SHOULD be in the
range 95 to 120 seconds. If the client generating the subsequent
SDP 'Answer' places a value of 'passive' in the COMDEDIA 'setup'
attribute, the original 'Offerer' will generate the SYNC request
and include the 'Keep-Alive' header. The value SHOULD be in the
range 95 to 120 seconds.
o If the initial negotiated offer/answer results in a COMEDIA
'setup' attribute equal to 'holdconn', the initial SYNC mechanism
will occur when the offer/answer exchange is updated and active/
passive roles are delegated using COMEDIA.
The previous steps ensures that the entity initiating the control
channel connection is always the one specifying the keep alive
timeout period. It will always be the initiator of the connection
who generates the 'K-ALIVE' Control Framework level messages.
Once negotiated, the keep alive timeout applies for the remainder of
the Control Framework session. Any subsequent SYNC messages
generated in the control channel do not impact the negotiated keep
alive property of the session. The "Keep-Alive" header MUST NOT be
included in subsequent SYNC messages and if it is received it MUST be
ignored.
6.3.4.2. Package Negotiation
As part of the SYNC message exchange a client generating the request
MUST include a "Packages" header, as defined in Section 9. The
"Packages" header will contain a list of all Control Framework
packages that can be supported within this control session (from the
perspective of the client creating the SYNC message). All tokens
MUST be Channel Framework packages that adhere to the rules set out
in Section 8. The "Packages" header of the initial SYNC message MUST
contain at least one value.
A server receiving the initial SYNC request MUST examine the contents
of the "Packages" header. If the server supports at least one of the
packages listed in the request, it MUST respond with a 200 response
code. The response MUST contain a "Packages" header that lists the
supported packages that are in common with those from the "Packages"
header of the request (either all or a subset). This list forms a
common set of Control Packages that are supported by both parties.
Any Control Packages supported by the server that are not listed in
Boulton, et al. Expires May 28, 2009 [Page 23]
Internet-Draft Media Control Channel Framework November 2008
the "Packages" header of the SYNC request, MAY be placed in the
"Supported" header of the response. This provides a hint to the
client that generated the SYNC request of the additional packages
supported by the server.
If no common packages are supported by the server receiving the SYNC
message, it MUST respond with a 422 error response code. The error
response MUST contain a "Supported" header indicating the packages
that are supported. The initiating client can then choose to either
re-submit a new SYNC message based on the 422 response or consider
the interaction as a failure. This would lead to termination of the
associated SIP dialog by sending a SIP BYE request, as per [RFC3261].
Once the initial SYNC transaction is completed, either client MAY
choose to send a subsequent new SYNC Control Framework message to re-
negotiate the packages that are supported within the control channel.
A new SYNC message whose Packages header has different values from
the previous SYNC message can effectively add and delete the packages
used in the control channel. If a client receiving a subsequent SYNC
message does not wish to change the set of packages, it MUST respond
with a 421 Control Framework response code. Subsequent SYNC messages
MUST NOT change the value of the "Dialog-ID" and "Keep-Alive" Control
Framework headers that appeared in the original SYNC negotiation.
Any Control Framework commands relating to a Control Package that is
no longer supported by the session which are received after package
re-negotiation SHOULD be responded to with a 420 response. An entity
MAY choose to honor such commands for a limited period of time but
this is implementation specific.
7. Response Code Descriptions
The following response codes are defined for transaction responses to
methods defined in Section 6.1. All response codes in this section
MUST be supported and can be used in response to both CONTROL and
REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message.
Note that these response codes apply to framework transactions only.
Success or error indications for control commands MUST be treated as
the result of a control command and returned in either a 200 response
or REPORT message.
7.1. 200 Response Code
The 200 code indicates the completion of a successful framework
protocol transaction.
Boulton, et al. Expires May 28, 2009 [Page 24]
Internet-Draft Media Control Channel Framework November 2008
7.2. 202 Response Code
The 202 response code indicates the completion of a successful
framework protocol transaction with additional information to be
provided at a later time through the REPORT mechanism defined in
Section 6.3.2.
7.3. 400 Response Code
The 400 response indicates that the request was syntactically
incorrect.
7.4. 403 Response Code
The server understood the request, but is refusing to fulfill it.
The request SHOULD NOT be repeated.
7.5. 405 Response Code
Method not allowed. The primitive is not supported.
7.6. 420 Response Code
Intended target of the request is for a Control Package that is not
valid for the current session.
7.7. 421 Response Code
Recipient does not wish to re-negotiate Control Packages at this
moment in time.
7.8. 422 Response Code
Recipient does not support any Control Packages listed in the SYNC
message.
7.9. 423 Response Code
Recipient has an existing transaction with the same transaction ID.
7.10. 481 Response Code
The 481 response indicates that the transaction of the request does
not exist. In response to a SYNC request, it indicates that the
corresponding SIP dialog does not exist.
Boulton, et al. Expires May 28, 2009 [Page 25]
Internet-Draft Media Control Channel Framework November 2008
7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the
request
8. Control Packages
"Control Packages" are intended to specify behavior that extends the
the capability defined in this document. "Control Packages" are not
allowed to weaken "MUST" and "SHOULD" strength statements that are
detailed in this document. A "Control Package" MAY strengthen
"SHOULD" to "MUST" if justified by the specific usage of the
framework.
In addition to normal sections expected in a standards-track RFC and
SIP extension documents, authors of "Control Packages" need to
address each of the issues detailed in the following subsections.
The following sections MUST be used as a template and included
appropriately in all Control-Packages. To reiterate, the following
sections do not solely form the basis of all Control-Package
structure but are included as a minimum to provide essential package
level information. A Control-Package can take any valid form it
wishes as long as the following sections are additionally included.
8.1. Control Package Name
This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the
token. Information on registering control package tokens is
contained in Section 12. The package name MUST also register a
version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be
registered where appropriate. An initial version of a package MUST
start with the value '1.0'. Subsequent versions MUST increment this
number if the same package name is to be used. The exact increment
is left to the discretion of the package author. It is RECOMMENDED
that package authors make a clear statement on backwards
compatibility with any new version.
8.2. Framework Message Usage
The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no
limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document should
explicitly detail the control messages that can be used as well as
Boulton, et al. Expires May 28, 2009 [Page 26]
Internet-Draft Media Control Channel Framework November 2008
provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type.
8.3. Common XML Support
This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required, as
defined and discussed in Section 16.1 in Appendix A. The Control
Package will make strong statements (using language from RFC 2119
[RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is
to be supported. If only part of the schema is required (for example
just 'connectionid' or just conferenceid), the Control Package will
make equally strong (using language from RFC 2119 [RFC2119])
statements.
8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in
Section 6 (or that no control package body is required). This
section should indicate the location of detailed syntax definitions
and semantics for the appropriate MIME[RFC2045] body type that apply
to a CONTROL command request and optionally the associated 200
response.
8.5. REPORT Message Bodies
This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in
Section 6 (or that no report package body is required). This section
should indicate the location of detailed syntax definitions and
semantics for the appropriate MIME[RFC2045] body type. It should be
noted that the Control Framework specification does allow for
payloads to exist in 200 responses to CONTROL messages (as defined in
this document). An entity that is prepared to receive a payload type
in a REPORT message MUST also be prepared to receive the same payload
in a 200 response to a CONTROL message.
8.6. Audit
Auditing of various control package properties such as capabilities
and resources (meta package level information) is extremely useful.
Such meta-data usually has no direct impact on control framework
interactions but allows for contextual information to be learnt.
Control Packages are encouraged to make use of Control Framework
interactions to provide relevant package audit information.
This section should include information including:
Boulton, et al. Expires May 28, 2009 [Page 27]
Internet-Draft Media Control Channel Framework November 2008
o If an auditing capability is available in this package.
o How auditing information is triggered (for example, using Control
framework CONTROL message) and delivered (for example in a Control
Framework 200 response).
o The location of the audit query and response format for the
payload (for example, it could be a separate XML schema OR part of
a larger XML schema).
8.7. Examples
It is strongly recommended that Control Packages provide a range of
message flows that represent common flows using the package and this
framework document.
9. Formal Syntax
9.1. Control Framework Formal Syntax
The Control Framework interactions use the UTF-8 transformation
format as defined in [RFC3629]. The syntax in this section uses the
Augmented Backus-Naur Form (ABNF) as defined in [RFC2234].
control-req-or-resp = control-request / control-response
control-request = control-req-start *headers CRLF [control-content]
control-response = control-resp-start *headers CRLF [control-content]
control-req-start = pCFW SP transact-id SP method CRLF
control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text
pCFW = %x43.46.57; CFW in caps
transact-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNC = %x53.59.4E.43; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps
other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF
header-name = (Content-Length
/Content-Type
/Control-Package
/Status
Boulton, et al. Expires May 28, 2009 [Page 28]
Internet-Draft Media Control Channel Framework November 2008
/Seq
/Timeout
/Dialog-id
/Packages
/Supported
/Keep-alive
/ext-header) CRLF
Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supported-alphanum *(COMMA supported-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token
package-name = alpha-num-token
supported-alphanum = alpha-num-token
kalive-seconds = 1*DIGIT
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "="
control-content = *OCTET
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
Boulton, et al. Expires May 28, 2009 [Page 29]
Internet-Draft Media Control Channel Framework November 2008
ext-header = hname ":" SP hval CRLF
hname = ALPHA *token
hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UPALPHA = %x41-5A
UTF8-NONASCII = %xC0-DF UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
The following table details a summary of the headers that can be
contained in Control Framework interactions. The "where" columns
details where headers can be used:
R: header field may only appear in requests;
r: header field may only appear in responses;
Blank indicates the header field may appear in either requests or responses.
2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used;
An empty entry in the "where" column indicates that the header
field may be present in all requests and responses.
The remaining columns list the specified methods and the presence of
a specific header:
m: The header field is mandatory.
o: The header field is optional.
-: The header field is not applicable (ignored if present).
Boulton, et al. Expires May 28, 2009 [Page 30]
Internet-Draft Media Control Channel Framework November 2008
Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________
Content-Length o o - -
Control-Package R m - - -
Seq - m - -
Status R - m - -
Timeout R - m - -
Timeout 202 - m - -
Dialog-ID R - - m -
Packages - - m -
Supported r - - o -
Keep-Alive R - - o -
Content-Type o o - -
Figure 3: Table 1
9.2. Control Framework Dialog Identifier SDP Attribute
This specification defines a new media-level value attribute:
'cfw-id'. Its formatting in SDP is described by the following
ABNF[RFC5234].
cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF
cfw-id-name = token
token = 1*(token-char)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
The token-char and token elements are defined in [RFC4566] but
included here to provide support for the implementer of this SDP
feature.
10. Examples
The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document.
In this example, the Control Client establishes a control channel,
SYNCs with the Control Server, and issues a CONTROL request that
Boulton, et al. Expires May 28, 2009 [Page 31]
Internet-Draft Media Control Channel Framework November 2008
can't be completed within the 'Transaction-Timeout', so the Control
Server returns a 202 response code to extend the transaction. The
Control Server then follows with REPORTs until the requested action
has been completed. The SIP dialog is then terminated.
Control Client Control Server
| |
| (1) SIP INVITE |
| ----------------------------------------> |
| |
| (2) SIP 200 |
| <--------------------------------------- |
| |
| (3) SIP ACK |
| ----------------------------------------> |
| |
|==>=======================================>==|
| Control Channel Established |
|==>=======================================>==|
| |
| (4) SYNC |
| ----------------------------------------> |
| |
| (5) 200 |
| <--------------------------------------- |
| |
| (6) CONTROL |
| ----------------------------------------> |
| |
| (7) 202 |
| <--------------------------------------- |
| |
| (8) REPORT (update) |
| <---------------------------------------- |
| |
| (9) 200 |
| ----------------------------------------> |
| |
| (10) REPORT (update) |
| <---------------------------------------- |
| |
| (11) 200 |
| ----------------------------------------> |
| |
| (12) REPORT (terminate) |
| <---------------------------------------- |
| |
Boulton, et al. Expires May 28, 2009 [Page 32]
Internet-Draft Media Control Channel Framework November 2008
| (13) 200 |
| ----------------------------------------> |
| |
| (14) SIP BYE |
| ----------------------------------------> |
| |
| (15) SIP 200 |
| <--------------------------------------- |
|=============================================|
| Control Channel Terminated |
|=============================================|
| |
1. Control Client->Control Server (SIP): INVITE
sip:control-server@example.com
INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp
Cotent-Length: [..]
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 control-client.example.com
m=application 7575 TCP/CFW
a=setup:active
a=connection:new
a=cfw-id:fndskuhHKsd783hjdla
2. Control Server->Control Client (SIP): 200 OK
Boulton, et al. Expires May 28, 2009 [Page 33]
Internet-Draft Media Control Channel Framework November 2008
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc2.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 control-server.example.com
m=application 7575 TCP/CFW
a=setup:passive
a=connection:new
a=cfw-id:fndskuhHKsd783hjdla
3. Control Client->Control Server (SIP): ACK
4. Control Client opens a TCP connection to the Control Server.
The connection can now be used to exchange control framework
messages. Control Client-->Control Server (Control Framework
Message): SYNC.
CFW 8djae7khauj SYNC
Dialog-ID: fndskuhHKsd783hjdla
K-Alive: 100
Packages: msc-ivr-basic/1.0
5. Control Server-->Control Client (Control Framework Message):
200.
CFW 8djae7khauj 200
Keep-Alive: 100
Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
6. Once the SYNC process has completed, the connection can now be
used to exchange control framework messages. Control
Client-->Control Server (Control Framework Message): CONTROL.
Boulton, et al. Expires May 28, 2009 [Page 34]
Internet-Draft Media Control Channel Framework November 2008
CFW i387yeiqyiq CONTROL
Control-Package: <package-name>
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/>
7. Control Server-->Control Client (Control Framework Message):
202.
CFW i387yeiqyiq 202
Timeout: 10
8. Control Server-->Control Client (Control Framework Message):
REPORT.
CFW i387yeiqyiq REPORT
Seq: 1
Status: update
Timeout: 10
9. Control Client-->Control Server (Control Framework Message):
200.
CFW i387yeiqyiq 200
Seq: 1
10. Control Server-->Control Client (Control Framework Message):
REPORT.
CFW i387yeiqyiq REPORT
Seq: 2
Status: update
Timeout: 10
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/>
11. Control Client-->Control Server (Control Framework Message):
200.
CFW i387yeiqyiq 200
Seq: 2
Boulton, et al. Expires May 28, 2009 [Page 35]
Internet-Draft Media Control Channel Framework November 2008
12. Control Server-->Control Client (Control Framework Message):
REPORT.
CFW i387yeiqyiq REPORT
Seq: 3
Status: terminate
Timeout: 10
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/>
13. Control Client-->Control Server (Control Framework Message):
200.
CFW i387yeiqyiq 200
Seq: 3
14. Control Client->Control Server (SIP): BYE
BYE sip:control-client@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com
15. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com
11. Security Considerations
The Channel Framework provides confidentiality and integrity for the
messages it transfers. It also provides assurances that the
connected host is the host that it meant to connect to and that the
connection has not been hijacked.
The Channel Framework in design complies with the security-related
requirements documented in the control protocol requirements
document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12
REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by
Boulton, et al. Expires May 28, 2009 [Page 36]
Internet-Draft Media Control Channel Framework November 2008
the Channel Framework are summarized in the following subsections.
11.1. Session Establishment
Channel Framework sessions are established as media sessions
described by SDP within the context of a SIP dialog. In order to
ensure secure rendezvous between Control Framework clients and
servers, the Media Channel Control Framework should make full use of
mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP
attribute results in important session information being carried
across the SIP network. For this reason SIP clients using this
specification MUST use appropriate security mechanisms, such as
TLS[RFC4346] and SMIME[RFC3851], when deployed in open networks.
11.2. Transport Level Protection
When using only TCP connections, the Channel Framework security is
weak. Although the Channel Framework requires the ability to protect
this exchange, there is no guarantee that the protection will be used
all the time. If such protection is not used, anyone can see data
exchanges.
Sensitive data, such as private and financial data, is carried over
the Control Framework channel. Clients and servers must be properly
authenticated/authorized and the control channel must permit the use
of confidentiality, replay protection and integrity for the data. To
ensure control channel protection, Control Framework clients and
servers MUST support TLS and SHOULD use it by default unless
alternative control channel protection is used or a protected
environment is guaranteed by the deployer of the network.
Alternative control channel protection MAY be used if desired
(e.g.IPSEC).
TLS is used to authenticate devices and to provide integrity, replay
protection and confidentiality for the header fields being
transported on the control channel. Channel Framework elements MUST
implement TLS and MUST also implement the TLS ClientExtendedHello
extended hello information for server name indication as described in
[RFC4366]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other
cipher-suites MAY also be supported.
11.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control
channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create
Boulton, et al. Expires May 28, 2009 [Page 37]
Internet-Draft Media Control Channel Framework November 2008
connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to
overcome such conflicts but will provide a summary of how it can be
achieved.
It can be determined that access to resources and use of control
channels relates to policy. It can be considered implementation and
deployment detail that dictates the level of policy that is adopted.
The authorization and associated policy of a control channel can be
linked to the authentication mechanisms described in this section.
For example, strictly authenticating a control channel either using
SIP digest or TLS authentication allows entities to protect resources
and ensure the required level of granularity. Such policy can be
applied at the package level or even as low as a structure like a
conference instance (control channel X is not permitted to issue
commands for control package y OR control channel A is not permitted
to issue commands for conference instance B). Systems should ensure
that if required, an appropriate policy framework is adopted to
satisfy the requirements for implemented packages. The most robust
form of policy can be achieved using a strong authentication
mechanism such as mutual TLS authentication on the control channel.
This specification provide a control channel response code(403) to
indicate to the issuer of a command that it is not permitted. It
should be noted that additional policy requirements to those covered
in this section might be defined and applied in individual packages
that specify a finer granularity for access to resources etc.
12. IANA Considerations
This specification instructs IANA to create a new registry for SIP
Control Framework parameters. The Channel Framework Parameter
registry is a container for sub-registries. This section further
introduces sub-registries for Channel Framework packages, method
names, status codes, header field names, port and transport protocol.
Additionally, Section 12.6 registers new parameters in existing IANA
registries.
12.1. Control Packages Registration Information
This specification establishes the Control Packages sub-registry
under Control Framework Packages. New parameters in this sub-
registry must be published in an RFC (either as an IETF submission or
RFC Editor submission), using the IANA policy [RFC5226] "RFC
Required".
Boulton, et al. Expires May 28, 2009 [Page 38]
Internet-Draft Media Control Channel Framework November 2008
As this document specifies no package or template-package names, the
initial IANA registration for control packages will be empty. The
remainder of the text in this section gives an example of the type of
information to be maintained by the IANA; it also demonstrates all
three possible permutations of package type, contact, and reference.
The table below lists the control packages defined in the "Media
Control Channel Framework".
Package Name Contact Reference
------------ ------- ---------
example1 [Boulton]
example2 [Boulton] [RFCXXX]
example3 [RFCXXX]
12.1.1. Control Package Registration Template
To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package
Package Name:
(Package names must conform to the syntax described in
section 8.1.)
Published Specification(s):
(Control packages require a published RFC.).
Person & email address to contact for further information:
12.2. Control Framework Method Names
This specification establishes the Methods sub-registry under Control
Framework Parameters and initiates its population as follows. New
parameters in this sub-registry must be published in an RFC (either
as an IETF submission or RFC Editor submission).
CONTROL - [RFCXXX]
REPORT - [RFCXXX]
SYNC - [RFCXXX]
The following information MUST be provided in an RFC publication in
Boulton, et al. Expires May 28, 2009 [Page 39]
Internet-Draft Media Control Channel Framework November 2008
o The method name.
o The RFC number in which the method is registered.
12.3. Control Framework Status Codes
This specification establishes the Status-Code sub-registry under
Channel Framework Parameters. New parameters in this sub-registry
must be published in an RFC (either as an IETF submission or RFC
Editor submission). Its initial population is defined in Section 9.
It takes the following format:
Code [RFC Number]
The following information MUST be provided in an RFC publication in
order to register a new Control Framework status code:
o The status code number.
o The RFC number in which the method is registered.
12.4. Control Framework Header Fields
This specification establishes the header field-Field sub-registry
under Channel Framework Parameters. New parameters in this sub-
registry must be published in an RFC (either as an IETF submission or
RFC Editor submission). Its initial population is defined as
follows:
Control-Package - [RFCXXXX]
Status - [RFCXXXX]
Seq - [RFCXXXX]
Timeout - [RFCXXXX]
Dialog-id - [RFCXXXX]
Packages - [RFCXXXX]
Supported - [RFCXXXX]
Keep-Alive - [RFCXXXX]
Content-Type - [RFCXXXX]
Content-Length - [RFCXXXX]
The following information MUST be provided in an RFC publication in
order to register a new Channel Framework header field:
o The header field name.
o The RFC number in which the method is registered.
Boulton, et al. Expires May 28, 2009 [Page 40]
Internet-Draft Media Control Channel Framework November 2008
12.5. Control Framework Port
The Control Framework uses TCP port XXXX, from the "registered" port
range. Usage of this value is described in Section 4.1.
12.6. SDP Transport Protocol
The Channel Framework defines the new SDP protocol field values 'TCP/
CFW', 'TCP/TLS/CFW', 'SCTP/CFW' and 'SCTP/TLS/CFW", which should be
registered in the sdp-parameters registry under "proto". The values
have the following meaning:
o TCP/CFW: Indicates the SIP Channel Framework when TCP is used as
an underlying transport for the control channel.
o TCP/TLS/CFW: Indicates the Channel Framework when TLS over TCP is
used as an underlying transport for the control channel.
o SCTP/CFW: Indicates the Channel Framework when SCTP is used as an
underlying transport for the control channel.
o SCTP/TLS/CFW: Indicates the Channel Framework when TLS over SCTP
is used as an underlying transport for the control channel.
Specifications defining new protocol values must define the rules for
the associated media format namespace. The 'TCP/CFW', 'TCP/TLS/CFW',
'SCTP/CFW' and 'SCTP/TLS/CFW' protocol values allow only one value in
the format field (fmt), which is a single occurrence of "*". Actual
format determination is made using the control package extension
specific payloads.
12.7. 'cfw-id' SDP Attribute
Contact name: Chris Boulton cboulton@avaya.com.
Attribute name: "cfw-id".
Type of attribute Media level.
Subject to charset: Not.
Purpose of attribute: The 'cfw-id' attribute indicates
an identifier that can be used to correlate the control
channel with the SIP dialog used to negotiate it, when
the attribute value is used within the control channel.
Allowed attribute values: A token.
Boulton, et al. Expires May 28, 2009 [Page 41]
Internet-Draft Media Control Channel Framework November 2008
12.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:control:framework-attributes", per the
guidelines in RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (cboulton@avaya.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
12.9. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Chris Boulton (cboulton@avaya.com).
Schema: The XML for this schema can be found as the entirety of
Section 16 of this document.
Boulton, et al. Expires May 28, 2009 [Page 42]
Internet-Draft Media Control Channel Framework November 2008
12.10. MIME Media Type Registration for 'application/
framework-attributes+xml'
This section registers the "application/framework-attributes+xml"
MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/framework-attributes+xml
MIME media type name: application
MIME subtype name: framework-attributes+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2.
Security considerations: No known security considerations outside
of those provided by core Media Control Channel Framework.
Interoperability considerations: This content type provides common
constructs for related Media Control Channel packages.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]
Applications which use this media type: Implementations of appropriate
Media Control Channel packages.
Additional Information: Magic Number(s): (none)
File extension(s): .xml
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Chris
Boulton <cboulton@avaya.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: None.
13. Changes
Note to RFC Editor: Please remove this whole section.
13.1. Changes from 06 Version
o Added 202 Timeout entry to table.
o Fixed some general nits and language.
o Fixed ABNF to be 'control-content = *OCTET'.
Boulton, et al. Expires May 28, 2009 [Page 43]
Internet-Draft Media Control Channel Framework November 2008
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.
13.2. Changes from 05 Version
o Reworded 'must' used in Introduction.
o Added urn namespace definition in IANA section.
o Added XML schema registration in IANA section.
o Added MIME registration in IANA section.
13.3. Changes from 04 Version
o Fixed nits as reported by Brian Weis.
o Amended Security text as per secdir review.
o Removed optional 'label' part of dialog identifier as per interim
call.
o Added clarifying text at the beginning of section 4 to help
describe what the section is about.
o Added text at the beginning of section 8 clarifying that the
template is not the basis for packages BUT only needs to be
included as part of a Control Package.
13.4. Changes from 03 Version
o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at
the package level.
o Scrubbed ABNF + XML.
13.5. Changes from 02 Version
o RAI review version. See comments.
o Fixed broken IANA subsections ordering + naming.
13.6. Changes from 01 Version
o Restructured text for readability.
o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no
payload.
Boulton, et al. Expires May 28, 2009 [Page 44]
Internet-Draft Media Control Channel Framework November 2008
o Replaced construction of dialog-id with new SDP parameter and
revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in
processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text.
o Added Default port text - as per meeting.
o Added Audit text.
13.7. Changes from 00 Version
o Aligned tokens to be 'CFW' (removed ESCS).
o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response.
o Added '405' method not allowed.
o Added IANA section.
o Added Security Considerations section (used MSRP and MRCPv2 as a
template).
o Removed noisy initial REPORT message - *Lorenzo please check
text*.
o Fixed ABNF - PLEASE CHECK.
o Removed separate event mechanism and now all tied to CONTROL
transaction (extended).
o General scrub of text.
o Organised 'Editors Notes' for discussion on the mailing list.
o Fixed ABNF in relation to extra CRLF on Content-Type.
14. Contributors
Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document.
15. Acknowledgments
The authors would like to thank Ian Evans and Michael Bardzinski of
Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and
input to this work. Eric Burger contributed to the early phases of
this work.
Boulton, et al. Expires May 28, 2009 [Page 45]
Internet-Draft Media Control Channel Framework November 2008
Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and
provided a great deal of invaluable input. Brian Weis carried out a
thorough security review. Text from Eric Burger was used in the
introduction in the explanation for using SIP.
16. Appendix A
During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages.
16.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing
Control Packages to apply specific commands to a particular SIP media
dialog (also referred to as Connection) or conference. If used
within a Control Package the Connection and multiparty attributes
will be imported and used appropriately to specifically identify
either a SIP dialog or a conference instance. If used within a
package, the value contained in the 'connectionid' attribute MUST be
constructed by concatenating the 'Local' and 'Remote' SIP dialog
identifier tags as defined in [RFC3261]. They MUST then be separated
using the '~' character. So the format would be:
'Local Dialog tag' + '~' + 'Remote Dialog tag'
As an example, for an entity that has a SIP Local dialog identifier
of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the
'connectionid' attribute for a Control Framework command would be:
7HDY839~HJKSkyHS
It should be noted that Control Framework requests initiated in
conjunction with a SIP dialog will produce a different 'connectionid'
value depending on the directionality of the request, for example
Local and Remote tags are locally identifiable.
As with the Connection attribute previously defined, it is also
Boulton, et al. Expires May 28, 2009 [Page 46]
Internet-Draft Media Control Channel Framework November 2008
useful to have the ability to apply specific control framework
commands to a number of related dialogs, such as a multiparty call.
This typically consists of a number of media dialogs that are
logically bound by a single identifier. The following schema allows
for control framework commands to explicitly reference such a
grouping through a 'conf' XML container. If used by a Control
Package, any control XML referenced by the attribute applies to all
related media dialogs. Unlike the dialog attribute, the
'conferenceid' attribute does not need to be constructed based on the
overlying SIP dialog. The 'conferenceid' attribute value is system
specific and should be selected with relevant context and uniqueness.
The full schema follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>
17. References
17.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Boulton, et al. Expires May 28, 2009 [Page 47]
Internet-Draft Media Control Channel Framework November 2008
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Boulton, et al. Expires May 28, 2009 [Page 48]
Internet-Draft Media Control Channel Framework November 2008
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
17.2. Informative References
[I-D.burger-mscl-thoughts]
Burger, E., "Media Server Control Language and Protocol
Thoughts", draft-burger-mscl-thoughts-01 (work in
progress), June 2006.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress),
October 2008.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
Boulton, et al. Expires May 28, 2009 [Page 49]
Internet-Draft Media Control Channel Framework November 2008
Authors' Addresses
Chris Boulton
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com
Tim Melanchuk
Rain Willow Communications
Email: tim.melanchuk@gmail.com
Scott McGlashan
Hewlett-Packard
Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com
Boulton, et al. Expires May 28, 2009 [Page 50]
Internet-Draft Media Control Channel Framework November 2008
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.
Boulton, et al. Expires May 28, 2009 [Page 51]
