draft-ietf-mediactrl-sip-control-framework-04.txt   draft-ietf-mediactrl-sip-control-framework-05.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft Avaya
Expires: February 21, 2009 T. Melanchuk Expires: April 24, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
August 20, 2008 October 21, 2008
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-04 draft-ietf-mediactrl-sip-control-framework-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 21, 2009. This Internet-Draft will expire on April 24, 2009.
Abstract Abstract
This document describes a Framework and protocol for application This document describes a Framework and protocol for application
deployment where the application programming logic and processing are deployment where the application programming logic and processing are
distributed. This implies that application programming logic can distributed. This implies that application programming logic can
seamlessly gain access to appropriate resources that are not co- seamlessly gain access to appropriate resources that are not co-
located on the same physical network entity. The framework uses the located on the same physical network entity. The framework uses the
Session Initiation Protocol (SIP) to establish an application-level Session Initiation Protocol (SIP) to establish an application-level
control mechanism between application servers and associated external control mechanism between application servers and associated external
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15 6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 16 6.1. General Behaviour for Constructing Requests . . . . . . . 17
6.2. General Behaviour for Constructing Responses . . . . . . . 17 6.2. General Behaviour for Constructing Responses . . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18 6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 20 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 25 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 26 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 26 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 27 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 30 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 36 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37
11.2. Transport Level Protection . . . . . . . . . . . . . . . . 36 11.2. Transport Level Protection . . . . . . . . . . . . . . . . 37
11.3. Control Channel Policy Management . . . . . . . . . . . . 37 11.3. Control Channel Policy Management . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Control Packages Registration Information . . . . . . . . 38 12.1. Control Packages Registration Information . . . . . . . . 38
12.1.1. Control Package Registration Template . . . . . . . . 38 12.1.1. Control Package Registration Template . . . . . . . . 39
12.2. Control Framework Method Names . . . . . . . . . . . . . . 38 12.2. Control Framework Method Names . . . . . . . . . . . . . . 39
12.3. Control Framework Status Codes . . . . . . . . . . . . . . 39 12.3. Control Framework Status Codes . . . . . . . . . . . . . . 40
12.4. Control Framework Header Fields . . . . . . . . . . . . . 39 12.4. Control Framework Header Fields . . . . . . . . . . . . . 40
12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40 12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 41
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 40 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 41
13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 41 13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 41
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Changes from 03 Version . . . . . . . . . . . . . . . . . 41 14.1. Changes from 04 Version . . . . . . . . . . . . . . . . . 42
14.2. Changes from 02 Version . . . . . . . . . . . . . . . . . 41 14.2. Changes from 03 Version . . . . . . . . . . . . . . . . . 42
14.3. Changes from 01 Version . . . . . . . . . . . . . . . . . 41 14.3. Changes from 02 Version . . . . . . . . . . . . . . . . . 42
14.4. Changes from 00 Version . . . . . . . . . . . . . . . . . 42 14.4. Changes from 01 Version . . . . . . . . . . . . . . . . . 42
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.5. Changes from 00 Version . . . . . . . . . . . . . . . . . 43
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 43 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 43 17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 44
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 44
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
18.1. Normative References . . . . . . . . . . . . . . . . . . . 45 18.1. Normative References . . . . . . . . . . . . . . . . . . . 45
18.2. Informative References . . . . . . . . . . . . . . . . . . 46 18.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
Real-time media applications are often developed using an Real-time media applications are often developed using an
architecture where the application logic and processing activities architecture where the application logic and processing activities
are distributed. Commonly, the application logic runs on are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers, "application servers" but the processing runs on external servers,
such as "media servers". This document focuses on the framework and such as "media servers". This document focuses on the framework and
protocol between the application server and external processing protocol between the application server and external processing
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
requirements for Media Server Control, which can be found in the requirements for Media Server Control, which can be found in the
'Media Server Control Protocol Requirements' document[RFC5167]. 'Media Server Control Protocol Requirements' document[RFC5167].
While the Framework is not media server control specific, it is the While the Framework is not media server control specific, it is the
primary driver and use case for this work. It is intended that the primary driver and use case for this work. It is intended that the
framework contained in this document will can be used for a variety framework contained in this document can be used for a variety of
of device control scenarios (for example, conference control). device control scenarios (for example, conference control).
This document does not define a SIP protocol driven extension that This document does not define a SIP protocol driven extension that
can be used directly for the control of external components. The can be used directly for the control of external components. The
framework mechanism must be extended by other documents that are framework mechanism must be extended by other documents that are
known as "Control Packages". A comprehensive set of guidelines for known as "Control Packages". A comprehensive set of guidelines for
creating "Control Packages" is described in Section 8. creating "Control Packages" is described in Section 8.
Current IETF device control protocols, such as megaco [RFC3525], Current IETF device control protocols, such as megaco [RFC3525],
while excellent for controlling media gateways that bridge separate while excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in networks, are troublesome for supporting media-rich applications in
skipping to change at page 5, line 5 skipping to change at page 5, line 5
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST", In this document, BCP 14 [RFC2119] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant addition, BCP 15 indicates requirement levels for compliant
implementations. implementations.
The following additional terms are defined for use in this document: The following additional terms are defined for use in this document:
User Agent Client (UAC): As specified in [RFC3261].
User Agent Server (UAS): As specified in [RFC3261].
B2BUA: A B2BUA is a Back-to-Back SIP User Agent. B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
Control Server: A Control Server is an entity that performs a Control Server: A Control Server is an entity that performs a
service, such as media processing, on behalf of a Control Client. service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing, announcement, tone For example, a media server offers mixing, announcement, tone
detection and generation, and play and record services. The detection and generation, and play and record services. The
Control Server in this case, has a direct RTP [RFC3550] Control Server in this case, has a direct RTP [RFC3550]
relationship with the source or sink of the media flow. In this relationship with the source or sink of the media flow. In this
document, we often refer to the Control Server simply as "the document, we often refer to the Control Server simply as "the
Server". Server".
Control Client: A Control Client is an entity that requests Control Client: A Control Client is an entity that requests
skipping to change at page 6, line 40 skipping to change at page 6, line 40
[I-D.burger-mscl-thoughts], established the following. One might [I-D.burger-mscl-thoughts], established the following. One might
ask, "If all we are doing is establishing a TCP connection to control ask, "If all we are doing is establishing a TCP connection to control
the media server, what do we need SIP for?" This is a reasonable the media server, what do we need SIP for?" This is a reasonable
question. The key is to be using SIP for media session question. The key is to be using SIP for media session
establishment. If we are using SIP for media session establishment, establishment. If we are using SIP for media session establishment,
then we need to ensure the URI used for 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 resolves to the same node as the node for session control. Using the
SIP routing mechanism, and having the server initiate the TCP SIP routing mechanism, and having the server initiate the TCP
connection back, ensures this works. For example, the URI sip: connection back, ensures this works. For example, the URI sip:
myserver.example.com may resolve to sip: myserver.example.com may resolve to sip:
server21.farm12.northeast.example.net, whereas the server21.farm12.northeast.example.net, whereas the URI
URIhttp://myserver.example.com may resolve to http://myserver.example.com may resolve to
http://server41.httpfarm.central.example.net. That is, the host part http://server41.httpfarm.central.example.net. That is, the host part
is NOT NECESSARILY unambiguous. is NOT NECESSARILY unambiguous.
The use of SIP for to negotiate the control-channel provides many The use of SIP for to negotiate the control-channel provides many
inherent capabilities which include: inherent capabilities which include:
o Service location - Use SIP Proxies or Back-to-Back User Agents for o Service location - Use SIP Proxies or Back-to-Back User Agents for
discovering Control Servers. discovering Control Servers.
o Security mechanisms - Leverage established security mechanisms o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication. such as Transport Layer Security (TLS) and Client Authentication.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
and associated media flow. A User Agent would create a SIP dialog and associated media flow. A User Agent would create a SIP dialog
with the Control Client entity. The Control Client entity will also with the Control Client entity. The Control Client entity will also
create a related dialog to the Control Server (B2BUA type create a related dialog to the Control Server (B2BUA type
functionality). Using the interaction illustrated by (2), the functionality). Using the interaction illustrated by (2), the
Control Client negotiates media capabilities with the Control Server, Control Client negotiates media capabilities with the Control Server,
on behalf of the User Agent, using SIP Third Party Call Control on behalf of the User Agent, using SIP Third Party Call Control
[RFC3725]. [RFC3725].
4. Control Channel Setup 4. Control Channel Setup
This section describes the setup, using SIP, of the dedicated
control. Once the control channel has been established commands can
be exchanged (as discussed in Section 6).
4.1. Control Client SIP UAC Behavior 4.1. Control Client SIP UAC Behavior
When a UAC wishes to establish a control channel, it MUST construct When a UAC wishes to establish a control channel, it MUST construct
and transmit a new SIP INVITE request for control channel setup, a and transmit a new SIP INVITE request for control channel setup, a
UAC MUST construct the protocol message as defined in [RFC3261]. UAC MUST construct the protocol message as defined in [RFC3261].
If a reliable response is received (as defined [RFC3261] and If a reliable response is received (as defined [RFC3261] and
[RFC3262]), the mechanisms defined in this document are applicable to [RFC3262]), the mechanisms defined in this document are applicable to
the newly created dialog. the newly created dialog.
skipping to change at page 11, line 45 skipping to change at page 11, line 49
recommended port defined in Section 12.5. This value is not a recommended port defined in Section 12.5. This value is not a
default as a client is free to choose explicit port numbers. default as a client is free to choose explicit port numbers.
However, SDP SHOULD be configured so that the recommended port is However, SDP SHOULD be configured so that the recommended port is
used whenever appropriate. This makes life easier for network used whenever appropriate. This makes life easier for network
administrators who need to manage firewall policy for Control administrators who need to manage firewall policy for Control
Framework interactions. The third sub-field, <proto>, MUST equal a Framework interactions. The third sub-field, <proto>, MUST equal a
transport value defined in Section 12.6. All implementations transport value defined in Section 12.6. All implementations
compliant to this specification MUST support the value "TCP/CFW", compliant to this specification MUST support the value "TCP/CFW",
"TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in "TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in
Section 12.6 of this document. Implementations MUST support TLS as a Section 12.6 of this document. Implementations MUST support TLS as a
transport-level security mechanism, although use of TLS in specific transport-level security mechanism for the control channel, although
deployments is optional. Control Framework implementations MUST use of TLS in specific deployments is optional. Control Framework
support TCP as a transport protocol. Control Framework implementations MUST support TCP as a transport protocol. Control
implementations MAY support SCTP as a transport protocol. When an Framework implementations MAY support SCTP as a transport protocol.
entity identifies one of the transport values defined in Section 12.6 When an entity identifies one of the transport values defined in
but is not willing to establish the session, it MUST respond using Section 12.6 but is not willing to establish the session, it MUST
the appropriate SIP mechanism. respond using the appropriate SIP mechanism.
The SDP MUST also contain a number of SDP media attributes(a=) that The SDP MUST also contain a number of SDP media attributes(a=) that
are specifically defined in the COMEDIA [RFC4145] specification. The are specifically defined in the COMEDIA [RFC4145] specification. The
attributes provide connection negotiation and maintenance parameters. attributes provide connection negotiation and maintenance parameters.
A client conforming to this specification SHOULD support all the A client conforming to this specification SHOULD support all the
possible values defined for media attributes from the COMEDIA possible values defined for media attributes from the COMEDIA
[RFC4145] specification but MAY choose not to support values if it [RFC4145] specification but MAY choose not to support values if it
can definitely determine they will never be used (for example will can definitely determine they will never be used (for example will
only ever initiate outgoing connections). It is RECOMMENDED that a only ever initiate outgoing connections). It is RECOMMENDED that a
Controlling UAC initiate a connection to an external Server but that Controlling UAC initiate a connection to an external Server but that
skipping to change at page 17, line 10 skipping to change at page 17, line 20
on individual package requirements). Control Commands MUST also on individual package requirements). Control Commands MUST also
adhere to the syntax defined by the Control Packages negotiated in 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 Section 4.1 and Section 4.2 of this document. A Control Client MUST
create a unique control message transaction and associated identifier create a unique control message transaction and associated identifier
for insertion in the request. The transaction identifier is then for insertion in the request. The transaction identifier is then
included in the first line of a control framework message along with 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 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 line starts with the "CFW" token for the purpose of easily extracting
the transaction identifier. The transaction identifier MUST be the transaction identifier. The transaction identifier MUST be
globally unique over space and time with at least 64 bits of globally unique over space and time with at least 64 bits of
randomness. All required mandatory and optional control framework randomness. This unique property helps in the avoidance of clashes
headers are then inserted into the control message with appropriate when multiple client entities could be creating transactions to be
values (see relevant individual header information for explicit carried out on a single receiving server. All required mandatory and
detail). A "Control-Package" header MUST also be inserted with the optional control framework headers are then inserted into the control
value indicating the Control Package to which this specific request message with appropriate values (see relevant individual header
applies (Multiple packages can be negotiated per control channel information for explicit detail). A "Control-Package" header MUST
using the SYNC control message discussed in Section 6.3.4.2). 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 Any framework message that contains an associated payload MUST also
include a 'Content-Type' and 'Content-Length' message header which include a 'Content-Type' and 'Content-Length' message header which
represents the size of the message body in decimal number of octets. represents the size of the message body in decimal number of octets.
The 'Content-Type' header represents the MIME payload to be used as The 'Content-Type' header represents the MIME payload to be used as
specified by the individual control frameowrk packages. If no specified by the individual control framework packages. If no
associated payload is to be added to the message, a 'Content-Length' 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 header with a value of '0' is considered the same as one not being
present. present.
When all of the headers have been included in the framework message, When all of the headers have been included in the framework message,
it is sent down the control channel. it is sent down the control channel.
A Server receiving such a request needs to respond quickly with an A Server receiving such a request needs to respond quickly with an
appropriate response (as defined in Section 6.2). Control Clients appropriate response (as defined in Section 6.2). Control Clients
MUST wait for a minimum of 'Transaction-Timeout' for a response MUST wait for a minimum of 'Transaction-Timeout' for a response
skipping to change at page 22, line 11 skipping to change at page 22, line 25
generate a 200 OK control framework response and reset the local keep generate a 200 OK control framework response and reset the local keep
alive timer. No other Control Framework response is valid. If no alive timer. No other Control Framework response is valid. If no
K-ALIVE message is received before the local keep alive timer fires, K-ALIVE message is received before the local keep alive timer fires,
the 'passive' entity SHOULD tear down the SIP dialog and recover the the 'passive' entity SHOULD tear down the SIP dialog and recover the
associated control channel resources. The 'active' entity MAY try to associated control channel resources. The 'active' entity MAY try to
and recover the connection by renegotiating using COMEDIA. and recover the connection by renegotiating using COMEDIA.
6.3.4. SYNC Transactions 6.3.4. SYNC Transactions
The initial SYNC request on a control channel is used to negotiate The initial SYNC request on a control channel is used to negotiate
the timeout period for the control-channel keep alive mechansim and the timeout period for the control-channel keep alive mechanism and
to allow clients and servers to learn the Control Packages that each to allow clients and servers to learn the Control Packages that each
supports. Subsequent SYNC requests may be used to change the set of supports. Subsequent SYNC requests may be used to change the set of
Control Packages that can be used on the vontrol-channel. Control Packages that can be used on the control-channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction 6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the control- The initial SYNC request allows the timeout period for the control-
channel keep alive mechanism to be negotiated. The following rules channel keep alive mechanism to be negotiated. The following rules
SHOULD be followed for the initial SYNC request: SHOULD be followed for the initial SYNC request:
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'active', the 'Keep-Alive' header MUST be attribute equal to 'active', the 'Keep-Alive' header MUST be
included in the SYNC message generated by the offerer. The value 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 of the 'Keep-Alive' header SHOULD be in the range of 95 and 120
skipping to change at page 26, line 4 skipping to change at page 26, line 23
the capability defined in this document. "Control Packages" are not the capability defined in this document. "Control Packages" are not
allowed to weaken "MUST" and "SHOULD" strength statements that are allowed to weaken "MUST" and "SHOULD" strength statements that are
detailed in this document. A "Control Package" may strengthen detailed in this document. A "Control Package" may strengthen
"SHOULD" to "MUST" if justified by the specific usage of the "SHOULD" to "MUST" if justified by the specific usage of the
framework. framework.
In addition to normal sections expected in a standards-track RFC and In addition to normal sections expected in a standards-track RFC and
SIP extension documents, authors of "Control Packages" need to SIP extension documents, authors of "Control Packages" need to
address each of the issues detailed in the following subsections. address each of the issues detailed in the following subsections.
The following sections MUST be used as a template and included The following sections MUST be used as a template and included
appropriately in all Control-Packages. 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 8.1. Control Package Name
This section MUST be present in all extensions to this document and This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the include information that appears in the IANA registration of the
token. Information on registering control package tokens is token. Information on registering control package tokens is
contained in Section 12. The package name MUST also register a contained in Section 12. The package name MUST also register a
version number for the package which is separated with a '/' symbol version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be e.g. package_name/1.0. This enables updates to the package to be
skipping to change at page 33, line 4 skipping to change at page 33, line 18
| | | |
| (15) SIP 200 | | (15) SIP 200 |
| <--------------------------------------- | | <--------------------------------------- |
|=============================================| |=============================================|
| Control Channel Terminated | | Control Channel Terminated |
|=============================================| |=============================================|
| | | |
1. Control Client->Control Server (SIP): INVITE 1. Control Client->Control Server (SIP): INVITE
sip:control-server@example.com sip:control-server@example.com
INVITE sip:control-server@example.com SIP/2.0 INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@examplae.com> To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com> Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Cotent-Length: [..] Cotent-Length: [..]
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com o=originator 2890844526 2890842808 IN IP4 controller.example,com
skipping to change at page 36, line 20 skipping to change at page 36, line 49
11. Security Considerations 11. Security Considerations
Channel Framework needs to provide confidentiality and integrity for Channel Framework needs to provide confidentiality and integrity for
the messages it transfers. It also needs to provide assurances that the messages it transfers. It also needs to provide assurances that
the connected host is the host that it meant to connect to and that the connected host is the host that it meant to connect to and that
the connection has not been hijacked. the connection has not been hijacked.
Channel Framework is designed to comply with the security-related Channel Framework is designed to comply with the security-related
requirements documented in the control protocol requirements requirements documented in the control protocol requirements
document[RFC5167]. Specific security measures employed by the document[RFC5167] (more specifically REQ-MCP-11, REQ-MCP-12
Channel Framework are summarized in the following subsections. REQ-MCP-13, and REQ-MCP-14). Specific security measures employed by
the Channel Framework are summarized in the following subsections.
11.1. Session Establishment 11.1. Session Establishment
Channel Framework sessions are established as media sessions Channel Framework sessions are established as media sessions
described by SDP within the context of a SIP dialog. In order to described by SDP within the context of a SIP dialog. In order to
ensure secure rendezvous between Control Framework clients and ensure secure rendezvous between Control Framework clients and
servers, the Media Channel Control Framework should make full use of servers, the Media Channel Control Framework should make full use of
mechanism provided by the SIP protocol. 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 should use appropriate security mechanisms, such as
TLS[RFC4346] and SMIME[RFC3851], when deployed in open networks.
11.2. Transport Level Protection 11.2. Transport Level Protection
When using only TCP connections, the Channel Framework security is When using only TCP connections, the Channel Framework security is
weak. Although the Channel Framework requires the ability to protect weak. Although the Channel Framework requires the ability to protect
this exchange, there is no guarantee that the protection will be used this exchange, there is no guarantee that the protection will be used
all the time. If such protection is not used, anyone can see data all the time. If such protection is not used, anyone can see data
exchanges. exchanges.
Sensitive data is carried over the Control Framework channel. Sensitive data is carried over the Control Framework channel.
Clients and servers must be properly authenticated and the control Clients and servers must be properly authenticated/authorized and the
channel must permit the use of both confidentiality and integrity for control channel must permit the use of confidentiality, replay
the data. To ensure control channel protection, Control Framework protection and integrity for the data. To ensure control channel
clients and servers MUST support TLS and SHOULD utilize it by default protection, Control Framework clients and servers MUST support TLS
unless alternative control channel protection is used or a protected and SHOULD utilize it by default unless alternative control channel
environment is guaranteed. Alternative control channel protection protection is used or a protected environment is guaranteed.
MAY be used if desired (e.g.IPSEC). Alternative control channel protection MAY be used if desired
(e.g.IPSEC).
TLS is used to authenticate devices and to provide integrity and TLS is used to authenticate devices and to provide integrity, replay
confidentiality for the header fields being transported on the protection and confidentiality for the header fields being
control channel. Channel Framework elements MUST implement TLS and transported on the control channel. Channel Framework elements MUST
MUST also implement the TLS ClientExtendedHello extended hello implement TLS and MUST also implement the TLS ClientExtendedHello
information for server name indication as described in [RFC4366]. A extended hello information for server name indication as described in
TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be [RFC4366]. A TLS cipher-suite of
supported (other cipher-suites MAY also be supported). TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported (other
cipher-suites MAY also be supported).
11.3. Control Channel Policy Management 11.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control This specification permits the establishment of a dedicated control
channel using SIP. It is also permitted for entities to create channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create general solution, the ability for multiple entities to create
connections and have access to resources could be the cause of connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to this document does not specifically carry any specific mechanism to
skipping to change at page 37, line 39 skipping to change at page 38, line 27
applied at the package level or even as low as a structure like a applied at the package level or even as low as a structure like a
conference instance (control channel X is not permitted to issue conference instance (control channel X is not permitted to issue
commands for control package y OR control channel A is not permitted commands for control package y OR control channel A is not permitted
to issue commands for conference instance B). Systems should ensure to issue commands for conference instance B). Systems should ensure
that if required, an appropriate policy framework is adopted to that if required, an appropriate policy framework is adopted to
satisfy the requirements for implemented packages. The most robust satisfy the requirements for implemented packages. The most robust
form of policy can be achieved using a strong authentication form of policy can be achieved using a strong authentication
mechanism such as mutual TLS authentication on the control channel. mechanism such as mutual TLS authentication on the control channel.
This specification provide a control channel response code(403) to This specification provide a control channel response code(403) to
indicate to the issuer of a command that it is not permitted. It indicate to the issuer of a command that it is not permitted. It
should be noted that additional policy requirements might be defined should be noted that additional policy requirements to those covered
and applied in individual packages that specify a finer granularity in this section might be defined and applied in individual packages
for access to resources etc. that specify a finer granularity for access to resources etc.
12. IANA Considerations 12. IANA Considerations
This specification instructs IANA to create a new registry for SIP This specification instructs IANA to create a new registry for SIP
Control Framework parameters. The Channel Framework Parameter Control Framework parameters. The Channel Framework Parameter
registry is a container for sub-registries. This section further registry is a container for sub-registries. This section further
introduces sub-registries for Channel Framework packages, method introduces sub-registries for Channel Framework packages, method
names, status codes, header field names, port and transport protocol. names, status codes, header field names, port and transport protocol.
Additionally, Section 12.6 registers new parameters in existing IANA Additionally, Section 12.6 registers new parameters in existing IANA
skipping to change at page 41, line 26 skipping to change at page 42, line 9
an identifier that can be used to correlate the control an identifier that can be used to correlate the control
channel with the SIP dialog used to negotiate it, when channel with the SIP dialog used to negotiate it, when
the attribute value is used within the control channel. the attribute value is used within the control channel.
Allowed attribute values: A token. Allowed attribute values: A token.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 03 Version 14.1. 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.
14.2. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
14.2. Changes from 02 Version 14.3. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
14.3. Changes from 01 Version 14.4. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
14.4. Changes from 00 Version 14.5. Changes from 00 Version
o Aligned tokens to be 'CFW' (removed ESCS). o Aligned tokens to be 'CFW' (removed ESCS).
o Content-Length not mandatory for messages with no payload. o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions. o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others. o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF. o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific. o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response. o Added '423' duplicate transaction ID response.
o Added '405' method not allowed. o Added '405' method not allowed.
o Added IANA section. o Added IANA section.
skipping to change at page 43, line 13 skipping to change at page 44, line 6
Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and
input to this work. Eric Burger contributed to the early phases of input to this work. Eric Burger contributed to the early phases of
this work. this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work. has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and Ben Campbell carried out the RAI expert review on this draft and
provided a great deal of invaluable input. Text from Eric Burger was provided a great deal of invaluable input. Brian Weis carried out a
used in the introduction in the explanation for using SIP. thorough security review. Text from Eric Burger was used in the
introduction in the explanation for using SIP.
17. Appendix A 17. Appendix A
During the creation of the Control Framework it has become clear that During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages. initial 'Utilities Document' that can be used by Control Packages.
skipping to change at page 43, line 47 skipping to change at page 44, line 41
using the '~' character. So the format would be: using the '~' character. So the format would be:
'Local Dialog tag' + '~' + 'Remote Dialog tag' 'Local Dialog tag' + '~' + 'Remote Dialog tag'
As an example, for an entity that has a SIP Local dialog identifier As an example, for an entity that has a SIP Local dialog identifier
of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the
'connectionid' attribute for a Control Framework command would be: 'connectionid' attribute for a Control Framework command would be:
7HDY839~HJKSkyHS 7HDY839~HJKSkyHS
If a session description has more than one media description (as
identified by 'm=' in [RFC4566]) it is possible to explicitly
reference them individually. When constructing the 'connectionid'
attribute for a command that applies to a specific media ('m=') in an
SDP description, an optional third component can be concatenated to
the Connection reference key. It is again separated using the '~'
character and uses the 'label' attribute as specified in [RFC4574].
So the format would be:
'Local Dialog tag' + '~' + 'Remote Dialog tag' + '~' + 'Label Attribute'
As an example, for an entity that has a SIP Local dialog identifier
of '7HDY839', a Remote dialog identifier of 'HJKSkyHS' and an SDP
label attribute of 'HUwkuh7ns', the 'connectionid' attribute for a
Control Framework command would be:
7HDY839~HJKSkyHS~HUwkuh7ns
It should be noted that Control Framework requests initiated in It should be noted that Control Framework requests initiated in
conjunction with a SIP dialog will produce a different 'connectionid' conjunction with a SIP dialog will produce a different 'connectionid'
value depending on the directionality of the request, for example value depending on the directionality of the request, for example
Local and Remote tags are locally identifiable. Local and Remote tags are locally identifiable.
As with the Connection attribute previously defined, it is also As with the Connection attribute previously defined, it is also
useful to have the ability to apply specific control framework useful to have the ability to apply specific control framework
commands to a number of related dialogs, such as a multiparty call. commands to a number of related dialogs, such as a multiparty call.
This typically consists of a number of media dialogs that are This typically consists of a number of media dialogs that are
logically bound by a single identifier. The following schema allows logically bound by a single identifier. The following schema allows
skipping to change at page 46, line 16 skipping to change at page 46, line 27
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002. RFC 3268, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[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 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
 End of changes. 43 change blocks. 
105 lines changed or deleted 129 lines changed or added

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