draft-ietf-mediactrl-sip-control-framework-00.txt   draft-ietf-mediactrl-sip-control-framework-01.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation Internet-Draft Avaya
Expires: February 2, 2008 T. Melanchuk Expires: August 25, 2008 T. Melanchuk
TJM Consulting Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
A. Shiratzky February 22, 2008
Radvision
August 2007
A Control Framework for the Session Initiation Protocol (SIP) Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-00 draft-ietf-mediactrl-sip-control-framework-01
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 39 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 2, 2008. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes a Framework and protocol for application This document describes a Framework and protocol for application
deployment where the application logic and processing are deployment where the application logic and processing are
distributed. The framework uses the Session Initiation Protocol distributed. The framework uses the Session Initiation Protocol
(SIP) to establish an application-level control mechanism between (SIP) to establish an application-level control mechanism between
application servers and associated external servers such as media application servers and associated external servers such as media
servers. servers.
The motivation for the creation of this Framework is to provide an The motivation for the creation of this Framework is to provide an
interface suitable to meet the requirements of a distributed, interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the XCON work group of centralized conference system, as defined by the IETF. It is not,
the IETF. It is not, however, limited to this scope and it is however, limited to this scope and it is envisioned that this generic
envisioned that this generic Framework will be used for a wide Framework will be used for a wide variety of de-coupled control
variety of de-coupled control architectures between network entities. architectures between network entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Locating External Server Resources . . . . . . . . . . . . . . 9 4. Control Client SIP UAC Behavior - Control Channel Setup . . . 9
5. Control Client SIP UAC Behavior - Control Channel Setup . . . 9 4.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12
5.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12 5. Control Server SIP UAS Behavior - Control Channel Setup . . . 13
6. Control Server SIP UAS Behavior - Control Channel Setup . . . 12 6. Control Framework Interactions . . . . . . . . . . . . . . . . 14
7. Control Framework Interactions . . . . . . . . . . . . . . . . 13 6.1. Constructing Requests . . . . . . . . . . . . . . . . . . 15
7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 15 6.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 16
7.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 16 6.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 16
7.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 16 6.1.3. Control Channel Keep-Alive . . . . . . . . . . . . . . 18
7.1.3. Control Channel Keep-Alive . . . . . . . . . . . . . . 18 6.1.4. Package Negotiation . . . . . . . . . . . . . . . . . 21
7.1.4. Package Negotiation . . . . . . . . . . . . . . . . . 20 6.2. Constructing Responses . . . . . . . . . . . . . . . . . . 22
7.2. Constructing Responses . . . . . . . . . . . . . . . . . . 21 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 23
8. Response Code Descriptions . . . . . . . . . . . . . . . . . . 22 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.5. 420 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 23
8.6. 421 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 24
8.7. 422 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 24
8.8. 481 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 24
8.9. 500 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 24
9. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 23 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 24
9.1. Control Package Name . . . . . . . . . . . . . . . . . . . 24 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Framework Message Usage . . . . . . . . . . . . . . . . . 24 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 24
9.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 24 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 25
9.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 25 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 25
9.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 25 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 25
9.5.1. Events . . . . . . . . . . . . . . . . . . . . . . . . 25 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 25
9.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Network Address Translation (NAT) . . . . . . . . . . . . . . 25 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Control Framework Formal Syntax . . . . . . . . . . . . . 26 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 26
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 34
14.1. Control Package Registration Information . . . . . . . . . 33 11.2. Transport Level Protection . . . . . . . . . . . . . . . . 34
14.1.1. Control Package Registration Template . . . . . . . . 33 11.3. Control Channel Policy Management . . . . . . . . . . . . 35
14.2. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14.2.1. TCP/ESCS . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Control Packages Registration Information . . . . . . . . 36
14.2.2. TCP/TLS/ESCS . . . . . . . . . . . . . . . . . . . . . 33 12.1.1. Control Package Registration Template . . . . . . . . 37
14.3. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 33 12.2. Control Framework Method Names . . . . . . . . . . . . . . 37
14.4. SIP Response Codes . . . . . . . . . . . . . . . . . . . . 33 12.3. Control Framework Status Codes . . . . . . . . . . . . . . 37
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12.4. Control Framework Header Fields . . . . . . . . . . . . . 38
16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 38
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 34 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
17.1. Normative References . . . . . . . . . . . . . . . . . . . 35 13.1. Changes from 00 Version . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 38 16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 40
17. Normative References . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
Applications are often developed using an architecture where the Real-time media applications are often developed using an
application logic and processing activities are distributed. architecture where the application logic and processing activities
Commonly, the application logic runs on "application servers" whilst are distributed. Commonly, the application logic runs on
the processing runs on external servers, such as "media servers". "application servers" whilst the processing runs on external servers,
This document focuses on the framework and protocol between the such as "media servers". This document focuses on the framework and
application server and external processing server. The motivation protocol between the application server and external processing
for this framework comes from a set of requirements for Media Server server. The motivation for this framework comes from a set of
Control, which can be found in the 'Media Server Control Protocol requirements for Media Server Control, which can be found in the
Requirements' document[8]. While the Framework is not media server 'Media Server Control Protocol Requirements' document[8]. While the
control specific, it is the primary driver and use case for this Framework is not media server control specific, it is the primary
work. It is intended that the framework contained in this document driver and use case for this work. It is intended that the framework
will be used for a plethora of appropriate device control scenarios. contained in this document will be used for a plethora of appropriate
device control scenarios.
This document does not define a SIP based extension that can be used This document does not define a SIP based extension that can be used
directly for the control of external components. The framework directly for the control of external components. The framework
mechanism must be extended by other documents that are known as mechanism must be extended by other documents that are known as
"Control Packages". A comprehensive set of guidelines for creating "Control Packages". A comprehensive set of guidelines for creating
"Control Packages" is described in Section 9. "Control Packages" is described in Section 8.
Current IETF transport device control protocols, such as megaco [7], Current IETF device control protocols, such as megaco [7], while
while excellent for controlling media gateways that bridge separate excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in networks, are troublesome for supporting media-rich applications in
SIP networks, because they duplicate many of the functions inherent SIP networks, because they duplicate many of the functions inherent
in SIP. Rather than relying on single protocol session in SIP. Rather than relying on single protocol session
establishment, application developers need to translate between two establishment, application developers need to translate between two
separate mechanisms. separate mechanisms.
Application servers traditionally use SIP third party call control Application servers traditionally use SIP third party call control
RFC 3725 [12] to establish media sessions from SIP user agents to a RFC 3725 [12] to establish media sessions from SIP user agents to a
media server. SIP, as defined in RFC 3261 [2], also provides the media server. SIP, as defined in RFC 3261 [2], also provides the
ideal rendezvous mechanism for establishing and maintaining control ideal rendezvous mechanism for establishing and maintaining control
skipping to change at page 5, line 28 skipping to change at page 5, line 28
that terminates on a media server acting in the role of a Control that terminates on a media server acting in the role of a Control
Server. In this document, we often refer to the Control Client Server. In this document, we often refer to the Control Client
simply as "the Client". simply as "the Client".
Control Channel: A Control Channel is a reliable connection between Control Channel: A Control Channel is a reliable connection between
a Client and Server that is used to exchange Framework messages. a Client and Server that is used to exchange Framework messages.
The term "Connection" is used synonymously within this document. The term "Connection" is used synonymously within this document.
Framework Message: A Framework Message is a message on a Control Framework Message: A Framework Message is a message on a Control
Channel that has a type corresponding to one of the Methods Channel that has a type corresponding to one of the Methods
defined in this document. A Framework message is often referred defined in this document. A Framework message is often referred
to by its method, such as a "CONTROL message". to by its method, such as a "CONTROL message".
Method: A Method is the type of a framework message. Three Methods Method: A Method is the type of a framework message. Four Methods
are defined in this document: SYNCH, CONTROL, REPORT, and K-ALIVE. are defined in this document: SYNCH, CONTROL, REPORT, and K-ALIVE.
Control Command: A Control Command is an application level request Control Command: A Control Command is an application level request
from a Client to a Server. Control Commands are carried in the from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in body of CONTROL messages. Control Commands are defined in
separate specifications known as "Control Packages". separate specifications known as "Control Packages".
framework transaction: A framework transaction is defined as a framework transaction: A framework transaction is defined as a
sequence composed of a control framework message originated by sequence composed of a control framework message originated by
either a Control Client or Control Server and responded to with a either a Control Client or Control Server and responded to with a
control Framework response code message. Note that the control control Framework response code message. Note that the control
framework has no "provisional" responses. A control framework framework has no "provisional" responses. A control framework
transaction MUST complete within Transaction-Timeout time. transaction MUST complete within 'Transaction-Timeout' time.
extended framework transaction: An extended framework transaction is extended transaction lifetime: An extended transaction lifetime is
used to extend the lifetime of a CONTROL method transaction when used to extend the lifetime of a CONTROL method transaction when
the Control Command it carries cannot be completed within Command- the Control Command it carries cannot be completed within
Timeout milliseconds. A Server extends the lifetime of a CONTROL Transaction-Timeout milliseconds. A Server extends the lifetime
method transaction by sending a 202 response code followed by one of a CONTROL method transaction by sending a 202 response code
or more REPORT transactions as specified in Section 7.1.2. followed by one or more REPORT transactions as specified in
Extended framework transactions allow command failures to be Section 6.1.2. Extended transaction lifetimes allow command
discovered at the transaction layer. failures to be discovered at the transaction layer.
Transaction-Timeout: the maximum allowed time between a control Transaction-Timeout: the maximum allowed time between a control
Client or Server issuing a framework message and receiving a Client or Server issuing a framework message and receiving a
corresponding response. The value for the timeout should be based corresponding response. The value for the timeout should be based
on a multiple of the network RTT plus Command-Timeout milliseconds on a multiple of the network RTT plus 'Transaction-Timeout'
to allow for message parsing and processing. milliseconds to allow for message parsing and processing.
[Editors Note:DP0 - Need to pick a time for "Transaction-Time" - Work
Group input requested.]
3. Overview 3. Overview
This document details mechanisms for establishing, using, and This document details mechanisms for establishing, using, and
terminating a reliable channel using SIP for the purpose of terminating a reliable channel using SIP for the purpose of
controlling an external server. The following text provides a non- controlling an external server. The following text provides a non-
normative overview of the mechanisms used. Detailed, normative normative overview of the mechanisms used. Detailed, normative
guidelines are provided later in the document. guidelines are provided later in the document.
Control channels are negotiated using standard SIP mechanisms that Control channels are negotiated using standard SIP mechanisms that
skipping to change at page 6, line 28 skipping to change at page 6, line 31
the SIP interactions. the SIP interactions.
The use of SIP for the specified mechanism provides many inherent The use of SIP for the specified mechanism provides many inherent
capabilities which include:- 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.
o Connection maintenance - The ability to re-negotiate a connection, o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, audit parameters, and so forth. ensure it is active, audit parameters, and so forth.
o Agnostic - Generic protocol allows for easy extension. o Application agnostic - Generic protocol allows for easy extension.
As mentioned in the previous list, one of the main benefits of using As mentioned in the previous list, one of the main benefits of using
SIP as the session control protocol is the "Service Location" SIP as the session control protocol is the "Service Location"
facilities provided. This applies at both a routing level, where RFC facilities provided. This applies at both a routing level, where RFC
3263 [4] provides the physical location of devices, and at the 3263 [4] provides the physical location of devices, and at the
Service level, using Caller Preferences[13] and Callee Service level, using Caller Preferences[13] and Callee
Capabilities[14]. The ability to select a Control Server based on Capabilities[14]. The ability to select a Control Server based on
Service level capabilities is extremely powerful when considering a Service level capabilities is extremely powerful when considering a
distributed, clustered architecture containing varying services (for distributed, clustered architecture containing varying services (for
example Voice, Video, IM). More detail on locating Control Server example Voice, Video, IM). More detail on locating Control Server
resources using these techniques is outlined in Section 5 of this resources using these techniques is outlined in Section 4 of this
document. document.
+--------------SIP Traffic--------------+ +--------------SIP Traffic--------------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
| SIP | | SIP | | SIP | | SIP |
|Stack| |Stack| |Stack| |Stack|
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Control | | Control | | Control | | Control |
skipping to change at page 7, line 49 skipping to change at page 8, line 19
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:Client@clientmachine.example.com> Contact: <sip:Client@clientmachine.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [..] Content-Length: [..]
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=- s=-
c=IN IP4 controller.example.com c=IN IP4 controller.example.com
m=application 7575 TCP/ESCS m=application 7575 TCP/SCFW
a=setup:active a=setup:active
a=connection:new a=connection:new
On receiving the INVITE request, the external Server supporting this On receiving the INVITE request, the external Server supporting this
mechanism generates a 200 OK response containing appropriate SDP. mechanism generates a 200 OK response containing appropriate SDP.
External Server Sends to Client: External Server Sends to Client:
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879 To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746 From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
skipping to change at page 8, line 23 skipping to change at page 8, line 42
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com> Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [..] Content-Length: [..]
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 server.example.com o=originator 2890844526 2890842808 IN IP4 server.example.com
s=- s=-
c=IN IP4 mserver.example.com c=IN IP4 mserver.example.com
m=application 7563 TCP/ESCS m=application 7563 TCP/SCFW
a=setup:passive a=setup:passive
a=connection:new a=connection:new
The Control Client receives the SIP 200 OK response and extracts the The Control Client receives the SIP 200 OK response and extracts the
relevant information (also sending a SIP ACK). It creates an relevant information (also sending a SIP ACK). It creates an
outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP
connection to the Control Server. The connection address (taken from connection to the Control Server. The connection address (taken from
'c=') and port (taken from 'm=')are used to identify the remote part 'c=') and port (taken from 'm=')are used to identify the remote part
in the new connection. in the new connection.
skipping to change at page 9, line 32 skipping to change at page 9, line 44
(2) from Figure 4 represents the User Agent SIP dialog interactions (2) from Figure 4 represents the User Agent SIP dialog interactions
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 User functionality). Using the interaction illustrated by (2), the User
Agent is able to negotiate media capabilities with the Control Server Agent is able to negotiate media capabilities with the Control Server
using standard SIP mechanisms as defined in RFC 3261 [2] and RFC 3264 using standard SIP mechanisms as defined in RFC 3261 [2] and RFC 3264
[5]. [5].
4. Locating External Server Resources 4. Control Client SIP UAC Behavior - Control Channel Setup
[Editors Note: Section will describe mechanisms for locating an
external Server.]
5. Control Client SIP UAC Behavior - Control Channel Setup
On creating a new SIP INVITE request for control channel setup, a UAC On creating a new SIP INVITE request for control channel setup, a UAC
MUST construct the protocol message as defined in RFC 3261 [2]. MUST construct the protocol message as defined in RFC 3261 [2].
If a reliable response is received (as defined RFC 3261 [2] and RFC If a reliable response is received (as defined RFC 3261 [2] and RFC
3262 [3]), the mechanisms defined in this document are applicable to 3262 [3]), the mechanisms defined in this document are applicable to
the newly created dialog. the newly created dialog.
Before the UAC can send an INVITE request, it MAY include a valid The UAC MAY include a valid session description (an 'offer' as
session description (an 'offer' as defined in RFC 3264 [5]) using the defined in RFC 3264 [5]) in an INVITE request using the Session
Session Description Protocol defined in [9]. The following Description Protocol defined in [9]. The following information
information defines the composition of some specific elements of the defines the composition of some specific elements of the SDP payload
SDP payload that MUST be adhered to for compliancy to this that MUST be adhered to for compliancy to this specification when
specification when used in an SIP SDP offer. used in an SIP SDP offer.
The Connection Data line in the SDP payload is constructed as The Connection Data line in the SDP payload is constructed as
specified in [9]: specified in [9]:
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The first sub-field, <nettype>, MUST equal the value "IN". The The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The
third sub-field for Connection Data is <connection-address>. This third sub-field for Connection Data is <connection-address>. This
supplies a representation of the SDP originators address, for example supplies a representation of the SDP originators address, for example
skipping to change at page 10, line 37 skipping to change at page 10, line 46
The first "sub-field" <media> MUST equal the value "application". The first "sub-field" <media> MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the The second sub-field, <port>, MUST represent a port on which the
constructing client can receive an incoming connection if required. constructing client can receive an incoming connection if required.
The port is used in combination with the address specified in the The port is used in combination with the address specified in the
'Connection Data line defined previously to supply connection 'Connection Data line defined previously to supply connection
details. If the constructing client can't receive incoming details. If the constructing client can't receive incoming
connections it MUST still enter a valid port range entry. The use of connections it MUST still enter a valid port range entry. The use of
the port value '0' has the same meaning as defined in the SDP the port value '0' has the same meaning as defined in the SDP
specification[9]. The third sub-field, <proto>, MUST equal a specification[9]. The third sub-field, <proto>, MUST equal a
transport value defined in Section 14.2. All implementations transport value defined in Section 12.6. All implementations
compliant to this specification MUST support the value "TCP/ESCS" and compliant to this specification MUST support the value "TCP/SCFW",
"TCP/TLS/ESCS" as defined in Section 14.2 of this document. "TCP/TLS/SCFW", "SCTP/SCFW" and "SCTP/TLS/SCFW" as defined in
Section 12.6 of this document. Implementations MUST support TLS as a
transport-level security mechanism, although use of TLS in specific
deployments is optional. MEDIACTRL implementations MUST support TCP
as a transport protocol. MEDIACTRL 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 The SDP MUST also contain a number of SDP media attributes(a=) that
are specifically defined in the COMEDIA [6] specification. The are specifically defined in the COMEDIA [6] 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 [6] possible values defined for media attributes from the COMEDIA [6]
specification but MAY choose not to support values if it can specification but MAY choose not to support values if it can
definitely determine they will never be used (for example will only definitely determine they will never be used (for example will only
ever initiate outgoing connections). It is RECOMMENDED that a 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 11, line 23 skipping to change at page 11, line 39
Section 3. Once the SDP has been constructed along with the Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in RFC 3261 [2]), it remainder of the SIP INVITE request (as defined in RFC 3261 [2]), it
can be sent to the appropriate location. The SIP dialog and can be sent to the appropriate location. The SIP dialog and
appropriate control connection is then established. appropriate control connection is then established.
As mentioned previously, the SIP Control Framework can be used in As mentioned previously, the SIP Control Framework can be used in
conjunction with other media dialogs (for example, use the control conjunction with other media dialogs (for example, use the control
channel to play a prompt to media dialog X). For SIP based media channel to play a prompt to media dialog X). For SIP based media
dialogs, if not present in the SDP received by the Control Client dialogs, if not present in the SDP received by the Control Client
(when acting as a B2BUA) from the User Agent, a media label SDP (when acting as a B2BUA) from the User Agent, a media label SDP
attribute, which is defined in [10], should be inserted for every attribute, which is defined in RFC 4574 [10], should be inserted for
media description (identified as m= line as defined in [9]) before every media description (identified as m= line as defined in [9])
forwarding. This provides flexibility for the Control Client as it before forwarding. This provides flexibility for the Control Client
can generate control messages using the Control Channel that specify as it can generate control messages using the Control Channel that
a particular Media stream (between User Agent and Control Server) specify a particular Media stream (between User Agent and Control
within a SIP media dialog. If a Media label is not included in the Server) within a SIP media dialog. If a Media label is not included
control message, commands apply to all media associated with the in the control message, commands apply to all media associated with
dialog. the dialog.
A non-2xx class error (4xx, 5xx and 6xx) SIP response received for A non-2xx class error (4xx, 5xx and 6xx) SIP response received for
the INVITE request indicates that no SIP dialog has been created and the INVITE request indicates that no SIP dialog has been created and
is treated as specified RFC 3261 [2]. Specifically, support of this is treated as specified RFC 3261 [2]. Specifically, support of this
specification is negotiated through the presence of the media type specification is negotiated through the presence of the media type
defined in this specification. The receipt of a SIP error response defined in this specification. The receipt of a SIP error response
like "488" indicates that the offer contained in a request is not like "488" indicates that the offer contained in a request is not
acceptable. The inclusion of the media line associated with this acceptable. The inclusion of the media line associated with this
specification in such a rejected offer should indicate to the client specification in such a rejected offer should indicate to the client
generating the offer that this could be due to the receiving client generating the offer that this could be due to the receiving client
not supporting this specification. The client generating the offer not supporting this specification. The client generating the offer
should act as it would normally on receiving this response, as per should act as it would normally on receiving this response, as per
RFC 3261 [2]. Media streams can also be rejected by setting the port RFC 3261 [2]. Media streams can also be rejected by setting the port
to "0" in the "m=" line of the session description. A client using to "0" in the "m=" line of the session description. A client using
this specification should be prepared to receive an answer where the this specification should be prepared to receive an answer where the
"m=" line it inserted for using the Control Framework has been set to "m=" line it inserted for using the Control Framework has been set to
"0". "0".
5.1. Control Client SIP UAC Behavior - Media Dialogs 4.1. Control Client SIP UAC Behavior - Media Dialogs
It is intended that the Control framework will be used within a It is intended that the Control framework will be used within a
variety of architectures for a wide range of functions. One of the variety of architectures for a wide range of functions. One of the
primary functions will be the use of the control channel to apply primary functions will be the use of the control channel to apply
specific Control package commands to co-existing SIP dialogs that specific Control package commands to co-existing SIP dialogs that
have been established with the same remote server, for example the have been established with the same remote server, for example the
manipulation of audio dialogs connected to a media server. manipulation of audio dialogs connected to a media server.
Such co-existing dialogs will pass through the Control Client (see Such co-existing dialogs will pass through the Control Client (see
Figure 4) entity and may contain more than one Media Description (as Figure 4) entity and may contain more than one Media Description (as
skipping to change at page 12, line 35 skipping to change at page 12, line 49
this will reduce repetitive specifying of dialog reference language. this will reduce repetitive specifying of dialog reference language.
The schema can be found in Section 16.1 in Appendix A. The schema can be found in Section 16.1 in Appendix A.
Similarly, the ability to identify and apply commands to a group of Similarly, the ability to identify and apply commands to a group of
associated media dialogs (multiparty) is also identified as a common associated media dialogs (multiparty) is also identified as a common
structure that could be defined and re-used (for example playing a structure that could be defined and re-used (for example playing a
prompt to all participants in a Conference). The schema for such prompt to all participants in a Conference). The schema for such
operations can also be found in Section 16.1 in Appendix A. operations can also be found in Section 16.1 in Appendix A.
Support for both the common attributes described here is specified as Support for both the common attributes described here is specified as
part of each Control Package definition, as detailed in Section 9. part of each Control Package definition, as detailed in Section 8.
6. Control Server SIP UAS Behavior - Control Channel Setup 5. Control Server SIP UAS Behavior - Control Channel Setup
On receiving a SIP INVITE request, an external Server(UAS) inspects On receiving a SIP INVITE request, an external Server(UAS) inspects
the message for indications of support for the mechanisms defined in the message for indications of support for the mechanisms defined in
this specification. This is achieved through inspection of the this specification. This is achieved through inspection of the
Sessions Description of the SIP INVITE message and identifying Sessions Description of the SIP INVITE message and identifying
support for the appropriate media type. If the external Server support for the appropriate media type. If the external Server
wishes to construct a reliable response that conveys support for the wishes to construct a reliable response that conveys support for the
extension, it should follow the mechanisms defined in RFC 3261 [2]. extension, it should follow the mechanisms defined in RFC 3261 [2].
If support is conveyed in a reliable SIP provisional response, the If support is conveyed in a reliable SIP provisional response, the
mechanisms in RFC 3262 [3] MUST also be used. It should be noted mechanisms in RFC 3262 [3] MUST also be used. It should be noted
that the SDP offer is not restricted to the initial INVITE request that the SDP offer is not restricted to the initial INVITE request
and maybe appear in any series of messages that are compliant to RFC and may appear in any series of messages that are compliant to RFC
3261 [2], RFC 3262 [3], and RFC 3264 [5] 3261 [2], RFC 3262 [3], and RFC 3264 [5]
When constructing an answer, the SDP payload MUST be constructed When constructing an answer, the SDP payload MUST be constructed
using the semantics(Connection, Media and attribute) defined in using the semantics(Connection, Media and attribute) defined in
Section 5 using valid local settings and also with full compliance to Section 4 using valid local settings and also with full compliance to
the COMEDIA[6] specification. For example, the SDP attributes the COMEDIA[6] specification. For example, the SDP attributes
included in the answer constructed for the example offer provided in included in the answer constructed for the example offer provided in
Section 5 would look as illustrated below: Section 4 would look as illustrated below:
a=setup:passive a=setup:passive
a=connection:new a=connection:new
Once the SIP success response has been constructed, it is sent using Once the SIP success response has been constructed, it is sent using
standard SIP mechanisms. Depending on the contents of the SDP standard SIP mechanisms. Depending on the contents of the SDP
payloads that were negotiated using the Offer/Answer exchange, a payloads that were negotiated using the Offer/Answer exchange, a
reliable connection will be established between the Controlling UAC reliable connection will be established between the Controlling UAC
and external Server UAS entities. The newly established connection and external Server UAS entities. The newly established connection
is now available to exchange control command primitives. The state is now available to exchange control command primitives. The state
of the SIP Dialog and the associated Control channel are now of the SIP Dialog and the associated Control channel are now
implicitly linked. If either party wishes to terminate a Control implicitly linked. If either party wishes to terminate a Control
channel is simply issues a SIP termination request (SIP BYE request). channel it simply issues a SIP termination request (SIP BYE request).
The Control Channel therefore lives for the duration of the SIP The Control Channel therefore lives for the duration of the SIP
dialog. dialog.
If the UAS does not support the extension defined in this document, If the UAS does not support the extension defined in this document,
as identified by the media contained in the Session Description, it as identified by the media contained in the Session Description, it
SHOULD respond as detailed in RFC 3261 [2] with a "SIP 488" response SHOULD respond as detailed in RFC 3261 [2] with a "SIP 488" response
code. If multiple media descriptions exist it MAY choose to continue code. If multiple media descriptions exist it MAY choose to continue
processing the request and mark the port field equal to "0". processing the request and mark the port field equal to "0".
A SIP entity receiving a SIP OPTIONS request MUST respond A SIP entity receiving a SIP OPTIONS request MUST respond
appropriately as defined in RFC 3261 [2]. This involves providing appropriately as defined in RFC 3261 [2]. This involves providing
information relating to supported SIP extensions and media types in a information relating to supported SIP extensions and media types in a
200 OK response. For this extension the media types supported MUST 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 be included in the SIP 200 OK response in a SIP "Accept" header to
indicate a valid media type. indicate a valid media type.
7. Control Framework Interactions 6. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of the Control Channel to be set up in either direction as a result of the
SIP INVITE transaction. While providing a flexible negotiation SIP INVITE transaction. While providing a flexible negotiation
mechanism, it does provide certain correlation problems between the mechanism, it does provide certain correlation problems between the
channel and the overlying SIP dialog. Remember that the two are channel and the overlying SIP dialog. Remember that the two are
implicitly linked and so need a robust correlation mechanism. A implicitly linked and so need a robust correlation mechanism. A
Control Client receiving an incoming connection (whether it be acting Control Client receiving an incoming connection (whether it be acting
in the role of UAC or UAS) has no way of identifying the associated 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 SIP dialog as it could be simply listening for all incoming
connections on a specific port. As a consequence, some rules are connections on a specific port. As a consequence, some rules are
applied to allow a connecting (defined as 'active' role in COMEDIA) applied to allow a connecting (defined as 'active' role in COMEDIA)
client to identify the associated SIP dialog that triggered the active UA to identify the associated SIP dialog that triggered the
connection. The following steps provide an identification mechanism connection. The following steps provide an identification mechanism
that MUST be carried out before any other signaling is carried out on that MUST be carried out before any other signaling is carried out on
the newly created Control channel. the newly created Control channel.
o Once the connection has been established, the client initiating o Once the connection has been established, the active UA initiating
the connection (as determined by COMEDIA) MUST immediately send a the connection (as determined by COMEDIA) MUST immediately send a
Control Framework SYNCH request. The SYNCH request will be Control Framework SYNCH request. The SYNCH request will be
constructed as defined in Section 11.1 and MUST contain the constructed as defined in Section 9.1 and MUST contain the message
message header, 'Dialog-ID', which contains the SIP dialog header, 'Dialog-ID', which contains the SIP dialog information.
information.
o The 'Dialog-ID' message header is constructed by concatenating the o The 'Dialog-ID' message header is constructed by concatenating the
Local-tag, Call-ID and Remote-tag (as defined in Section 11.1) Local-tag, Call-ID and Remote-tag (as defined in Section 9.1) from
from the SIP dialog and separating with a '~'. See syntax defined the SIP dialog and separating with a '~'. See syntax defined in
in Section 16.1 in Appendix A and examples in Section 9.6. For Section 16.1 in Appendix A and examples in Section 8.7. For
example, if the SIP dialog had values of 'Local-tag=HKJDH', example, if the SIP dialog had values of 'Local-tag=HKJDH',
'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the 'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the
'Dialog-ID' header would look like this: 'Dialog-ID' header would look like this:
'Dialog-ID=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'. 'Dialog-ID=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'.
o On creating the SYNCH request the controlling client MUST follow o On creating the SYNCH request the controlling active UA MUST
the procedures outlined in Section 7.1.3 . This provides details follow the procedures outlined in Section 6.1.3 . This provides
of connection keep-alive messages. details of connection keep-alive messages.
o On creating the SYNCH request the controlling client MUST also o On creating the SYNCH request the controlling active UA MUST also
follow the procedures outlined in Section 7.1.4. This provides follow the procedures outlined in Section 6.1.4. This provides
details of the negotiation mechanism used to determine the details of the negotiation mechanism used to determine the
Protocol Data Units (PDUs) that can be exchanged on the Protocol Data Units (PDUs) that can be exchanged on the
established control channel connection. established control channel connection.
o The client who initiated the connection MUST then send the SYNCH o The active UA who initiated the connection MUST then send the
request. It should then wait for a period of 5 seconds to receive SYNCH request. It MUST then wait for a period of at least 5
a response. It MAY choose a longer time to wait but it should not seconds to receive a response. It MAY choose a longer time to
be shorter than 5 seconds. wait but it should not be shorter than 5 seconds.
o If no response is received for the SYNCH control message, a o If no response is received for the SYNCH control message, a
timeout occurs and the control channel is terminated along with timeout occurs and the control channel is terminated along with
the associated SIP dialog (issue a BYE request). the associated SIP dialog (issue a BYE request).
o If the client who initiated a connection receives a 481 response, o If the active UA who initiated a connection receives a 481
this implies that the SYNCH request was received but no associated response, this implies that the SYNCH request was received but no
SIP dialog exists. This also results in the control channel being associated SIP dialog exists. This also results in the control
terminated along with the associated SIP dialog (issue a BYE channel being terminated along with the associated SIP dialog
request). (issue a BYE request).
o All other error responses received for the SYNCH request are o All other error responses received for the SYNCH request are
treated as detailed in this specification and also result in the treated as detailed in this specification and also result in the
termination of the control channel and the associated SIP dialog termination of the control channel and the associated SIP dialog
(issue a BYE request). (issue a BYE request).
o The receipt of a 200 response to a SYNCH message implies that the o The receipt of a 200 response to a SYNCH message implies that the
SIP dialog and control connection have been successfully SIP dialog and control connection have been successfully
correlated. The control channel can now be used for further correlated. The control channel can now be used for further
interactions. interactions.
It should be noted that SYNCH messages can be sent at any point while It should be noted that SYNCH messages can be sent at any point while
the Control Channel is open from either side, once the initial the Control Channel is open from either side, once the initial
exchange is complete. It should also be noted that if present, the exchange is complete. It should also be noted that if present, the
contents of the "Keep-Alive" and "Dialog-ID" headers should not contents of the "Keep-Alive" and "Dialog-ID" headers should not
change and new values have no relevance as they are both negotiated change and new values have no relevance as they are both negotiated
for the lifetime of the session. for the lifetime of the session.
Once a successful control channel has been established, as defined in Once a successful control channel has been established, as defined in
Section 5 and Section 6 (and the connection has been correlated, as Section 4 and Section 5 (and the connection has been correlated, as
described in previous paragraph), the two entities are now in a described in previous paragraph), the two entities are now in a
position to exchange relevant control framework messages. The position to exchange relevant control framework messages. The
remainder of this section provides details of the core set of methods remainder of this section provides details of the core set of methods
and responses that MUST be supported for the core control framework. and responses that MUST be supported for the core control framework.
Future extensions to this document MAY define new methods and Future extensions to this document MAY define new methods and
responses. responses.
7.1. Constructing Requests 6.1. Constructing Requests
An entity acting as a Control Client is now able to construct and An entity acting as a Control Client is now able to construct and
send new requests on a control channel and MUST adhere to the syntax send new requests on a control channel and MUST adhere to the syntax
defined in Section 11 (Note: either client can act as a control defined in Section 9 (Note: either client can act as a control client
client depending on individual package requirements). Control depending on individual package requirements). Control Commands MUST
Commands MUST also adhere to the syntax defined by the Control also adhere to the syntax defined by the Control Packages negotiated
Packages negotiated in Section 5 and Section 6 of this document. A in Section 4 and Section 5 of this document. A Control Client MUST
Control Client MUST create a unique transaction and associated create a unique control message transaction and associated identifier
identifier per request transaction. The transaction identifier is for insertion in the request. The transaction identifier is then
then included in the first line of a control framework message along included in the first line of a control framework message along with
with the method type (as defined in the ABNF in Section 11). The the method type (as defined in the ABNF in Section 9). The first
first line starts with the "SCFW" token for the purpose of easily line starts with the "SCFW" token for the purpose of easily
extracting the transaction identifier. The transaction identifier extracting the transaction identifier. The transaction identifier
MUST be globally unique over space and time. All required mandatory MUST be globally unique over space and time. All required mandatory
and optional control framework headers are then inserted into the and optional control framework headers are then inserted into the
control message with appropriate values (see relevant individual control message with appropriate values (see relevant individual
header information for explicit detail). A "Control-Package" header header information for explicit detail). A "Control-Package" header
MUST also be inserted with the value indicating the Control Package MUST also be inserted with the value indicating the Control Package
to which this specific request applies (Multiple packages can be to which this specific request applies (Multiple packages can be
negotiated per control channel using the SYNCH control message that negotiated per control channel using the SYNCH control message that
is discussed in this section along with the mechanism from is discussed in this section along with the mechanism from
Section 7.1.4). Section 6.1.4).
Any framework message that contains an associated payload MUST also Any framework message that contains an associated payload MUST also
include a 'Content-Length' message header which represents the size include a 'Content-Length' and 'Content-Type' message header which
of the message body in decimal number of octets. If no associated represents the size of the message body in decimal number of octets.
payload is to be added to the message, a 'Content-Length' header with If no associated payload is to be added to the message, a 'Content-
a value of '0' MUST be included. 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, When all of the headers have been included in the framework message,
it is sent down the control channel established in Section 5. it is sent down the control channel established in Section 4.
It is a requirement that a Server receiving such a request respond It is a requirement that a Server receiving such a request respond
quickly with an appropriate response (as defined in Section 7.2). A quickly with an appropriate response (as defined in Section 6.2). A
Control Client entity needs to wait for "Transaction-Time" time for a Control Client entity needs to wait for "Transaction-Time" time for a
response before considering the transaction a failure. response before considering the transaction a failure.
[Editors Note: Need to pick a time for "Transaction-Time" - Work [Editors Note:DP1 - Need to pick a time for "Transaction-Time" - Work
Group input requested.] Group input requested.]
7.1.1. Sending CONTROL 6.1.1. Sending CONTROL
A 'CONTROL' message is used by Control Client to invoke control A 'CONTROL' message is used by Control Client to invoke control
commands on a Control Server. The message is constructed in the same commands on a Control Server. The message is constructed in the same
way as any standard Control Framework message, as discussed way as any standard Control Framework message, as discussed
previously in Section 7.1 and defined in Section 11. A CONTROL previously in Section 6.1 and defined in Section 9. A CONTROL
message MAY contain a message body. The explicit control command(s) message MAY contain a message body. The explicit control command(s)
of the message payload contained in a CONTROL message are specified of the message payload contained in a CONTROL message are specified
in separate Control Package specifications. These specifications in separate Control Package specifications. These specifications
MUST conform to the format defined in Section 9.4. 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.
7.1.2. Sending REPORT 6.1.2. Sending REPORT
A 'REPORT' message is used by a Control Server in two situations. A 'REPORT' message is used by a Control Server when processing of a
The first situation occurs when processing of a Control Command CONTROL Command extends beyond a 'Transaction-Timeout'. In this case
extends beyond a Command-Timeout. In this case a 202 response is a 202 response is returned. Status updates and the final results of
returned. Status updates and the final results of the command are the command are then returned in subsequent REPORT messages. The
then returned in subsequent REPORT messages. The second situation extended reporting mechanism defined in Section 6.1.2.1 can be used
allows REPORT to be used as an event notification mechanism where for a wide variety of functions including long lived event reporting
events are correlated with the original CONTROL message. In this associated with a transaction.
case, REPORT messages may be sent after the original transaction or
extended transaction has completed. [Editors Note:DP2 - Need to pick a time for "Transaction-Time" - Work
Group input requested.]
All REPORT messages MUST contain the same transaction ID in the All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL request start line that was present in the original CONTROL
transaction. This allows both extended transactions and event transaction. This allows both extended transactions and event
notifications to be correlated with the original CONTROL transaction. notifications 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 type defined by the
control package and its length.
7.1.2.1. Reporting the Status of Extended Transactions 6.1.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within On receiving a CONTROL message, a Control Server MUST respond within
Command-Timeout with a status code for the request, as specified in 'Transaction-Timeout' with a status code for the request, as
Section 7.2. If the command completed within that time, a 200 specified in Section 6.2. If the command completed within that time,
response code would have been sent. If the command did not complete a 200 response code would have been sent. If the command did not
within that time, the response code 202 would have been sent complete within that time, the response code 202 would have been sent
indicating that the requested command is still being processed and indicating that the requested command is still being processed and
the CONTROL transaction is being extended. The REPORT method is used the CONTROL transaction is being extended. The REPORT method is then
to update the status of the extended transaction. used to update and terminate the status of the extended transaction.
A Control Server issuing a 202 response MUST immediately issue a [Editors Note:DP3 - Need to pick a time for "Transaction-Time" - Work
REPORT message. The initial REPORT message MUST contain a 'Seq' Group input requested.]
(Sequence) message header with a value equal to '1' (It should be
noted that the 'Seq' numbers at both Control Client Control Server A Control Server issuing a 202 response MUST contain a 'Timeout'
for framework messages are independent). The initial REPORT message message header. This header will contain a value in delta seconds
MUST also contain a 'Status' message header with a value of that represents the amount of time the recipient of the 202 message
'pending'. This initial REPORT message MUST NOT contain a message must wait before assuming that there has been a problem and
body and is primarily used to establish a subsequent message terminating the extended transaction and associated state (no
transaction based on the initial CONTROL message. 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 All REPORT messages for an extended CONTROL transaction MUST contain
a 'Timeout' message header. This header will contain a value in a 'Timeout' message header. This header will contain a value in
delta seconds that represents the amount of time the recipient of the delta seconds that represents the amount of time the recipient of the
REPORT message must wait before assuming that there has been a REPORT message must wait before assuming that there has been a
problem and terminating the extended transaction and associated problem and terminating the extended transaction and associated
state. On receiving a REPORT message with a 'Status' header of state. On receiving a REPORT message with a 'Status' header of
'pending' or 'update', the Control Client MUST reset the counter for 'pending' or 'update', the Control Client MUST reset the timer for
the associated extended CONTROL transaction to the indicated timeout the associated extended CONTROL transaction to the indicated timeout
period. If the timeout period approaches with no intended REPORT period. If the timeout period approaches with no intended REPORT
messages being generated, the entity acting as a Control Framework messages being generated, the entity acting as a Control Framework
UAS for the interaction MUST generate a REPORT message containing, as UAS for the interaction MUST generate a REPORT message containing, as
defined in this paragraph, a 'Status' header of 'pending'. Such a defined in this paragraph, a 'Status' header of 'pending'. Such a
message acts as a timeout refresh and in no way impacts the extended message acts as a timeout refresh and in no way impacts the extended
transaction, because no message body or semantics are permitted. It transaction, because no message body or semantics are permitted. It
is RECOMMENDED that a minimum value of 10 and a maximum of "Upper- is RECOMMENDED that a minimum value of 10 and a maximum of "Upper-
limit" is used for the value of the 'Timeout' message header. It is limit" is used for the value of the 'Timeout' message header. It is
also RECOMMENDED that a Control Server refresh the timeout period of also RECOMMENDED that a Control Server refresh the timeout period of
the CONTROL transaction at an interval that is not too close to the 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 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 example a timeout period of 10 seconds would be refreshed after 8
seconds. seconds.
[Editors Note: Need to pick a time for "Upper-Limit" - Work Group [Editors Note:DP4 - Need to pick a time for "Upper-Limit" - Work
input requested.] Group input requested.]
Subsequent REPORT messages that provide additional information Subsequent REPORT messages that provide additional information
relating to the extended CONTROL transaction MUST also include and relating to the extended CONTROL transaction MUST also include and
increment by 1 the 'Seq' header value. They MUST also include a increment by 1 the 'Seq' header value. They MUST also include a
'Status' header with a value of 'update'. These REPORT messages sent 'Status' header with a value of 'update'. These REPORT messages sent
to update the extended CONTROL transaction status MAY contain a to update the extended CONTROL transaction status MAY contain a
message body, as defined by individual Control Packages and specified message body, as defined by individual Control Packages and specified
in Section 9.5. A REPORT message sent updating the extended in Section 9.5. A REPORT message sent updating the extended
transaction also acts as a timeout refresh, as described earlier in transaction also acts as a timeout refresh, as described earlier in
this section. This will result in a transaction timeout period at this section. This will result in a transaction timeout period at
the initiator of the request being reset to the interval contained in the initiator of the original CONTROL request being reset to the
the 'Timeout' message header. interval contained in the 'Timeout' message header.
When all processing for an extended CONTROL transaction has taken When all processing for an extended CONTROL transaction has taken
place, the entity acting as a Control Server MUST send a terminating place, the entity acting as a Control Server MUST send a terminating
REPORT message. The terminating REPORT message MUST increment the REPORT message. The terminating REPORT message MUST increment the
value in the 'Seq' message header by the value of '1' from the value in the 'Seq' message header by the value of '1' from the
previous REPORT message. It MUST also include a 'Status' header with previous REPORT message. It MUST also include a 'Status' header with
a value of 'terminate' and MAY contain a message body. A Control a value of 'terminate' and MAY contain a message body. A Control
Framework UAC can then clean up any pending state associated with the Framework UAC can then clean up any pending state associated with the
original control transaction. original control transaction.
7.1.2.2. Reporting Asynchronous Events 6.1.3. Control Channel Keep-Alive
Commands that are carried in CONTROL messages can request that the
Server notify the Client about events that occur sometime in the
future. It is not desirable to use extended Control transactions for
these types of commands for two reasons. First, an event never
occurring is often correct behavior. Second, events may occur long
after the original request for their notification.
REPORT messages can be used to notify events. REPORT messages that
notify events MUST contain a 'Status' header of 'Notify'. They MUST
NOT contain either a 'Timeout' or 'Seq' header and any such headers
MUST be ignored when the REPORT message has a 'Status' of 'notify'.
The REPORT message MAY contain a message body.
7.1.3. Control Channel Keep-Alive
It is reasonable to expect this document to be used in various It is reasonable to expect this document to be used in various
network architectures. This will include a wide range of deployments network architectures. This will include a wide range of deployments
where the clients could be co-located in a secured, private domain or where the clients could be co-located in a secured, private domain or
spread across disparate domains that require traversal of devices spread across disparate domains that require traversal of devices
such as Network Address Translators (NAT) and Firewalls (which is such as Network Address Translators (NAT) and Firewalls. It is
covered in Section 10). It is important, therefore, that this important, therefore, that this document provides a 'keep-alive'
document provides a 'keep-alive' mechanism that enables the control mechanism that enables the control channel being created to firstly
channel being created to firstly be kept active during times of be kept active during times of inactivity (most Firewalls have a
inactivity (most Firewalls have a timeout period after which timeout period after which connections are closed) and also provide
connections are closed) and also provide the ability for application the ability for application level failure detection. It should be
level failure detection. It should be noted at this point that the noted at this point that the following procedures apply explicitly to
following procedures apply explicitly to the control channel being the control channel being created and for details relating to a SIP
created and for details relating to a SIP keep-alive mechanism keep-alive mechanism implementers should seek guidance from SIP
implementers should seek guidance from SIP Outbound [11]. The Outbound [11]. The following 'keep-alive' procedures SHOULD be
following 'keep-alive' procedures SHOULD be implemented by all implemented by all entities unless it can be guaranteed that
entities but MAY NOT be implemented if it can be guaranteed that
deployments will only occur with entities in a co-located domain. It deployments will only occur with entities in a co-located domain. It
should be noted that choosing to not implement the 'keep-alive' should be noted that choosing to not implement the 'keep-alive'
mechanism in this section, even when in a co-located architecture, mechanism in this section, even when in a co-located architecture,
will reduce the ability to detect application level errors - will reduce the ability to detect application level errors -
especially during long periods of in-activity. especially during long periods of in-activity.
7.1.3.1. Timeout Negotiation 6.1.3.1. Timeout Negotiation
During the creation of the initial SYNCH primitive, the clients will During the creation of the initial SYNCH primitive, the clients will
also negotiate a timeout period for the control channel 'keep-alive' also negotiate a timeout period for the control channel 'keep-alive'
mechanism. The following rules SHOULD be obeyed: mechanism. The following rules SHOULD be obeyed:
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 'k-alive' header MUST be included attribute equal to 'active', the 'k-alive' header MUST be included
in the SYNCH message generated by the offerer. The value of the in the SYNCH message generated by the offerer. The value of the
'K-Alive' header SHOULD be in the range of 95 and 120 seconds 'K-Alive' header SHOULD be in the range of 95 and 120 seconds
(this is consistent with SIP Outbound[11]). The client that (this is consistent with SIP Outbound[11]). The client that
generated the SDP "Answer" ('passive' client) MUST copy the generated the SDP "Answer" ('passive' client) MUST copy the
skipping to change at page 19, line 45 skipping to change at page 20, line 8
and include the 'Keep-Alive' header. The value SHOULD be in the and include the 'Keep-Alive' header. The value SHOULD be in the
range 95 to 120 seconds. range 95 to 120 seconds.
o Once negotiated, the keep-alive applies for the remainder of the o Once negotiated, the keep-alive applies for the remainder of the
Control Framework session. Any subsequent SYNCH messages Control Framework session. Any subsequent SYNCH messages
generated in the control channel do not impact the negotiated generated in the control channel do not impact the negotiated
keep-alive property of the session. The "Keep-Alive" header MUST keep-alive property of the session. The "Keep-Alive" header MUST
NOT be included in subsequent SYNCH messages as it has no meaning. NOT be included in subsequent SYNCH messages as it has no meaning.
If it is present it MUST be ignored. If it is present it MUST be ignored.
o The 'K-alive' header MUST NOT be included when the COMEDIA 'setup' o The 'K-alive' header MUST NOT be included when the COMEDIA 'setup'
attribute is equal to 'holdconn'. attribute is equal to 'holdconn'.
o [Editors Note: holdconn needs more thought.] o [Editors Note:DP5 - holdconn needs more thought.]
o Following the previous steps ensures that the entity initiating o Following the previous steps ensures that the entity initiating
the control channel connection is always the one specifying the the control channel connection is always the one specifying the
keep-alive timeout period. It will always be the initiator of the keep-alive timeout period. It will always be the initiator of the
connection who generates the 'K-ALIVE' Control Framework level connection who generates the 'K-ALIVE' Control Framework level
messages. The following section describes in more detail how to messages. The following section describes in more detail how to
generate the Control Framework 'K-ALIVE' message. generate the Control Framework 'K-ALIVE' message.
7.1.3.2. Generating Keep-Alive Messages 6.1.3.2. Generating Keep-Alive Messages
Once the SIP dialog has been established using the SDP 'Offer/Answer' Once the SIP dialog has been established using the SDP 'Offer/Answer'
mechanism and the underlying control channel has been established mechanism and the underlying control channel has been established
(including the initial identity handshake using SYNCH as discussed in (including the initial identity handshake using SYNCH as discussed in
Section 7), both the 'active' and 'passive' (as defined in Section 6), both the 'active' and 'passive' (as defined in
COMEDIA[6]) clients MUST start a keep-alive timer equal to the value COMEDIA[6]) clients MUST start a keep-alive timer equal to the value
negotiated during the control channel SYNCH request/response exchange negotiated during the control channel SYNCH request/response exchange
(the value from the 'k-alive' header in delta seconds). (the value from the 'k-alive' header in delta seconds).
When acting as an 'active' client, a 'K-ALIVE' Control Framework When acting as an 'active' entity, a 'K-ALIVE' Control Framework
message MUST be generated before the local 'keep-alive' timer fires. message MUST be generated before the local 'keep-alive' timer fires.
An active client is free to send the K-ALIVE Control Framework An active entity is free to send the K-ALIVE Control Framework
message when ever it chooses. A guideline of 80% of the local 'keep- message when ever it chooses. A guideline of 80% of the local 'keep-
alive' timer is suggested. The 'passive' client MUST generate a 200 alive' timer is suggested. The 'passive' entity MUST generate a 200
OK Control Framework response to the K-ALIVE message and reset the OK Control Framework response to the K-ALIVE message and reset the
local 'keep-alive' timer. No other Control Framework response is local 'keep-alive' timer. No other Control Framework response is
valid. On receiving the 200 OK Control Framework message, the valid. On receiving the 200 OK Control Framework message, the
'active' client MUST reset the local 'keep-alive' timer. If no 200 'active' entity MUST reset the local 'keep-alive' timer. If no 200
OK response is received to the K-ALIVE Control Framework message, OK response is received to the K-ALIVE Control Framework message,
before the local 'keep-alive' timer fires, the 'active' client SHOULD before the local 'keep-alive' timer fires, the 'active' entity SHOULD
tear down the SIP dialog and recover the associated control channel tear down the SIP dialog and recover the associated control channel
resources. The 'active' client MAY choose to try and recover the resources. The 'active' entity MAY choose to try and recover the
connection by renegotiation using COMEDIA. It should be noted that connection by renegotiation using COMEDIA. It should be noted that
the local 'active' keep-alive timer MUST be reset on receipt of any the local 'active' keep-alive timer MUST be reset on receipt of any
Control Framework message (request or response) from the passive Control Framework message (request or response) from the passive
client. entity.
When acting as a 'passive' client, a 'K-ALIVE' Control Framework When acting as a 'passive' entity, a 'K-ALIVE' Control Framework
message MUST be received before the local 'keep-alive' timer fires. message MUST be received before the local 'keep-alive' timer fires.
The 'passive' client MUST generate a 200 OK control framework The 'passive' entity MUST generate a 200 OK control framework
response to the K-ALIVE Control Framework message. On sending the response to the K-ALIVE Control Framework message. On sending the
200 OK response, the 'passive' client MUST reset the local 'keep- 200 OK response, the 'passive' entity MUST reset the local 'keep-
alive' timer. If no K-ALIVE message is received before the local alive' timer. If no K-ALIVE message is received before the local
'keep-alive' timer fires, the 'passive' client SHOULD tear down the 'keep-alive' timer fires, the 'passive' entity SHOULD tear down the
SIP dialog and recover the associated control channel resources. The SIP dialog and recover the associated control channel resources. The
'active' client MAY try to and recover the connection by 'active' entity MAY try to and recover the connection by
renegotiating using COMEDIA. It should be noted that the local renegotiating using COMEDIA. It should be noted that the local
'passive' keep-alive timer MUST be reset on receipt of any Control 'passive' keep-alive timer MUST be reset on receipt of any Control
Framework message (request or response) from the active client. Framework message (request or response) from the active entity.
7.1.4. Package Negotiation 6.1.4. Package Negotiation
As part of the SYNCH message exchange a client generating the request As part of the SYNCH message exchange a client generating the request
MUST include a "Packages" header, as defined in Section 11. The MUST include a "Packages" header, as defined in Section 9. The
"Packages " header will contain a list of all Control Framework "Packages " header will contain a list of all Control Framework
packages that can be supported within this control session (from the packages that can be supported within this control session (from the
perspective of the entity creating the SYNCH message). All tokens perspective of the entity creating the SYNCH message). All tokens
MUST be official SIP Control Framework packages that adhere to the MUST be SIP Control Framework packages that adhere to the rules set
rules set out in Section 9. The initial SYNCH message MUST at least out in Section 8. The initial SYNCH message MUST at least contain a
contain a single value. single value.
An entity receiving the initial SYNCH request should carefully An entity receiving the initial SYNCH request should carefully
examine the contents of the "Packages" header. The entity responding examine the contents of the "Packages" header. The entity responding
with a 200 response to the SYNCH header will also populate the with a 200 response to the SYNCH header will also populate the
"Packages" header with supported Control Framework packages. This "Packages" header with supported Control Framework packages. This
entry only contain packages that are listed in the received SYNCH entry only contain packages that are listed in the received SYNCH
request (either all or a subset). This forms a common set of Control request (either all or a subset). This forms a common set of Control
Packages that are supported by both parties. Any Control Packages Packages that are supported by both parties. Any Control Packages
supported by the receiving entity that are not listed in the SYNCH supported by the receiving entity that are not listed in the SYNCH
message MAY be placed in the "Supported" header of the response. message MAY be placed in the "Supported" header of the response.
This is to provide a hint to the client generating the SYNCH message This is to provide a hint to the client generating the SYNCH message
that the receiving client also supports the listed Control Packages. that the receiving entity also supports the listed Control Packages.
If no packages are supported by the entity receiving the SYNCH If no packages are supported by the entity receiving the SYNCH
message, it MUST respond with a 422 error response code. The error message, it MUST respond with a 422 error response code. The error
response MUST contain a "Supported" header indicating the packages response MUST contain a "Supported" header indicating the packages
that are supported. The initiating client can then choose to either that are supported. The initiating client can then choose to either
re-submit a new SYNCH message based on the 422 response or consider re-submit a new SYNCH message based on the 422 response or consider
the interaction as a failure. This would lead to termination of the the interaction as a failure. This would lead to termination of the
associated SIP dialog by sending a SIP BYE request, as per RFC 3261 associated SIP dialog by sending a SIP BYE request, as per RFC 3261
[2]. [2].
Once the initial SYNCH transaction is completed, either client MAY Once the initial SYNCH transaction is completed, either client MAY
choose to send a subsequent new SYNCH Control Framework message to choose to send a subsequent new SYNCH Control Framework message to
re-negotiate the packages that are supported with the control re-negotiate the packages that are supported with the control
channel. A new SYNCH message whose Packages header has different channel. A new SYNCH message whose Packages header has different
values from the previous SYNCH message can effectively add and delete values from the previous SYNCH message can effectively add and delete
the packages used in the control channel Subsequent SYNCH message the packages used in the control channel. Subsequent SYNCH message
MUST NOT change the value of the "Dialog-ID" and "Keep-Alive" Control MUST NOT change the value of the "Dialog-ID" and "Keep-Alive" Control
Framework headers that appeared in the original SYNCH negotiation. Framework headers that appeared in the original SYNCH negotiation.
If a client receiving a subsequent SYNCH message does not wish to re- If a client receiving a subsequent SYNCH message does not wish to re-
negotiate it MUST respond with a 421 Control Framework response code. negotiate it MUST respond with a 421 Control Framework response code.
Any Control Framework commands relating to a Control Package that is Any Control Framework commands relating to a Control Package that is
no longer supported by the session are received after re-negotiation, no longer supported by the session are received after re-negotiation,
the receiving entity SHOULD respond with a 420 response. An entity the receiving entity SHOULD respond with a 420 response. An entity
MAY choose to honor such commands for a limited period of time but MAY choose to honor such commands for a limited period of time but
this is implementation specific. this is implementation specific.
7.2. Constructing Responses 6.2. Constructing Responses
A Control Client or Server, on receiving a request, MUST generate a A Control Client or Server, on receiving a request, MUST generate a
response within 'Command-Time time'. The response MUST conform to response within 'Transaction-Time'. The response MUST conform to the
the ABNF defined in Section 11. The first line of the response MUST ABNF defined in Section 9. The first line of the response MUST
contain the transaction identifier used in first line of the request, contain the transaction identifier used in first line of the request,
as defined in Section 7.1. Responses MUST NOT include the 'Status' as defined in Section 6.1. Responses MUST NOT include the 'Status'
or 'Timeout' message headers - if they are included they have no or 'Timeout' message headers - if they are included they have no
meaning or semantics. meaning or semantics.
[Editors Note: Work Group to pick response time]. [Editors Note:DP6 - Need to pick a time for "Transaction-Time" - Work
Group input requested.]
A Control Client or Server MUST then include a status code in the A Control Client or Server MUST then include a status code in the
first line of the constructed response. A Control Framework request first line of the constructed response. A Control Framework request
(like CONTROL) that has been understood, and either the relevant (like CONTROL) that has been understood, and either the relevant
actions for the control command have completed or a control command actions for the control command have completed or a control command
error is detected, uses the 200 Control Framework status code as error is detected, uses the 200 Control Framework status code as
defined in Section 8.1. A 200 response MAY include message bodies. defined in Section 7.1. A 200 response MAY include message bodies.
If a 200 response does contain a payload it MUST include a Content- If a 200 response does contain a payload it MUST include Content-
Length header. A 200 is the only response defined in this Length and Content-Type headers. A 200 is the only response defined
specification that allows a message body to be included. A client in this specification that allows a message body to be included. A
receiving a 200 class response then considers the control command client receiving a 200 class response then considers the control
completed. A Control Framework request (like CONTROL) that is command transaction completed. A Control Framework request (like
received and understood but requires processing that extends beyond CONTROL) that is received and understood but requires processing that
'Command-Time' time will return a 202 status code in the response. extends beyond 'Transaction-Time' time will return a 202 status code
This will be followed immediately by an initial REPORT message as in the response. This will be followed by an REPORT message(s) as
defined in Section 7.1.2. A Control Package SHOULD explicitly define defined in Section 6.1.2. A Control Package SHOULD explicitly define
the circumstances under which either 200 or 202 with subsequent the circumstances under which either 200 or 202 with subsequent
processing takes place. processing takes place.
[Editors Note:DP7 - Need to pick a time for "Transaction-Time" - Work
Group input requested.]
If a Control Client or Server encounters problems with either a If a Control Client or Server encounters problems with either a
Control Framework request (like REPORT or CONTROL), an appropriate Control Framework request (like REPORT or CONTROL), an appropriate
error code should be used in the response, as listed in Section 8. error code should be used in the response, as listed in Section 7.
The generation of a non 2xx class response code to either a Control The generation of a non 2xx class response code to either a Control
Framework request (like CONTROL or REPORT) will result in failure of Framework request (like CONTROL or REPORT) will indicate failure of
the transaction, and all associated state and resources should be the transaction, and all associated state and resources should be
terminated. The response code may provide an explicit indication of terminated. The response code may provide an explicit indication of
why the transaction failed, which might result in a re-submission of why the transaction failed, which might result in a re-submission of
the request. the request.
8. Response Code Descriptions 7. Response Code Descriptions
The following response codes are defined for transaction responses to The following response codes are defined for transaction responses to
methods defined in Section 7.1. All response codes in this section methods defined in Section 6.1. All response codes in this section
MUST be supported and can be used in response to both CONTROL and MUST be supported and can be used in response to both CONTROL and
REPORT messages except that a 202 MUST NOT be generated in response REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message. to a REPORT message.
Note that these response codes apply to framework transactions only. Note that these response codes apply to framework transactions only.
Success or error indications for control commands MUST be treated as Success or error indications for control commands MUST be treated as
the result of a control command and returned in either a 200 response the result of a control command and returned in either a 200 response
or REPORT message. or REPORT message.
8.1. 200 Response Code 7.1. 200 Response Code
The 200 code indicates the completion of a successful transaction. The 200 code indicates the completion of a successful transaction.
8.2. 202 Response Code 7.2. 202 Response Code
The 202 response code indicates the completion of a successful The 202 response code indicates the completion of a successful
transaction with additional information to be provided at a later transaction with additional information to be provided at a later
time through the REPORT mechanism defined in Section 7.1.2. time through the REPORT mechanism defined in Section 6.1.2.
8.3. 400 Response Code 7.3. 400 Response Code
The 400 response indicates that the request was syntactically The 400 response indicates that the request was syntactically
incorrect. incorrect.
8.4. 403 Response Code 7.4. 403 Response Code
The 400 response indicates that the requested operation is illegal. The server understood the request, but is refusing to fulfill it.
The request SHOULD NOT be repeated.
8.5. 420 Response Code 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 Intended target of the request is for a Control Package that is not
valid for the current session. valid for the current session.
8.6. 421 Response Code 7.7. 421 Response Code
Recipient does not wish to re-negotiate Control Packages at this Recipient does not wish to re-negotiate Control Packages at this
moment in time. moment in time.
8.7. 422 Response Code 7.8. 422 Response Code
Recipient does not support any Control Packages listed in the SYNCH Recipient does not support any Control Packages listed in the SYNCH
message. message.
8.8. 481 Response Code 7.9. 423 Response Code
The 481 response indicates that the intended target of the request Recipient already has a transaction with the same transaction ID.
does not exist.
8.9. 500 Response Code 7.10. 481 Response Code
The 481 response indicates that the transaction of the request does
not exist.
7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
request request
9. Control Packages 8. Control Packages
"Control Packages" are intended to specify behavior that extends the "Control Packages" are intended to specify behavior that extends the
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.
9.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 event tokens is token. Information on registering control package tokens is
contained in Section 14. The package name MUST also register a contained in Section 12. The package name MUST also register a
version number for the package. This enables updates to the package version number for the package which is separated with a '/' symbol
to be registered where appropriate. An initial version of a package e.g. package_name/1.0. This enables updates to the package to be
MUST start with the value '1.0'. Subsequent versions MUST increment registered where appropriate. An initial version of a package MUST
this number if the same package name is to be used. The exact start with the value '1.0'. Subsequent versions MUST increment this
increment is left to the discretion of the package author. number if the same package name is to be used. The exact increment
is left to the discretion of the package author.
9.2. Framework Message Usage 8.2. Framework Message Usage
The Control Framework defines a number of message primitives that can The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no be used to exchange commands and information. There are no
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document should control channel. This section of a Control package document should
explicitly detail the control messages that can be used as well as explicitly detail the control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. include which role type is allowed to initiate a request type.
[Editors Note: Need to examine text.] 8.3. Common XML Support
9.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required. attributes for media dialog or Conference reference are required.
The Control Package will make strong statements (MUST strength) if The Control Package will make strong statements (MUST strength) if
the XML schema defined in Section 16.1 in Appendix A is to be 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 supported. If only part of the schema is required (for example just
'connection-id' or just conf-id), the Control Package will make 'connection-id' or just conf-id), the Control Package will make
equally strong (MUST strength) statements. equally strong (MUST strength) statements.
9.4. CONTROL Message Bodies 8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 7 (or that no control package body is required). This Section 6 (or that no control package body is required). This
section should indicate the location of detailed syntax definitions section should indicate the location of detailed syntax definitions
and semantics for the appropriate body types. and semantics for the appropriate body types.
9.5. REPORT Message Bodies 8.5. REPORT Message Bodies
This mandatory section of a Control Package defines the REPORT body This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in that can be contained within a REPORT command request, as defined in
Section 7 (or that no report package body is required). This section Section 6 (or that no report package body is required). This section
should indicate the location of detailed syntax definitions and should indicate the location of detailed syntax definitions and
semantics for the appropriate body types. It should be noted that semantics for the appropriate body types. It should be noted that
the Control Framework specification does allow for payloads to exist the Control Framework specification does allow for payloads to exist
in 200 responses to CONTROL messages (as defined in this document). in 200 responses to CONTROL messages (as defined in this document).
An entity that is prepared to receive a payload type in a REPORT 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 message MUST also be prepared to receive the same payload in a 200
response to a CONTROL message. response to a CONTROL message.
9.5.1. Events 8.6. Audit
A Control Package can optionally include one or more subscriptions
that allow a controlling client to receive specific event updates in
REPORT message bodies. The mechanisms that installs/un-installs
subscriptions is not specified in document and is considered out of
scope. Event notifications are always carried in REPORT messages
MUST conform to the rules detailed in Section 7.1.2.2. This section
of a Control Package definition MUST specify details of the payload
expected to be received from subscriptions that have been installed.
[Editors Note: Ongoing discussions relating to a generic [EDITORS NOTE: DP12 - Need to include audit template mechanism.]
subscription/event mechanism across all packages.]
9.6. Examples 8.7. Examples
It is strongly RECOMMENDED that Control Packages provide a range of It is strongly recommended that Control Packages provide a range of
message flows that represent common flows using the package and this message flows that represent common flows using the package and this
framework document. framework document.
10. Network Address Translation (NAT) 9. Formal Syntax
[Editors Note: This section will look at geographically distributed
systems where NAT traversal might be an issue. It will look at both
the SIP media dialog traversal and the control channel traversal.
Should this be in a separate doc?]
11. Formal Syntax
11.1. Control Framework Formal Syntax 9.1. Control Framework Formal Syntax
The Control Framework interactions use the UTF-8 transformation The Control Framework interactions use the UTF-8 transformation
format as defined in RFC3629 [16]. The syntax in this section uses format as defined in RFC3629 [16]. The syntax in this section uses
the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [17]. the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [17].
control-req-or-resp = control-request / control-response control-req-or-resp = control-request / control-response
control-request = control-req-start headers [control-content] control-request = control-req-start *( headers ) CRLF [control-content]
control-response = control-resp-start headers control-response = control-resp-start *( headers ) CRLF [control-content]
control-req-start = pSCFW SP transact-id SP method CRLF control-req-start = pSCFW SP transact-id SP method CRLF
control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pSCFW = %x53.43.46.57; SCFW in caps pSCFW = %x53.43.46.57; SCFW in caps
transact-id = alpha-num-token transact-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNCH / mK-ALIVE / other-method method = mCONTROL / mREPORT / mSYNCH / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNCH = %x53.59.4E.43.48; SYNCH in caps mSYNCH = %x53.59.4E.43.48; SYNCH in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this and other documents status-code = 3DIGIT ; any code defined in this and other documents
headers = Content-Length headers = header-name CRLF
header-name = (Content-Length
/Control-Package /Control-Package
/Status /Status
/Seq /Seq
/Timeout /Timeout
/Dialog-id /Dialog-id
/Packages /Packages
/Supported /Supported
/Keep-alive /Keep-alive
/ext-header /ext-header) CRLF
Content-Length = "Content-Length:" SP 1*DIGIT Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("pending" / "update" / "terminate" ) Status = "Status:" SP ("pending" / "update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-ID:" SP dialog-id-string Dialog-id = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name) Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supported *(COMMA supported) Supported = "Supported:" SP supported *(COMMA supported)
Keep-alive = "Keep-Alive:" SP delta-seconds Keep-alive = "Keep-Alive:" SP delta-seconds
skipping to change at page 28, line 11 skipping to change at page 28, line 24
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
The following table details a summary of the headers that can be The following table details a summary of the headers that can be
contained in Control Framework interactions. The "where" columns contained in Control Framework interactions. The "where" columns
details where headers can be used: details where headers can be used:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; 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 2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used; codes with which the header field can be used;
An empty entry in the "where" column indicates that the header An empty entry in the "where" column indicates that the header
field may be present in all requests and responses. field may be present in all requests and responses.
The remaining columns list the specified methods and the presence of The remaining columns list the specified methods and the presence of
a specific header: a specific header:
m: The header field is mandatory. m: The header field is mandatory.
skipping to change at page 28, line 38 skipping to change at page 29, line 19
Seq - m - - Seq - m - -
Status R - m - - Status R - m - -
Timeout R - m - - Timeout R - m - -
Dialog-ID R - - m - Dialog-ID R - - m -
Packages - - m - Packages - - m -
Supported r - - o - Supported r - - o -
Keep-Alive R - - o - Keep-Alive R - - o -
Figure 10: Table 1 Figure 10: Table 1
12. Examples 10. Examples
The following examples provide an abstracted flow of Control Channel The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document. Control Framework interactions defined in this document.
In this example, the Control Client establishes a control channel,
SYNCHs with the Control Server, and issues a CONTROL request that
can't be completed within "transaction-timeout" seconds, so the
Control Server returns a 202 response code to extend the
trqansaction. The Control Server then follows with REPORTs until the
requested action has been completed. The SIP dialog is then
terminated.
[Editors Note:DP8 - Need to pick a time for "Transaction-Time" - Work
Group input requested.]
Control Client Control Server Control Client Control Server
| | | |
| (1) SIP INVITE | | (1) SIP INVITE |
| ----------------------------------------> | | ----------------------------------------> |
| | | |
| (2) SIP 200 | | (2) SIP 200 |
| <--------------------------------------- | | <--------------------------------------- |
| | | |
| (3) SIP ACK | | (3) SIP ACK |
| ----------------------------------------> | | ----------------------------------------> |
skipping to change at page 30, line 13 skipping to change at page 31, line 4
| | | |
| (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@example.com> To: <sip:control-server@examplae.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
s=- s=-
c=IN IP4 control-client.example.com c=IN IP4 control-client.example.com
m=application 7575 TCP/ESCS m=application 7575 TCP/SCFW
a=setup:active a=setup:active
a=connection:new a=connection:new
2. Control Server->Control Client (SIP): 200 OK 2. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP 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@pc2.example.com> Contact: <sip:control-client@pc2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [..] Content-Length: [..]
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=- s=-
c=IN IP4 control-server.example.com c=IN IP4 control-server.example.com
m=application 7575 TCP/ESCS m=application 7575 TCP/SCFW
a=setup:passive a=setup:passive
a=connection:new a=connection:new
3. Control Client->Control Server (SIP): ACK 3. Control Client->Control Server (SIP): ACK
4. Control Client opens a TCP connection to the Control Server. 4. Control Client opens a TCP connection to the Control Server.
The connection can now be used to exchange control framework The connection can now be used to exchange control framework
messages. Control Client-->Control Server (Control Framework messages. Control Client-->Control Server (Control Framework
Message): SYNCH. Message): SYNCH.
SCFW 8djae7khauj SYNCH SCFW 8djae7khauj SYNCH
skipping to change at page 31, line 32 skipping to change at page 32, line 21
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
6. Control Client opens a TCP connection to the Control Server. 6. Control Client opens a TCP connection to the Control Server.
The connection can now be used to exchange control framework The connection can now be used to exchange control framework
messages. Control Client-->Control Server (Control Framework messages. Control Client-->Control Server (Control Framework
Message): CONTROL. Message): CONTROL.
SCFW i387yeiqyiq CONTROL SCFW i387yeiqyiq CONTROL
Control-Package: <package-name> Control-Package: <package-name>
Content-Type: example_content/example_content
Content-Length: 11 Content-Length: 11
<XML BLOB/> <XML BLOB/>
7. Control Server-->Control Client (Control Framework Message): 7. Control Server-->Control Client (Control Framework Message):
202. 202.
SCFW i387yeiqyiq 202 SCFW i387yeiqyiq 202
Timeout: 10
8. Control Server-->Control Client (Control Framework Message): 8. Control Server-->Control Client (Control Framework Message):
REPORT. REPORT.
SCFW i387yeiqyiq REPORT SCFW i387yeiqyiq REPORT
Seq: 1 Seq: 1
Status: pending Status: pending
Timeout: 10 Timeout: 10
9. Control Client-->Control Server (Control Framework Message): 9. Control Client-->Control Server (Control Framework Message):
200. 200.
SCFW i387yeiqyiq 200 SCFW i387yeiqyiq 200
Seq: 1 Seq: 1
10. Control Server-->Control Client (Control Framework Message): 10. Control Server-->Control Client (Control Framework Message):
REPORT. REPORT.
SCFW i387yeiqyiq REPORT SCFW i387yeiqyiq REPORT
skipping to change at page 32, line 17 skipping to change at page 33, line 9
SCFW i387yeiqyiq 200 SCFW i387yeiqyiq 200
Seq: 1 Seq: 1
10. Control Server-->Control Client (Control Framework Message): 10. Control Server-->Control Client (Control Framework Message):
REPORT. REPORT.
SCFW i387yeiqyiq REPORT SCFW i387yeiqyiq REPORT
Seq: 2 Seq: 2
Status: update Status: update
Timeout: 10 Timeout: 10
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/> <XML BLOB/>
11. Control Client-->Control Server (Control Framework Message): 11. Control Client-->Control Server (Control Framework Message):
200. 200.
SCFW i387yeiqyiq 200 SCFW i387yeiqyiq 200
Seq: 2 Seq: 2
12. Control Server-->Control Client (Control Framework Message): 12. Control Server-->Control Client (Control Framework Message):
REPORT. REPORT.
SCFW i387yeiqyiq REPORT SCFW i387yeiqyiq REPORT
Seq: 3 Seq: 3
Status: terminate Status: terminate
Timeout: 10 Timeout: 10
Content-Type: example_content/example_content
Content-Length: 11
<XML BLOB/> <XML BLOB/>
13. Control Client-->Control Server (Control Framework Message): 13. Control Client-->Control Server (Control Framework Message):
200. 200.
SCFW i387yeiqyiq 200 SCFW i387yeiqyiq 200
Seq: 3 Seq: 3
14. Control Client->Control Server (SIP): BYE 14. Control Client->Control Server (SIP): BYE
BYE sip:control-client@pc2.example.com SIP/2.0 BYE sip:control-client@pc2.example.com SIP/2.0
To: <sip:control-server@example.com> To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE CSeq: 2 BYE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
15. Control Server->Control Client (SIP): 200 OK
15. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE CSeq: 2 BYE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
13. Security Considerations 11. Security Considerations
Security Considerations to be included in later versions of this SIP Control Framework needs to provide confidentiality and integrity
document. for 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 connection has not been hijacked.
14. IANA Considerations SIP Control Framework is designed to comply with the security-related
requirements documented in the control prtoocol requirements
document[8]. Specific security measures employed by the SIP Control
Framework are summarized in the following subsections.
14.1. Control Package Registration Information 11.1. Session Establishment
14.1.1. Control Package Registration Template SIP Control 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 following are required:
14.2. SDP Transport Protocol o The SIP implementation in Control Framework clients and servers
MUST support digest authentication as specified in RFC3261 [2] and
'Enhancements for Authenticated Identity Management in the Session
Initiation Protocol (SIP)[18].
o The SIP implementation in Control Framework clients and servers
SHOULD employ SIPS: URIs as specified in RFC3261 [2].
14.2.1. TCP/ESCS [EDITORS NOTE:DP9 - Sip identity - is this too strong?]
14.2.2. TCP/TLS/ESCS [EDITORS NOTE:DP10 - WHAT DO WE SAY ABOUT S/MIME????]
14.3. SDP Attribute Names 11.2. Transport Level Protection
14.4. SIP Response Codes When using only TCP connections, the SIP Control Framework security
is weak. Although the SIP Control 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 is carried over the Control Framework channel.
Clients and servers must be properly authenticated and the control
channel must permit the use of both confidentiality and integrity for
the data. To ensure control channel protection, Control Framework
clients and servers MUST support TLS and SHOULD utilize it by default
unless alternative control channel protection is used or a protected
environment is guaranteed. Alternative control channel protection
MAY be used if desired (e.g.IPSEC).
TLS is used to authenticate devices and to provide integrity and
confidentiality for the header fields being transported on the
control chanel. SIP Control Framowork elements MUST implement TLS
and MUST also implement the TLS ClientExtendedHello extended hello
information for server name indication as described in [19]. A TLS
cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA[2] MUST be supported
(other cipher-suites MAY also be supported).
11.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control
channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create
connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to
overcome such conflicts but will provide a summary of how it can be
achieved.
It can be determined that access to resources and use of control
channels relates to policy. It is implementation detail as to the
level of policy that is adopted for use with specification. 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 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 SIP Control Framework Parameter
registry is a container for sub-registries. This section further
introduces sub-registries for SIP Control 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).
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 SIP Control 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]
SYNCH - [RFCXXX]
The following information MUST be provided in an RFC publication in
o The method name.
o The RFC number in which the method is registered.
12.3. Control Framework Status Codes
This specification establishes the Status-Code sub-registry under SIP
Control 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 SIP Control 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]
The following information MUST be provided in an RFC publication in
order to register a new SIP Control Framework header field:
o The header field name.
o The RFC number in which the method is registered.
12.5. Control Framework Port
[Editors Note:DP11 - To be discussed].
12.6. SDP Transport Protocol
the SIP Control Framework defines the new SDP protocol field values
'TCP/SCFW', 'TCP/TLS/SCFW', 'SCTP/SCFW' and 'SCTP/ TLS/SCFW", which
should be registered in the sdp-parameters registry under "proto".
The values have the following meaning:
o TCP/SCFW: Indicates the SIP Control Framework when TCP is used as
an underlying transport for the control channel.
o TCP/TLS/SCFW: Indicates the SIP Control Framework when TLS over
TCP is used as an underlying transport for the control channel.
o SCTP/SCFW: Indicates the SIP Control Framework when SCTP is used
as an underlying transport for the control channel.
o SCTP/TLS/SCFW: Indicates the SIP Control 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/SCFW', 'TCP/TLS/
SCFW', 'SCTP/SCFW' and 'SCTP/TLS/SCFW' 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.
13. Changes
Note to RFC Editor: Please remove this whole section.
13.1. Changes from 00 Version
o Aligned tokens to be 'SCFW' (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.
14. Contributors
Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document.
15. Acknowledgments 15. Acknowledgments
The authors would like to thank Ian Evans and Michael Bardzinski of The authors would like to thank Ian Evans and Michael Bardzinski of
Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for
useful review and input to this work. Eric Burger contributed to the useful review and input to this work. Eric Burger contributed to the
early phases of this work. early phases of this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even.
16. Appendix A 16. 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 35, line 21 skipping to change at page 41, line 25
grouping through a 'conf' XML container. If used by a Control grouping through a 'conf' XML container. If used by a Control
Package, any control XML referenced by the attribute applies to all Package, any control XML referenced by the attribute applies to all
related media dialogs. Unlike the dialog attribute, the 'conf-id' related media dialogs. Unlike the dialog attribute, the 'conf-id'
attribute does not need to be constructed based on the overlying SIP attribute does not need to be constructed based on the overlying SIP
dialog. The 'conf-id' attribute value is system specific and should dialog. The 'conf-id' attribute value is system specific and should
be selected with relevant context and uniqueness. be selected with relevant context and uniqueness.
The full schema follows: The full schema follows:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes" xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- xs:include schemaLocation="common-schema.xsd"/ --> <!--xsd:include schemaLocation="common-schema.xsd"/-->
<xsd:attributeGroup name="framework-attributes"> <xsd:attributeGroup name="framework-attributes">
<xsd:annotation> <xsd:annotation>
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation> <xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="connection-id" type="xsd:string"/> <xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conf-id" type="xsd:string"/>
</xsd:attributeGroup> <xsd:attribute name="conferenceid" type="xsd:string"/>
</xs:schema>
17. References </xsd:attributeGroup>
</xsd:schema>
17.1. Normative References 17. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
skipping to change at page 36, line 30 skipping to change at page 42, line 32
[7] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway [7] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003. Control Protocol Version 1", RFC 3525, June 2003.
[8] Dolly, M. and R. Even, "Media Server Control Protocol [8] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", draft-dolly-mediactrl-requirements-00 (work in Requirements", draft-dolly-mediactrl-requirements-00 (work in
progress), June 2007. progress), June 2007.
[9] Handley, M., "SDP: Session Description Protocol", [9] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[10] Levin, O. and G. Camarillo, "The SDP (Session Description [10] Levin, O. and G. Camarillo, "The Session Description Protocol
Protocol) Label Attribute", (SDP) Label Attribute", RFC 4574, August 2006.
draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005.
[11] Jennings, C. and R. Mahy, "Managing Client Initiated [11] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007. draft-ietf-sip-outbound-11 (work in progress), November 2007.
[12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004. April 2004.
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
skipping to change at page 37, line 13 skipping to change at page 43, line 13
[15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[18] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[19] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 4366, April 2006.
[20] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Ubiquity Software Corporation Avaya
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com Email: cboulton@avaya.com
Tim Melanchuk Tim Melanchuk
TJM Consulting Rain Willow Communications
Email: tim.melanchuk@gmail.com Email: tim.melanchuk@gmail.com
Scott McGlashan Scott McGlashan
Hewlett-Packard Hewlett-Packard
Gustav III:s boulevard 36 Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com Email: scott.mcglashan@hp.com
Asher Shiratzky
Radvision
24 Raoul Wallenberg st
Tel-Aviv, Israel
Email: ashers@radvision.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 168 change blocks. 
376 lines changed or deleted 626 lines changed or added

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