draft-ietf-mediactrl-sip-control-framework-10.txt   draft-ietf-mediactrl-sip-control-framework-11.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track T. Melanchuk Intended status: Standards Track T. Melanchuk
Expires: August 30, 2009 Rain Willow Communications Expires: April 26, 2010 Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
February 26, 2009 October 23, 2009
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-10 draft-ietf-mediactrl-sip-control-framework-11
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 August 30, 2009. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 12 skipping to change at page 3, line 12
Framework will be used for a wide variety of de-coupled control Framework will be used for a wide variety of de-coupled control
architectures between network entities. architectures between network entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 11 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 11
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 11 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 11
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 14
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15 6. Control Framework Interactions . . . . . . . . . . . . . . . . 16
6.1. General Behaviour for Constructing Requests . . . . . . . 17 6.1. General Behaviour for Constructing Requests . . . . . . . 18
6.2. General Behaviour for Constructing Responses . . . . . . 18 6.2. General Behaviour for Constructing Responses . . . . . . 19
6.3. Transaction Processing . . . . . . . . . . . . . . . . . 18 6.3. Transaction Processing . . . . . . . . . . . . . . . . . 19
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 20
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 20
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 22
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 23
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 25
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 27
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 27
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 27
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Control Package Name . . . . . . . . . . . . . . . . . . 26 8.1. Control Package Name . . . . . . . . . . . . . . . . . . 27
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 28
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 27 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 28
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 27 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 28
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 28
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 29
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 32
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11.2. Transport Level Protection . . . . . . . . . . . . . . . 37 12.1. Session Establishment . . . . . . . . . . . . . . . . . . 39
11.3. Control Channel Policy Management . . . . . . . . . . . . 37 12.2. Transport Level Protection . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.3. Control Channel Policy Management . . . . . . . . . . . . 39
12.1. Control Packages Registration Information . . . . . . . . 38 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
12.1.1. Control Package Registration Template . . . . . . . . 39 13.1. Control Packages Registration Information . . . . . . . . 40
12.2. Control Framework Method Names . . . . . . . . . . . . . 39 13.1.1. Control Package Registration Template . . . . . . . . 41
12.3. Control Framework Status Codes . . . . . . . . . . . . . 40 13.2. Control Framework Method Names . . . . . . . . . . . . . 41
12.4. Control Framework Header Fields . . . . . . . . . . . . . 40 13.3. Control Framework Status Codes . . . . . . . . . . . . . 42
12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41 13.4. Control Framework Header Fields . . . . . . . . . . . . . 42
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41 13.5. Control Framework Port . . . . . . . . . . . . . . . . . 42
12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41 13.6. Media Type Registration . . . . . . . . . . . . . . . . . 43
12.8. URN Sub-Namespace for 13.6.1. Registration of MIME Media Type application/cfw . . . 44
urn:ietf:params:xml:ns:control:framework-attributes . . . 42 13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 45
12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42 13.8. URN Sub-Namespace for
12.10. MIME Media Type Registration for urn:ietf:params:xml:ns:control:framework-attributes . . . 45
'application/framework-attributes+xml' . . . . . . . . . 43 13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 46
13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.10. MIME Media Type Registration for
13.1. Changes from 09 Version . . . . . . . . . . . . . . . . . 43 'application/framework-attributes+xml' . . . . . . . . . 46
13.2. Changes from 08 Version . . . . . . . . . . . . . . . . . 44 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.3. Changes from 07 Version . . . . . . . . . . . . . . . . . 44 14.1. Changes from 10 Version . . . . . . . . . . . . . . . . . 47
13.4. Changes from 06 Version . . . . . . . . . . . . . . . . . 44 14.2. Changes from 09 Version . . . . . . . . . . . . . . . . . 48
13.5. Changes from 05 Version . . . . . . . . . . . . . . . . . 44 14.3. Changes from 08 Version . . . . . . . . . . . . . . . . . 48
13.6. Changes from 04 Version . . . . . . . . . . . . . . . . . 44 14.4. Changes from 07 Version . . . . . . . . . . . . . . . . . 48
13.7. Changes from 03 Version . . . . . . . . . . . . . . . . . 44 14.5. Changes from 06 Version . . . . . . . . . . . . . . . . . 48
13.8. Changes from 02 Version . . . . . . . . . . . . . . . . . 45 14.6. Changes from 05 Version . . . . . . . . . . . . . . . . . 48
13.9. Changes from 01 Version . . . . . . . . . . . . . . . . . 45 14.7. Changes from 04 Version . . . . . . . . . . . . . . . . . 48
13.10. Changes from 00 Version . . . . . . . . . . . . . . . . . 45 14.8. Changes from 03 Version . . . . . . . . . . . . . . . . . 49
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 14.9. Changes from 02 Version . . . . . . . . . . . . . . . . . 49
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 14.10. Changes from 01 Version . . . . . . . . . . . . . . . . . 49
16. Appendix: Common Package Components . . . . . . . . . . . . . 46 14.11. Changes from 00 Version . . . . . . . . . . . . . . . . . 50
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
17.1. Normative References . . . . . . . . . . . . . . . . . . 48 17. Appendix: Common Package Components . . . . . . . . . . . . . 51
17.2. Informative References . . . . . . . . . . . . . . . . . 49 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
18.1. Normative References . . . . . . . . . . . . . . . . . . 52
18.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Real-time media applications are often developed using an Real-time media applications are often developed using an
architecture where the application logic and media processing architecture where the application logic and media processing
activities are distributed. Commonly, the application logic runs on activities are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers, "application servers" but the processing runs on external servers,
such as "media servers". This document focuses on the framework and such as "media servers". This document focuses on the framework and
protocol between the application server and external processing protocol between the application server and external processing
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
skipping to change at page 7, line 31 skipping to change at page 7, line 31
the media server, what do we need SIP for?" This is a reasonable the media server, what do we need SIP for?" This is a reasonable
question. The key is we use SIP for media session establishment. If question. The key is we use SIP for media session establishment. If
we are using SIP for media session establishment, then we need to we are using SIP for media session establishment, then we need to
ensure the URI used for session establishment resolves to the same ensure the URI used for session establishment resolves to the same
node as the node for session control. Using the SIP routing node as the node for session control. Using the SIP routing
mechanism, and having the server initiate the TCP connection back, mechanism, and having the server initiate the TCP connection back,
ensures this works. For example, the URI sip:myserver.example.com ensures this works. For example, the URI sip:myserver.example.com
may resolve to sip:server21.farm12.northeast.example.net, whereas the may resolve to sip:server21.farm12.northeast.example.net, whereas the
URI http://myserver.example.com may resolve to URI http://myserver.example.com may resolve to
http://server41.httpfarm.central.example.net. That is, the host part http://server41.httpfarm.central.example.net. That is, the host part
is NOT NECESSARILY unambiguous. is not necessarily unambiguous.
The use of SIP to negotiate the control-channel provides many The use of SIP to negotiate the control-channel provides many
inherent capabilities which include: inherent capabilities which include:
o Service location - Use SIP Proxies and Back-to-Back User Agents o Service location - Use SIP Proxies and Back-to-Back User Agents
for locating Control Servers. for locating Control Servers.
o Security mechanisms - Leverage established security mechanisms o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication. such as Transport Layer Security (TLS) and Client Authentication.
o Connection maintenance - The ability to re-negotiate a connection, o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, and so forth. ensure it is active, and so forth.
o Application agnostic - Generic protocol allows for easy extension. o Application agnostic - Generic protocol allows for easy extension.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Control | | Control | | Control | | Control |
| Client |<----Control Channel---->| Server | | Client |<----Control Channel---->| Server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Basic Architecture Figure 1: Basic Architecture
The example from Figure 1 conveys a 1:1 connection between the The example from Figure 1 conveys a 1:1 connection between the
Control Client and the Control Server. It is possible, if required, Control Client and the Control Server. It is possible, if required,
for the client to request multiple control channels using separate for the client to request multiple control channels using separate
SIP dialogs between the Control Client and the Control Server SIP INVITE dialogs between the Control Client and the Control Server
entities. Any of the connections created between the two entities entities. Any of the connections created between the two entities
can then be used for Server control interactions. The control can then be used for Server control interactions. The control
connections are orthogonal to any given media session. Specific connections are orthogonal to any given media session. Specific
media session information are incorporated in control interaction media session information are incorporated in control interaction
commands, which themselves are defined in external packages, using commands, which themselves are defined in external packages, using
the XML schema defined in Section 16. The ability to have multiple the XML schema defined in Section 17. The ability to have multiple
control channels allows for stronger redundancy and the ability to control channels allows for stronger redundancy and the ability to
manage high volumes of traffic in busy systems. manage high volumes of traffic in busy systems.
Consider the following simple example for session establishment Consider the following simple example for session establishment
between a Client and a Server (Note: Some lines in the examples are between a Client and a Server (Note: Some lines in the examples are
removed for clarity and brevity). Note that the roles discussed are removed for clarity and brevity). Note that the roles discussed are
logical and can change during a session, if the Control Package logical and can change during a session, if the Control Package
allows. allows.
The Client constructs and sends a standard SIP INVITE request, as The Client constructs and sends a standard SIP INVITE request, as
defined in [RFC3261], to the external Server. The SDP payload defined in [RFC3261], to the external Server. The SDP payload
includes the required information for control channel negotiation and includes the required information for control channel negotiation and
is the primary mechanism for conveying support for this specification is the primary mechanism for conveying support for this
(through the media type). The COMEDIA [RFC4145] specification for specification. The application/cfw MIME type is defined in this
setting up and maintaining reliable connections is used as part of document to convey the appropriate SDP format for compliance to this
the negotiation mechanism (more detail available in later sections). specification. The COMEDIA [RFC4145] specification for setting up
The Client also includes the 'cfw-id' SDP attribute, as defined in and maintaining reliable connections is used as part of the
this specification, which is used to correlate the underlying Media negotiation mechanism (more detail available in later sections). The
Control Channel with the offer/answer exchange. Client also includes the 'cfw-id' SDP attribute, as defined in this
specification, which is a unique identifier used to correlate the
underlying Media Control Channel with the offer/answer exchange.
Client Sends to External Server: Client Sends to External Server:
INVITE sip:External-Server@example.com SIP/2.0 INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com> To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746 From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
Max-Forwards: 70
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/CFW * m=application 7575 TCP cfw
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cfw-id:H839quwhjdhegvdga a=cfw-id:H839quwhjdhegvdga
On receiving the INVITE request, an external Server supporting this On receiving the INVITE request, an external Server supporting this
mechanism generates a 200 OK response containing appropriate SDP. mechanism generates a 200 OK response containing appropriate SDP and
The 'cfw-id' SDP attribute is copied from the original offer. formatted using the application/cfw MIME type specified in this
document. The Server inserts its own unique 'cfw-id' SDP attribute
which differs from the one received in the INVITE (offer).
External Server Sends to Client: External Server Sends to Client:
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879 To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746 From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
CSeq: 1 INVITE CSeq: 1 INVITE
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
o=responder 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:U8dh7UHDushsdu32uha
v=0
o=originator 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP/CFW *
a=setup:passive
a=connection:new
a=cfw-id:H839quwhjdhegvdga
The Control Client receives the SIP 200 OK response and extracts the The Control Client receives the SIP 200 OK response and extracts the
relevant information (also sending a SIP ACK). It creates an relevant information (also sending a SIP ACK). It creates an
outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP
connection to the Control Server. The connection address (taken from connection to the Control Server. The connection address (taken from
'c=') and port (taken from 'm=') are used to identify the remote port 'c=') and port (taken from 'm=') are used to identify the remote port
in the new connection. in the new connection.
Once established, the newly created connection can be used to Once established, the newly created connection can be used to
exchange requests and responses as defined in this document. If exchange requests and responses as defined in this document. If
required, after the control channel has been setup, media sessions required, after the control channel has been setup, media sessions
can be established using standard SIP third party call control. can be established using standard SIP third party call control.
Figure 2 provides a simplified example where the framework is used to Figure 2 provides a simplified example where the framework is used to
control a User Agent's RTP session. The link (1) in brackets control a User Agent's RTP session. The link (1) in brackets
represents the SIP dialog and dedicated control channel previously represents the SIP INVITE dialog usage and dedicated control channel
described in this overview section. previously described in this overview section.
+--------Control SIP Dialog(1)---------+ +--------Control SIP Dialog(1)---------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP | +------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack| | |Stack| |Stack|
| +---+-----+---+ +---+-----+---+ | +---+-----+---+ +---+-----+---+
| | | | | | | | | |
| | Control |<--Control Channel(1)-->| | | | Control |<--Control Channel(1)-->| |
| | Client | | Control | | | Client | | Control |
| +-------------+ | Server | | +-------------+ | Server |
+--+--+ | | +--+--+ | |
|User | | | |User | | |
|Agent|<=====================RTP(2)===================>| | |Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+ +-----+ +-------------+
Figure 2: Participant Architecture Figure 2: Participant Architecture
The link (2) from Figure 2 represents the User Agent SIP dialog The link (2) from Figure 2 represents the User Agent SIP INVITE
interactions and associated media flow. A User Agent creates a SIP dialog usage interactions and associated media flow. A User Agent
dialog with the Control Client entity. The Control Client entity creates a SIP INVITE dialog usage with the Control Client entity.
then creates a related dialog to the Control Server, using B2BUA type The Control Client entity then creates a to the Control Server, using
functionality. Using the interaction illustrated by (2), the Control B2BUA type functionality. Using the interaction illustrated by (2),
Client negotiates media capabilities with the Control Server, on the Control Client negotiates media capabilities with the Control
behalf of the User Agent, using SIP Third Party Call Control Server, on behalf of the User Agent, using SIP Third Party Call
[RFC3725]. Control [RFC3725].
4. Control Channel Setup 4. Control Channel Setup
This section describes the setup, using SIP, of the dedicated control This section describes the setup, using SIP, of the dedicated control
channel. Once the control channel has been established commands can channel. Once the control channel has been established commands can
be exchanged (as discussed in Section 6). be exchanged (as discussed in Section 6).
4.1. Control Client SIP UAC Behavior 4.1. Control Client SIP UAC Behavior
When a UAC wishes to establish a control channel, it MUST construct When a UAC wishes to establish a control channel, it MUST construct
and transmit a new SIP INVITE request for control channel setup. The and transmit a new SIP INVITE request for control channel setup. The
UAC MUST construct the INVITE request as defined in [RFC3261]. UAC MUST construct the INVITE request as defined in [RFC3261].
If a reliable response is received (as defined [RFC3261] and If a reliable response is received (as defined [RFC3261] and
[RFC3262]), the mechanisms defined in this document are applicable to [RFC3262]), the mechanisms defined in this document are applicable to
the newly created dialog. the newly created SIP INVITE dialog usage.
The UAC SHOULD include a valid session description (an 'offer' as The UAC SHOULD include a valid session description (an 'offer' as
defined in [RFC3264]) in an INVITE request using the Session defined in [RFC3264]) in an INVITE request using the Session
Description Protocol defined in [RFC4566], unless the Control Client Description Protocol defined in [RFC4566] but MAY choose an offer-
does not have the SDP of the far (non-Control Server) end of the less INVITE as per [RFC3261]. The SDP should be formatted in
session yet. The following information defines the composition of accordance with the steps below which is registered in this document
specific elements of the SDP payload the Client MUST adhere to when as MIME type application/cfw in Section 13. The following
used in an SIP SDP offer. information defines the composition of specific elements of the SDP
payload the offerer MUST adhere to when used in a SIP based offer/
answer exchange using SDP and the application/cfw MIME type. The SDP
being constructed MUST contain only a single occurrence of a control
channel definition outlined in this specification.
The Connection Data line in the SDP payload is constructed as The Connection Data line in the SDP payload is constructed as
specified in [RFC4566]: specified in [RFC4566]:
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The first sub-field, <nettype>, MUST equal the value "IN". The The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The second sub-field, <addrtype>, MUST equal either "IP4" or "IP6". The
third sub-field for Connection Data is <connection-address>. This third sub-field for Connection Data is <connection-address>. This
supplies a representation of the SDP originators address, for example supplies a representation of the SDP originators address, for example
dns/IP representation. The address is the address used for dns/IP representation. The address is the address used for
connections. connections.
Example: Example:
c=IN IP4 controller.example.com c=IN IP4 controller.example.com
The SDP MUST contain a corresponding Media Description entry: The SDP MUST contain a corresponding Media Description entry:
m=<media> <port> <proto> m=<media> <port> <proto> <fmt>
The first "sub-field" <media> MUST equal the value "application". The first "sub-field" <media> MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the The second sub-field, <port>, MUST represent a port on which the
constructing client can receive an incoming connection if required. constructing client can receive an incoming connection if required.
The port is used in combination with the address specified in the The port is used in combination with the address specified in the
'Connection Data line defined previously to supply connection '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 entry. The use of the connections it MUST still enter a valid port entry. The use of the
port value '0' has the same meaning as defined in a SIP Offer/Answer port value '0' has the same meaning as defined in a SIP Offer/Answer
exchange[RFC3264]. The Control Framework has an IANA-registered exchange[RFC3264]. The Control Framework has an IANA-registered
recommended port defined in Section 12.5. This value is not a recommended port defined in Section 13.5. This value is not a
default as a client is free to choose explicit port numbers. default as a client is free to choose explicit port numbers.
However, SDP SHOULD use the registered port number, unless local However, SDP SHOULD use the registered port number, unless local
policy prohibits its use. Using the registered port number allows policy prohibits its use. Using the registered port number allows
network administrators to manage firewall policy for Control network administrators to manage firewall policy for Control
Framework interactions. The third sub-field, <proto>, MUST equal a Framework interactions. The third sub-field, <proto>, MUST equal a
transport value defined in Section 12.6. All implementations standard transport value. All implementations compliant to this
compliant to this specification MUST support the value "TCP/CFW", specification MUST support the values "TCP" and "TCP/TLS".
"TCP/TLS/CFW", "SCTP/CFW" and "SCTP/TLS/CFW" as defined in Implementations MUST support TLS as a transport-level security
Section 12.6 of this document. Implementations MUST support TLS as a mechanism for the control channel, although use of TLS in specific
transport-level security mechanism for the control channel, although deployments is optional. Control Framework implementations MUST
use of TLS in specific deployments is optional. Control Framework support TCP as a transport protocol. When an entity identifies a
implementations MUST support TCP as a transport protocol. Control transport value but is not willing to establish the session, it MUST
Framework implementations MAY support SCTP as a transport protocol. respond using the appropriate SIP mechanism. The <fmt> sub-field
When an entity identifies one of the transport values defined in MUST contain the value "cfw".
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 [RFC4145] specification. The are specifically defined in the COMEDIA [RFC4145] specification. The
attributes provide connection negotiation and maintenance parameters. attributes provide connection negotiation and maintenance parameters.
A client conforming to this specification SHOULD support all the It is RECOMMENDED that a Controlling UAC initiate a connection to an
possible values defined for media attributes from the COMEDIA external Server but that an external Server MAY negotiate and
[RFC4145] specification but MAY choose not to support values if it initiate a connection using COMEDIA, if network topology prohibits
can definitely determine they will never be used. For example, the initiating connections in a certain direction. An example of the
client may naver initiate incoming connections and thus does not need COMEDIA attributes is:
to support the incoming connection parameters. It is RECOMMENDED
that a Controlling UAC initiate a connection to an external Server
but that an external Server MAY negotiate and initiate a connection
using COMEDIA, if network topology prohibits initiating connections
in a certain direction. An example of the COMEDIA attributes is:
a=setup:active a=setup:active
a=connection:new a=connection:new
This example demonstrates a new connection that will be initiated This example demonstrates a new connection that will be initiated
from the owner of the SDP payload. The connection details are from the owner of the SDP payload. The connection details are
contained in the SDP answer received from the UAS. A full example of contained in the SDP answer received from the UAS. A full example of
an SDP payload compliant to this specification can be viewed in an SDP payload compliant to this specification can be viewed in
Section 3. Once the SDP has been constructed along with the Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in [RFC3261]), it can remainder of the SIP INVITE request (as defined in [RFC3261]), it can
be sent to the appropriate location. The SIP dialog and appropriate be sent to the appropriate location. The SIP INVITE dialog usage and
control connection is then established. appropriate control connection is then established.
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP A SIP UAC constructing an offer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. The 'cfw-id' attribute attribute as defined in Section 9.2. The 'cfw-id' attribute
indicates an identifier that can be used within the control channel indicates an identifier that can be used within the control channel
to correlate the control channel with this SIP dialog. This to correlate the control channel with this SIP INVITE dialog usage.
attribute MUST be globally unique over space and time (using an The 'cfw-id' attribute MUST be globally unique over space and time
appropriate algorithm) and will not clash with other offer/answer (using an appropriate algorithm) and MUST NOT clash with instances of
exchanges that will take place. The value chosen for the 'cfw-id' the 'cfw-id' used in other SIP offer/answer exchanges. The value
attribute MUST be used for the entire duration of the associated SIP chosen for the 'cfw-id' attribute MUST be used for the entire
dialog and not be changed during updates to the offer/answer duration of the associated SIP INVITE dialog usage and not be changed
exchange. This applies specifically to the 'connection' attribute as during updates to the offer/answer exchange. This applies
defined in [RFC4145]. If a SIP UAC wants to change some other parts specifically to the 'connection' attribute as defined in [RFC4145].
of the SDP but reuse the already established connection it MUST use If a SIP UAC wants to change some other parts of the SDP but reuse
the value of 'existing' in the 'connection' attribute (for example, the already established connection it MUST use the value of
a=connection:existing). If it has noted that a connection has failed 'existing' in the 'connection' attribute (for example, a=connection:
and wants to re-establish the connection, it MUST use the value of existing). If it has noted that a connection has failed and wants to
'new' in the 'connection' attribute (for example, a=connection:new). re-establish the connection, it MUST use the value of 'new' in the
Throughout this the connection identifier specified in the 'cfw-id' 'connection' attribute (for example, a=connection:new). Throughout
SDP parameter MUST NOT change. One is simply negotiating the this the connection identifier specified in the 'cfw-id' SDP
underlying TCP connection between endpoints but always using the same parameter MUST NOT change. One is simply negotiating the underlying
Control Framework session, which is 1:1 for the lifetime of the SIP TCP connection between endpoints but always using the same Control
dialog. Framework session, which is 1:1 for the lifetime of the SIP INVITE
dialog usage.
A non-2xx class final SIP response (4xx, 5xx and 6xx) received for A non-2xx class final SIP response (3xx, 4xx, 5xx and 6xx) received
the INVITE request indicates that no SIP dialog has been created and for the INVITE request indicates that no SIP INVITE dialog usage has
is treated as specified by SIP [RFC3261]. Specifically, support of been created and is treated as specified by SIP [RFC3261].
this specification is negotiated through the presence of the media Specifically, support of this specification is negotiated through the
type defined in this specification. The receipt of a SIP error presence of the media type defined in this specification. The
response such as "488" indicates that the offer contained in a receipt of a SIP error response such as "488" indicates that the
request is not acceptable. The inclusion of the media line offer contained in a request is not acceptable. The inclusion of the
associated with this specification in such a rejected offer indicates media line associated with this specification in such a rejected
to the client generating the offer that this could be due to the offer indicates to the client generating the offer that this could be
receiving client not supporting this specification. The client due to the receiving client not supporting this specification. The
generating the offer MUST act as it would normally on receiving this client generating the offer MUST act as it would normally on
response, as per [RFC3261]. Media streams can also be rejected by receiving this response, as per [RFC3261]. Media streams can also be
setting the port to "0" in the "m=" line of the session description. rejected by setting the port to "0" in the "m=" line of the session
A client using this specification MUST be prepared to receive an description. A client using this specification MUST be prepared to
answer where the "m=" line it inserted for using the Control receive an answer where the "m=" line it inserted for using the
Framework has been set to "0". In this situation the client will act Control Framework has been set to "0". In this situation the client
as it would for any other media type with a port set to "0". will act as it would for any other media type with a port set to "0".
4.2. Control Server SIP UAS Behavior 4.2. Control Server SIP UAS Behavior
On receiving a SIP INVITE request, an external Server(SIP UAS) On receiving a SIP INVITE request, an external Server(SIP UAS)
inspects the message for indications of support for the mechanisms inspects the message for indications of support for the mechanisms
defined in this specification. This is achieved through inspection defined in this specification. This is achieved through inspection
of the Sessions Description of the offer message and identifying of the Sessions Description of the offer message and identifying
support for the appropriate media type. If the SIP UAS wishes to support for the application/cfw MIME type in the SDP. If the SIP UAS
construct a reliable response that conveys support for the extension, wishes to construct a reliable response that conveys support for the
it MUST follow the mechanisms defined in [RFC3261]. If support is extension, it MUST follow the mechanisms defined in [RFC3261]. If
conveyed in a reliable SIP provisional response, the mechanisms in support is conveyed in a reliable SIP provisional response, the
[RFC3262] MUST also be used. It should be noted that the SDP offer mechanisms in [RFC3262] MUST also be used. It should be noted that
is not restricted to the initial INVITE request and may appear in any the SDP offer is not restricted to the initial INVITE request and may
series of messages that are compliant to [RFC3261], [RFC3262], and appear in any series of messages that are compliant to [RFC3261],
[RFC3264]. [RFC3262], [RFC3311] and [RFC3264].
When constructing an answer, the SDP payload MUST be constructed When constructing an answer, the SDP payload MUST be constructed
using the semantic (Connection, Media and attribute) defined in using the semantic (Connection, Media and attribute) defined in
Section 4.1 using valid local settings and also with full compliance Section 4.1 using valid local settings and also with full compliance
to the COMEDIA [RFC4145] specification. For example, the SDP to the COMEDIA [RFC4145] specification. For example, the SDP
attributes included in the answer constructed for the example offer attributes included in the answer constructed for the example offer
provided in Section 4.1 would look as illustrated below: provided in Section 4.1 would look as illustrated below:
a=setup:passive a=setup:passive
a=connection:new a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP A client constructing an answer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. This attribute MUST exactly attribute as defined in Section 9.2. This attribute MUST be globally
copy the value which appeared in the initial offer. unique over space and time (using an appropriate algorithm) and MUST
NOT clash with instances of the 'cfw-id' used in other SIP offer/
answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id'
value received in the offer as it is used to uniquely identify and
distinguish between multiple endpoint generating SDP answers. The
value chosen for the 'cfw-id' attribute MUST be used for the entire
duration of the associated SIP INVITE dialog usage and not be changed
during updates to the offer/answer exchange.
Once the SDP answer has been constructed, it is sent using standard Once the SDP answer has been constructed, it is sent using standard
SIP mechanisms. Depending on the contents of the SDP payloads that SIP mechanisms. Depending on the contents of the SDP payloads that
were negotiated using the Offer/Answer exchange, a reliable were negotiated using the Offer/Answer exchange, a reliable
connection will be established between the Controlling UAC and connection will be established between the Controlling UAC and
External Server UAS entities. The newly established connection is External Server UAS entities. The newly established connection is
now available to exchange control command primitives. The state of now available to exchange control command primitives. The state of
the SIP Dialog and the associated Control channel are now implicitly the SIP INVITE Dialog usage and the associated Control channel are
linked. If either party wishes to terminate a Control channel it now implicitly linked. If either party wishes to terminate a Control
simply issues a SIP termination request (for example a SIP BYE channel it simply issues a SIP termination request (for example a SIP
request, or appropriate response in an early dialog). The Control BYE request, or appropriate response in an early SIP INVITE dialog
Channel therefore lives for the duration of the SIP dialog. usage). The Control Channel therefore lives for the duration of the
SIP INVITE dialog usage.
A UAS receiving a SIP OPTIONS request MUST respond appropriately as A UAS receiving a SIP OPTIONS request MUST respond appropriately as
defined in [RFC3261]. The UAS MUST include the media types supported defined in [RFC3261]. The UAS MUST include the media types supported
in the SIP 200 OK response in a SIP "Accept" header to indicate the in the SIP 200 OK response in a SIP "Accept" header to indicate the
valid media types. valid media types.
5. Establishing Media Streams - Control Client SIP UAC Behavior 5. Establishing Media Streams - Control Client SIP UAC Behavior
It is intended that the Control framework will be used within a It is intended that the Control framework will be used within a
variety of architectures for a wide range of functions. One of the variety of architectures for a wide range of functions. One of the
primary functions will be the use of the control channel to apply primary functions will be the use of the control channel to apply
multiple specific Control package commands to media sessions multiple specific Control package commands to media sessions
established by SIP dialogs (media dialogs) with given a given remote established by SIP INVITE dialogs (media dialogs) with given a given
server. For example, the Control Server might send a command to remote server. For example, the Control Server might send a command
generate audio media (such as an announcement) on an RTP stream to generate audio media (such as an announcement) on an RTP stream
between a User Agent and a Media Server. between a User Agent and a Media Server.
SIP dialogs used to establish media sessions (see Figure 2) on behalf SIP INVITE dialogs used to establish media sessions (see Figure 2) on
of User Agents may contain more than one Media Description (as behalf of User Agents may contain more than one Media Description (as
defined by "m=" in the SDP). The Control Client MUST include a media defined by "m=" in the SDP). The Control Client MUST include a media
label attribute, as defined in [RFC4574], for each "m=" definition label attribute, as defined in [RFC4574], for each "m=" definition
received that is to be directed to an entity using the control received that is to be directed to an entity using the control
framework. This allows the Control Client to later explicitly direct framework. This allows the Control Client to later explicitly direct
commands on the control channel at a specific media line (m=). commands on the control channel at a specific media line (m=).
This framework identifies the referencing of such associated media This framework identifies the referencing of such associated media
dialogs as extremely important. A connection reference attribute has dialogs as extremely important. A connection reference attribute has
been specified that can optionally be imported into any Control been specified that can optionally be imported into any Control
Package. It is intended that this will reduce repetitive specifying Package. It is intended that this will reduce repetitive specifying
of dialog reference language. The schema can be found in of dialog reference language. The schema can be found in
Section 16.1 in Appendix A. Section 17.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 17.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 8. part of each Control Package definition, as detailed in Section 8.
6. Control Framework Interactions 6. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of a SIP Control Channel to be set up in either direction as a result of a SIP
INVITE transaction. SIP provides a flexible negotiation mechanism to INVITE transaction. SIP provides a flexible negotiation mechanism to
establish the control channel, but there needs to be a mechanism establish the control channel, but there needs to be a mechanism
within the control channel to correlate the control channel with the within the control channel to correlate the control channel with the
SIP dialog used for its establishment. A Control Client receiving an SIP INVITE dialog usage used for its establishment. A Control Client
incoming connection (whether it be acting in the role of UAC or UAS) receiving an incoming connection (whether it be acting in the role of
has no way of identifying the associated SIP dialog as it could be UAC or UAS) has no way of identifying the associated SIP INVITE
simply listening for all incoming connections on a specific port. dialog usage as it could be simply listening for all incoming
The following steps, which implementations MUST support, allow a connections on a specific port. The following steps, which
connecting UA that is, the UA with the 'active' role in COMEDIA, to implementations MUST support, allow a connecting UA that is, the UA
identify the associated SIP dialog that triggered the connection. with the 'active' role in COMEDIA, to identify the associated SIP
Unless there is an alternative dialog association mechanism used, the INVITE dialog usage that triggered the connection. Unless there is
UAs MUST carry out these steps before any other signaling on the an alternative dialog association mechanism used, the UAs MUST carry
newly created Control channel. out these steps before any other signaling on the newly created
Control channel.
o Once the connection has been established, the UA acting in the o Once the connection has been established, the UA acting in the
active role (active UA) to initiate the connection MUST active role (active UA) to initiate the connection MUST send a
immediately send a Control Framework SYNC request. The SYNC Control Framework SYNC request. The SYNC request MUST be
request MUST be constructed as defined in Section 9.1 and MUST constructed as defined in Section 9.1 and MUST contain the
contain the message header, 'Dialog-ID', which contains the SIP 'Dialog-ID' message header.
dialog information. o The 'Dialog-ID' message header is populated with the value of the
o The 'Dialog-ID' message header value is the value contained in the local 'cfw-id' media level attribute that was inserted by the same
'cfw-id' SDP media level attribute. This allows for a correlation client in the SDP offer/answer exchange to establish the control
between the control channel and its associated SIP dialog. channel. This allows for a correlation between the control
channel and its associated SIP INVITE dialog usage.
o On creating the SYNC request the active UA MUST follow the o On creating the SYNC request the active UA MUST follow the
procedures outlined in Section 6.3.3. This provides details of procedures outlined in Section 6.3.3. This provides details of
connection keep alive messages. connection keep alive messages.
o On creating the SYNC request the active UA MUST also follow the o On creating the SYNC request the active UA MUST also follow the
procedures outlined in Section 6.3.4.2. This provides details of procedures outlined in Section 6.3.4.2. This provides details of
the negotiation mechanism used to determine the Protocol Data the negotiation mechanism used to determine the Protocol Data
Units (PDUs) that can be exchanged on the established control Units (PDUs) that can be exchanged on the established control
channel connection. channel connection.
o The active UA MUST then send the SYNC request. It MUST then wait o The UA in the active role for the connection creation MUST then
for a period of at least 'Transaction-Timeout' to receive a send the SYNC request. If the UA in the active role for the
response. It MAY choose a longer time to wait but it MUST NOT be connection creation is a SIP UAS and has generated its SDP
shorter than 'Transaction-Timeout'. response in a 2XX class SIP response, it MUST wait for incoming
SIP ACK message before issuing the SYNC. If the UA in the active
role for the connection creation is a SIP UAS and has generated
its SDP response in a reliable 1XX class SIP response, it MUST
wait for incoming SIP PRACK message before issuing the SYNC. If
the UA in the active role for the connection creation is a SIP UAC
it MUST send the SYNC message immediately on establishment of the
control channel. It MUST then wait for a period of at least
'Transaction-Timeout' to receive a response. It MAY choose a
longer time to wait but it MUST NOT be shorter than 'Transaction-
Timeout'.
o If no response is received for the SYNC control message, a timeout o If no response is received for the SYNC control message, a timeout
occurs and the control channel is terminated along with the occurs and the control channel is terminated along with the
associated SIP dialog. The active UA MUST issue a BYE request to associated SIP INVITE dialog usage. The active UA MUST issue a
terminate the SIP dialog. BYE request to terminate the SIP INVITE dialog usage.
o If the active UA receives a 481 response from the passive UA, this o If the active UA receives a 481 response from the passive UA, this
means the SYNC request was received but the associated SIP dialog means the SYNC request was received but the associated SIP INVITE
specified in the SYNC message does not exists. The active client dialog usage specified in the SYNC message does not exists. The
MUST terminate the control channel. The active UA MUST issue a active client MUST terminate the control channel. The active UA
SIP BYE request to terminate the SIP dialog. MUST issue a SIP BYE request to terminate the SIP INVITE dialog
usage.
o All other error responses received for the SYNC request are o All other error responses received for the SYNC request are
treated as detailed in this specification and also result in the treated as detailed in this specification and also result in the
termination of the control channel and the associated SIP dialog. termination of the control channel and the associated SIP INVITE
The active UA MUST issue a BYE request to terminate the SIP dialog usage. The active UA MUST issue a BYE request to terminate
dialog. the SIP INVITE dialog usage.
o The receipt of a 200 response to a SYNC message implies that the o The receipt of a 200 response to a SYNC message implies that the
SIP dialog and control connection have been successfully SIP INVITE dialog usage and control connection have been
correlated. The control channel can now be used for further successfully correlated. The control channel can now be used for
interactions. further interactions.
SYNC messages can be sent at any point while the Control Channel is SYNC messages can be sent at any point while the Control Channel is
open from either side, once the initial exchange is complete. If open from either side, once the initial exchange is complete. If
present, the contents of the Keep-Alive and Dialog-ID headers MUST present, the contents of the Keep-Alive and Dialog-ID headers MUST
NOT change. New values of the Keep-Alive and Dialog-ID headers have NOT change. New values of the Keep-Alive and Dialog-ID headers have
no relevance as they are negotiated for the lifetime of the Media no relevance as they are negotiated for the lifetime of the Media
Control Channel Framework session. Control Channel Framework session.
Once a successful control channel has been established, as defined in Once a successful control channel has been established, as defined in
Section 4.1 and Section 4.2, and the connection has been correlated, Section 4.1 and Section 4.2, and the connection has been correlated,
skipping to change at page 18, line 37 skipping to change at page 19, line 37
202 status code in the first line of the response. Following the 202 status code in the first line of the response. Following the
initial response, the server will send one or more REPORT messages as initial response, the server will send one or more REPORT messages as
described in Section 6.3.2. A Control Package MUST explicitly define described in Section 6.3.2. A Control Package MUST explicitly define
the circumstances under which the server sends 200 and 202 messages. the circumstances under which the server sends 200 and 202 messages.
If a Control Server encounters problems with a Control Framework If a Control Server encounters problems with a Control Framework
request (like REPORT or CONTROL), an appropriate error code MUST be request (like REPORT or CONTROL), an appropriate error code MUST be
used in the response, as listed in Section 7. The generation of a used in the response, as listed in Section 7. The generation of a
non 2xx class response code to a Control Framework request (like non 2xx class response code to a Control Framework request (like
CONTROL or REPORT) will indicate failure of the transaction, and all CONTROL or REPORT) will indicate failure of the transaction, and all
associated state and resources MUST be terminated. The response code associated transaction state and resources MUST be terminated. The
may provide an explicit indication of why the transaction failed, response code may provide an explicit indication of why the
which might result in a re-submission of the request depending on the transaction failed, which might result in a re-submission of the
extension package being used. request depending on the extension package being used.
6.3. Transaction Processing 6.3. Transaction Processing
The Control Framework defines four types of requests (methods): The Control Framework defines four types of requests (methods):
CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support
sending and receiving these four methods. sending and receiving these four methods.
The following sub-sections specify each Control Framework method and The following sub-sections specify each Control Framework method and
its associated transaction processing. its associated transaction processing.
skipping to change at page 19, line 47 skipping to change at page 20, line 47
transaction. This correlates extended transactions with the original transaction. This correlates extended transactions with the original
CONTROL transaction. A REPORT message containing a payload MUST CONTROL transaction. A REPORT message containing a payload MUST
include the Content-Type and Content-Length headers indicating the include the Content-Type and Content-Length headers indicating the
payload MIME type [RFC2045] defined by the control package and the payload MIME type [RFC2045] defined by the control package and the
length of the payload, respectively. length of the payload, respectively.
6.3.2.1. Reporting the Status of Extended Transactions 6.3.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within On receiving a CONTROL message, a Control Server MUST respond within
Transaction-Timeout with a status code for the request, as specified Transaction-Timeout with a status code for the request, as specified
in Section 6.2. If the command completes within that time, a 200 in Section 6.2. If the processing of the command completes within
response code MUST be sent. If the command does not complete within that time, a 200 response code MUST be sent. If the command does not
that time, the response code 202 MUST be sent indicating that the complete within that time, the response code 202 MUST be sent
requested command is still being processed and the CONTROL indicating that the requested command is still being processed and
transaction is being extended. The REPORT method is then used to the CONTROL transaction is being extended. The REPORT method is then
update and terminate 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 contain a Timeout The Control Server should not wait until the last possible
message header. This header MUST have a value in seconds that is the opportunity to make the decision of issuing a 202 response code and
amount of time the recipient of the 202 message must wait before should ensure that is has plenty for the response to arrive at the
assuming that there has been a problem and terminating the extended Control Client. Not doing so will result in transactions being
transaction and associated state. terminated (timed out) at the Control Client before completion.
A Control Server issuing a 202 response MUST ensure the message
contains a Timeout message header. This header MUST have a value in
seconds that is the amount of time the recipient of the 202 message
must wait before assuming that there has been a problem and
terminating the extended transaction and associated state.
The initial REPORT message MUST contain a 'Seq' (Sequence) message The initial REPORT message MUST contain a 'Seq' (Sequence) message
header with a value equal to '1'. Note - the 'Seq' numbers at both header with a value equal to '1'. Note - the 'Seq' numbers at both
Control Client and Control Server for framework messages are Control Client and Control Server for framework messages are
independent. independent.
All REPORT messages for an extended CONTROL transaction MUST contain All REPORT messages for an extended CONTROL transaction MUST contain
a 'Timeout' message header. This header will contain a value in a 'Timeout' message header. This header will contain a value in
seconds that is the amount of time the recipient of the REPORT seconds that is the amount of time the recipient of the REPORT
message must wait before assuming that there has been a problem and message must wait before assuming that there has been a problem and
skipping to change at page 21, line 6 skipping to change at page 22, line 12
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 original CONTROL request being reset to the the initiator of the original CONTROL request being reset to the
interval contained in 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. It MUST also
Framework UAC can then clean up any pending state associated with the contain a 'Timeout' message header with a valid value. The inclusion
original control transaction. of the 'Timeout' header is for consistency and its value is ignored.
A Control Framework UAC can then clean up any pending state
associated with the original control transaction.
6.3.3. K-ALIVE Transactions 6.3.3. K-ALIVE Transactions
The protocol defined in this document may be used in various network The protocol defined in this document may be used in various network
architectures. This includes a wide range of deployments where the architectures. This includes a wide range of deployments where the
clients could be co-located in a secured, private domain, or spread clients could be co-located in a secured, private domain, or spread
across disparate domains that require traversal of devices such as across disparate domains that require traversal of devices such as
Network Address Translators (NAT) and Firewalls. A keep-alive Network Address Translators (NAT) and Firewalls. A keep-alive
mechanism enables the control channel to be kept active during times mechanism enables the control channel to be kept active during times
of inactivity. This is because many Firewalls have a timeout period of inactivity. This is because many Firewalls have a timeout period
after which connections are closed. This mechanism also provides the after which connections are closed. This mechanism also provides the
ability for application level failure detection. It should be noted ability for application level failure detection. It should be noted
that the following procedures apply explicitly to the control channel that the following procedures apply only to the control channel being
being created. For details relating to the SIP keep alive mechanism, created. For details relating to the SIP keep alive mechanism,
implementers should seek guidance from SIP Outbound implementers should seek guidance from SIP Outbound
[I-D.ietf-sip-outbound]. [I-D.ietf-sip-outbound].
The following keep-alive procedures MUST be implemented. Specific The following keep-alive procedures MUST be implemented. Specific
deployments MAY choose not to use the keep alive mechanism if both deployments MAY choose not to use the keep alive mechanism if both
entities are in a co-located domain. Note that choosing not to use entities are in a co-located domain. Note that choosing not to use
the keep alive mechanism defined in this section, even when in a co- the keep alive mechanism defined in this section, even when in a co-
located architecture, will reduce the ability to detect application located architecture, will reduce the ability to detect application
level errors - especially during long periods of inactivity. level errors - especially during long periods of inactivity.
Once the SIP dialog has been established and the underlying control Once the SIP INVITE dialog usage has been established and the
channel has been set-up, including the initial correlation handshake underlying control channel has been set-up, including the initial
using SYNC as discussed in Section 6, both entities acting in the correlation handshake using SYNC as discussed in Section 6, both
'active' and 'passive' roles, as defined in COMEDIA [RFC4145], MUST entities acting in the 'active' and 'passive' roles, as defined in
start a keep alive timer equal to the value negotiated during the COMEDIA [RFC4145], MUST start a keep alive timer equal to the value
control channel SYNC request/response exchange. This is the value negotiated during the control channel SYNC request/response exchange.
from the 'Keep-Alive' header in seconds. This is the value from the 'Keep-Alive' header in seconds.
6.3.3.1. Behaviour for an Entity in an Active Role 6.3.3.1. Behaviour for an Entity in an Active Role
When acting in an active role, a K-ALIVE Control Framework message When acting in an active role, a K-ALIVE Control Framework message
MUST be generated before the local keep alive timer fires. An active MUST be generated before the local keep alive timer fires. An active
entity is free to send the K-ALIVE Control Framework message whenever entity is free to send the K-ALIVE Control Framework message whenever
it chooses. It is recommended for the entity to issue a K-ALIVE it chooses. It is recommended for the entity to issue a K-ALIVE
message after 80% of the local keep-alive timer. On receiving a 200 message after 80% of the local keep-alive timer. On receiving a 200
OK Control Framework message for the K-ALIVE request, the 'active' OK Control Framework message for the K-ALIVE request, the 'active'
entity MUST reset the local keep alive timer. If no 200 OK response entity MUST reset the local keep alive timer. If no 200 OK response
is received to the K-ALIVE Control Framework message, or a transport is received to the K-ALIVE Control Framework message, or a transport
level problem is detected by some other means, before the local keep level problem is detected by some other means, before the local keep
alive timer fires, the 'active' entity MAY use COMEDIA renegotiation alive timer fires, the 'active' entity MAY use COMEDIA renegotiation
procedures to recover the connection. Otherwise, the 'active' entity procedures to recover the connection. Otherwise, the 'active' entity
MUST tear down the SIP dialog and recover the associated control MUST tear down the SIP INVITE dialog and recover the associated
channel resources. control channel resources.
6.3.3.2. Behaviour for an Entity in a Passive Role 6.3.3.2. Behaviour for an Entity in a Passive Role
When acting as a passive entity, a K-ALIVE Control Framework message When acting as a passive entity, a K-ALIVE Control Framework message
must be received before the local keep alive timer fires. When a must be received before the local keep alive timer fires. When a
K-ALIVE request is received, the 'passive' entity MUST generate a 200 K-ALIVE request is received, the 'passive' entity MUST generate a 200
OK control framework response and reset the local keep alive-timer. OK control framework response and reset the local keep alive-timer.
No other Control Framework response is valid. If no K-ALIVE message No other Control Framework response is valid. If no K-ALIVE message
is received (or a transport level problem is detected by some other is received (or a transport level problem is detected by some other
means) before the local keep alive timer fires, the 'passive' entity means) before the local keep alive timer fires, the 'passive' entity
MUST tear down the SIP dialog and recover the associated control MUST tear down the SIP INVITE dialog and recover the associated
channel resources. control channel resources.
6.3.4. SYNC Transactions 6.3.4. SYNC Transactions
The initial SYNC request on a control channel is used to negotiate The initial SYNC request on a control channel is used to negotiate
the timeout period for the control-channel keep alive mechanism and the timeout period for the control-channel keep alive mechanism and
to allow clients and servers to learn the Control Packages that each to allow clients and servers to learn the Control Packages that each
supports. Subsequent SYNC requests may be used to change the set of supports. Subsequent SYNC requests may be used to change the set of
Control Packages that can be used on the control-channel. Control Packages that can be used on the control-channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction 6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the control- The initial SYNC request allows the timeout period for the control-
channel keep alive mechanism to be negotiated. The following rules channel keep alive mechanism to be negotiated. The following rules
MUST be followed for the initial SYNC request: MUST be followed for the initial SYNC request:
o If the Client initiating the SDP Offer has a COMEDIA setup o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to active, the Keep-Alive header MUST be included attribute equal to active, the Keep-Alive header MUST be included
in the SYNC message generated by the offerer. The value of the in the SYNC message generated by the offerer. The value of the
Keep-Alive header SHOULD be in the range of 95 to 120 seconds Keep-Alive header SHOULD be in the range of 95 to 120 seconds
(this is consistent with SIP Outbound[I-D.ietf-sip-outbound]). (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]).
The value of the Keep-Alive header MUST NOT exceed 600 seconds.
The client that generated the SDP "Answer" (the passive client) The client that generated the SDP "Answer" (the passive client)
MUST copy the Keep-Alive header into the 200 response to the SYNC MUST copy the Keep-Alive header into the 200 response to the SYNC
message with the same value. message with the same value.
o If the Client initiating the SDP Offer has a COMEDIA setup o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to passive, the Keep-Alive header parameter MUST attribute equal to passive, the Keep-Alive header parameter MUST
be included in the SYNC message generated by the answerer. The be included in the SYNC message generated by the answerer. The
value of the Keep-Alive header SHOULD be in the range of 95 to 120 value of the Keep-Alive header SHOULD be in the range of 95 to 120
seconds. The client that generated the SDP Offer (the passive seconds. The client that generated the SDP Offer (the passive
client) MUST copy the Keep-Alive header into the 200 response to client) MUST copy the Keep-Alive header into the 200 response to
the SYNC message with the same value. the SYNC message with the same value.
skipping to change at page 24, line 12 skipping to change at page 25, line 24
Supported header of the response. This provides a hint to the client Supported header of the response. This provides a hint to the client
that generated the SYNC request of additional packages supported by that generated the SYNC request of additional packages supported by
the server. the server.
If no common packages are supported by the server receiving the SYNC If no common packages are supported by the server receiving the SYNC
message, it MUST respond with a 422 error response code. The error message, it MUST respond with a 422 error response code. The error
response MUST contain a Supported header indicating the packages that response MUST contain a Supported header indicating the packages that
are supported. The initiating client can then choose to either re- are supported. The initiating client can then choose to either re-
submit a new SYNC message based on the 422 response or consider the submit a new SYNC message based on the 422 response or consider the
interaction as a failure. This would lead to termination of the interaction as a failure. This would lead to termination of the
associated SIP dialog by sending a SIP BYE request, as per [RFC3261]. associated SIP INVITE dialog by sending a SIP BYE request, as per
[RFC3261].
Once the initial SYNC transaction is completed, either client MAY Once the initial SYNC transaction is completed, either client MAY
choose to send a subsequent new SYNC Control Framework message to re- choose to send a subsequent new SYNC Control Framework message to re-
negotiate the packages that are supported within the control channel. negotiate the packages that are supported within the control channel.
A new SYNC message whose Packages header has different values from A new SYNC message whose Packages header has different values from
the previous SYNC message can effectively add and delete the packages the previous SYNC message can effectively add and delete the packages
used in the control channel. If a client receiving a subsequent SYNC used in the control channel. If a client receiving a subsequent SYNC
message does not wish to change the set of packages, it MUST respond message does not wish to change the set of packages, it MUST respond
with a 421 Control Framework response code. Subsequent SYNC messages with a 421 Control Framework response code. Subsequent SYNC messages
MUST NOT change the value of the Dialog-ID and Keep-Alive Control MUST NOT change the value of the Dialog-ID and Keep-Alive Control
Framework headers that appeared in the original SYNC negotiation. Framework headers that appeared in the original SYNC negotiation.
An entity MAY honor Control Framework commands relating to a Control An entity MAY honour Control Framework commands relating to a Control
Package it no longer supports after package re-negotiation. When the Package it no longer supports after package re-negotiation. When the
entity does not wish to honor such commands, it MUST respond to the entity does not wish to honour such commands, it MUST respond to the
request with a 420 response. request with a 420 response.
7. Response Code Descriptions 7. Response Code Descriptions
The following response codes are defined for transaction responses to The following response codes are defined for transaction responses to
methods defined in Section 6.1. All response codes in this section methods defined in Section 6.1. All response codes in this section
MUST be supported and can be used in response to both CONTROL and MUST be supported and can be used in response to both CONTROL and
REPORT messages except that a 202 MUST NOT be generated in response REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message. to a REPORT message.
skipping to change at page 25, line 19 skipping to change at page 26, line 28
provided at a later time through the REPORT mechanism defined in provided at a later time through the REPORT mechanism defined in
Section 6.3.2. Section 6.3.2.
7.3. 400 Response Code 7.3. 400 Response Code
The 400 response code indicates that the request was syntactically The 400 response code indicates that the request was syntactically
incorrect. incorrect.
7.4. 403 Response Code 7.4. 403 Response Code
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfil it. The
The client should not repeat the request. client should not repeat the request.
7.5. 405 Response Code 7.5. 405 Response Code
Method not allowed. The primitive is not supported. Method not allowed. The primitive is not supported.
7.6. 420 Response Code 7.6. 420 Response Code
Intended target of the request is for a Control Package that is not Intended target of the request is for a Control Package that is not
valid for the current session. valid for the current session.
skipping to change at page 25, line 49 skipping to change at page 27, line 13
message. message.
7.9. 423 Response Code 7.9. 423 Response Code
Recipient has an existing transaction with the same transaction ID. Recipient has an existing transaction with the same transaction ID.
7.10. 481 Response Code 7.10. 481 Response Code
The 481 response indicates that the transaction of the request does The 481 response indicates that the transaction of the request does
not exist. In response to a SYNC request, it indicates that the not exist. In response to a SYNC request, it indicates that the
corresponding SIP dialog does not exist. corresponding SIP INVITE dialog usage does not exist.
7.11. 500 Response Code 7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
request request
8. Control Packages 8. Control Packages
Control Packages specify behavior that extends the capability defined Control Packages specify behavior that extends the capability defined
in this document. Control Packages MUST NOT weaken MUST and SHOULD in this document. Control Packages MUST NOT weaken MUST and SHOULD
skipping to change at page 26, line 34 skipping to change at page 27, line 44
structure but are included as a minimum to provide essential package structure but are included as a minimum to provide essential package
level information. A Control-Package can take any valid form it level information. A Control-Package can take any valid form it
wishes as long as it includes at least the following. wishes as long as it includes at least the following.
8.1. Control Package Name 8.1. Control Package Name
This section MUST be present in all extensions to this document and This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the include information that appears in the IANA registration of the
token. Information on registering control package tokens is token. Information on registering control package tokens is
contained in Section 12. The package name MUST also register a contained in Section 13. The package name MUST also register a
version number for the package which is separated with a '/' symbol version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be e.g. package_name/1.0. This enables updates to the package to be
registered where appropriate. An initial version of a package MUST registered where appropriate. An initial version of a package MUST
start with the value '1.0'. Subsequent versions MUST increment this start with the value '1.0'. Subsequent versions MUST increment this
number if the same package name is to be used. The exact increment number if the same package name is to be used. The exact increment
is left to the discretion of the package author. It is RECOMMENDED is left to the discretion of the package author. It is RECOMMENDED
that package authors make a clear statement on backwards that package authors make a clear statement on backwards
compatibility with any new version. compatibility with any new version.
8.2. Framework Message Usage 8.2. Framework Message Usage
skipping to change at page 27, line 10 skipping to change at page 28, line 20
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document MUST control channel. This section of a Control package document MUST
explicitly detail the control messages that can be used as well as explicitly detail the control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. include which role type is allowed to initiate a request type.
8.3. Common XML Support 8.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required, as attributes for media dialog or Conference reference are required, as
defined and discussed in Section 16.1 in Appendix A. The Control defined and discussed in Section 17.1 in Appendix A. The Control
Package will make strong statements (using language from RFC 2119 Package will make strong statements (using language from RFC 2119
[RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is [RFC2119]) if the XML schema defined in Section 17.1 in Appendix A is
to be supported. If only part of the schema is required (for example to be supported. If only part of the schema is required (for example
just 'connectionid' or just conferenceid), the Control Package will just 'connectionid' or just conferenceid), the Control Package will
make equally strong (using language from RFC 2119 [RFC2119]) make equally strong (using language from RFC 2119 [RFC2119])
statements. statements.
8.4. CONTROL Message Bodies 8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 6, or that no control package body is required. This section Section 6, or that no control package body is required. This section
skipping to change at page 28, line 29 skipping to change at page 29, line 39
framework document. framework document.
9. Formal Syntax 9. Formal Syntax
9.1. Control Framework Formal Syntax 9.1. Control Framework Formal Syntax
The Control Framework interactions use the UTF-8 transformation The Control Framework interactions use the UTF-8 transformation
format as defined in [RFC3629]. The syntax in this section uses the format as defined in [RFC3629]. The syntax in this section uses the
Augmented Backus-Naur Form (ABNF) as defined in [RFC5234]. Augmented Backus-Naur Form (ABNF) as defined in [RFC5234].
Unless otherwise stated in the definition of a particular header
field, field values, parameter names, and parameter values are case
in-sensitive
control-req-or-resp = control-request / control-response control-req-or-resp = control-request / control-response
control-request = control-req-start *headers CRLF [control-content] control-request = control-req-start *headers CRLF [control-content]
control-response = control-resp-start *headers CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content]
control-req-start = pCFW SP trans-id SP method CRLF control-req-start = pCFW SP trans-id SP method CRLF
control-resp-start = pCFW SP trans-id SP status-code [SP comment] CRLF control-resp-start = pCFW SP trans-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pCFW = %x43.46.57; CFW in caps pCFW = %x43.46.57; CFW in caps
trans-id = alpha-num-token trans-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNC = %x53.59.4E.43; SYNC in caps mSYNC = %x53.59.4E.43; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3*DIGIT ; any code defined in this and other documents status-code = 3*DIGIT ; any code defined in this and other documents
skipping to change at page 29, line 9 skipping to change at page 30, line 23
status-code = 3*DIGIT ; any code defined in this and other documents status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF headers = header-name CRLF
header-name = (Content-Length header-name = (Content-Length
/Content-Type /Content-Type
/Control-Package /Control-Package
/Status /Status
/Seq /Seq
/Timeout /Timeout
/Dialog-id /Dialog-ID
/Packages /Packages
/Supported /Supported
/Keep-alive /Keep-alive
/ext-header) /ext-header)
Content-Length = "Content-Length:" SP 1*DIGIT Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" ) Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-ID:" SP dialog-id-string Dialog-ID = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name) Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum) Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token dialog-id-string = alpha-num-token
package-name = alpha-num-token package-name = alpha-num-token
supprtd-alphanum = alpha-num-token supprtd-alphanum = alpha-num-token
kalive-seconds = 1*DIGIT kalive-seconds = 1*DIGIT
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
skipping to change at page 29, line 46 skipping to change at page 31, line 12
media-type = type "/" subtype *( ";" gen-param ) media-type = type "/" subtype *( ";" gen-param )
type = token type = token
subtype = token subtype = token
gen-param = pname [ "=" pval ] gen-param = pname [ "=" pval ]
pname = token pname = token
pval = token / quoted-string pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E) / %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII / UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\" BACKSLASH = "\"
UPALPHA = %x41-5A UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT ALPHANUM = ALPHA / DIGIT
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
skipping to change at page 32, line 7 skipping to change at page 33, line 30
The following examples provide an abstracted flow of Control Channel The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document. Control Framework interactions defined in this document.
In this example, the Control Client establishes a control channel, In this example, the Control Client establishes a control channel,
SYNCs with the Control Server, and issues a CONTROL request that SYNCs with the Control Server, and issues a CONTROL request that
can't be completed within the 'Transaction-Timeout', so the Control can't be completed within the 'Transaction-Timeout', so the Control
Server returns a 202 response code to extend the transaction. The Server returns a 202 response code to extend the transaction. The
Control Server then follows with REPORTs until the requested action Control Server then follows with REPORTs until the requested action
has been completed. The SIP dialog is then terminated. has been completed. The SIP INVITE dialog is then terminated.
Control Client Control Server Control Client Control Server
| | | |
| (1) SIP INVITE | | (1) SIP INVITE |
| ----------------------------------------> | | ----------------------------------------> |
| | | |
| (2) SIP 200 | | (2) SIP 200 |
| <--------------------------------------- | | <--------------------------------------- |
| | | |
| (3) SIP ACK | | (3) SIP ACK |
skipping to change at page 33, line 24 skipping to change at page 35, line 8
| 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@example.com>
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com> Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Cotent-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-client.example.com c=IN IP4 control-client.example.com
m=application 7575 TCP/CFW * m=application 7575 TCP cfw
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cfw-id:fndskuhHKsd783hjdla a=cfw-id:fndskuhHKsd783hjdla
2. Control Server->Control Client (SIP): 200 OK 2. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc2.example.com>
Content-Type: application/sdp
Content-Length: [..]
v=0 SIP/2.0 200 OK
o=originator 2890844526 2890842808 IN IP4 controller.example,com To: <sip:control-server@example.com>;tag=023983774
s=- From: <sip:control-client@example.com>;tag=8937498
c=IN IP4 control-server.example.com Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
m=application 7575 TCP/CFW * CSeq: 1 INVITE
a=setup:passive Call-ID: 893jhoeihjr8392@example.com
a=connection:new Contact: <sip:control-server@pc2.example.com>
a=cfw-id:fndskuhHKsd783hjdla Content-Type: application/sdp
Content-Length: [..]
v=0
o=responder 2890844600 2890842900 IN IP4 controller.example,com
s=-
c=IN IP4 control-server.example.com
m=application 7575 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:7JeDi23i7eiysi32
3. Control Client->Control Server (SIP): ACK 3. Control Client->Control Server (SIP): ACK
4. Control Client opens a TCP connection to the Control Server. 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): SYNC. Message): SYNC.
CFW 8djae7khauj SYNC CFW 8djae7khauj SYNC
Dialog-ID: fndskuhHKsd783hjdla Dialog-ID: fndskuhHKsd783hjdla
K-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
5. Control Server-->Control Client (Control Framework Message): 5. Control Server-->Control Client (Control Framework Message):
200. 200.
CFW 8djae7khauj 200 CFW 8djae7khauj 200
Keep-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
skipping to change at page 36, line 24 skipping to change at page 37, line 42
<XML BLOB/> <XML BLOB/>
13. Control Client-->Control Server (Control Framework Message): 13. Control Client-->Control Server (Control Framework Message):
200. 200.
CFW i387yeiqyiq 200 CFW i387yeiqyiq 200
Seq: 3 Seq: 3
14. Control Client->Control Server (SIP): BYE 14. Control Client->Control Server (SIP): BYE
BYE sip:control-client@pc2.example.com SIP/2.0 BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com> To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE CSeq: 2 BYE
Max-Forwards: 70
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Length: [..]
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:client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5
CSeq: 2 BYE CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc1.example.com>
Content-Length: [..]
11. Security Considerations 11. Extensibility
The Media Control Channel Framework was designed to be only minimally
extensible. New methods, header fields, and status codes can be
defined in standards-track RFCs. The Media Control Channel Framework
does not contain a version number or any negotiation mechanism to
require or discover new features. If an extension is specified in
the future that requires negotiation, the specification will need to
describe how the extension is to be negotiated in the encapsulating
signaling protocol. If a non-interoperable update or extension
occurs in the future, it will be treated as a new protocol, and MUST
describe how its use will be signaled.
In order to allow extension header fields without breaking
interoperability, if an Media Control Channel device receives a
request or response containing a header field that it does not
understand, it MUST ignore the header field and process the request
or response as if the header field was not present. If a Media
Control Channel device receives a request with an unknown method, it
MUST return a 500 response.
12. Security Considerations
The Channel Framework provides confidentiality and integrity for the The Channel Framework provides confidentiality and integrity for the
messages it transfers. It also provides assurances that the messages it transfers. It also provides assurances that the
connected host is the host that it meant to connect to and that the connected host is the host that it meant to connect to and that the
connection has not been hijacked. connection has not been hijacked.
The Channel Framework in design complies with the security-related The Channel Framework in design complies with the security-related
requirements documented in the control protocol requirements requirements documented in the control protocol requirements
document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12 document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12
REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by
the Channel Framework are summarized in the following subsections. the Channel Framework are summarized in the following subsections.
11.1. Session Establishment 12.1. Session Establishment
Channel Framework sessions are established as media sessions Channel Framework sessions are established as media sessions
described by SDP within the context of a SIP dialog. In order to described by SDP within the context of a SIP INVITE dialog. In order
ensure secure rendezvous between Control Framework clients and to ensure secure rendezvous between Control Framework clients and
servers, the Media Channel Control Framework should make full use of servers, the Media Channel Control Framework should make full use of
mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP
attribute results in important session information being carried attribute results in important session information being carried
across the SIP network. For this reason SIP clients using this across the SIP network. For this reason SIP clients using this
specification MUST use appropriate security mechanisms, such as specification MUST use appropriate security mechanisms, such as
TLS[RFC5246] and SMIME[RFC3851], when deployed in open networks. TLS[RFC5246] and SMIME[RFC3851], when deployed in open networks.
11.2. Transport Level Protection 12.2. Transport Level Protection
When using only TCP connections, the Channel Framework security is When using only TCP connections, the Channel Framework security is
weak. Although the Channel Framework requires the ability to protect weak. Although the Channel Framework requires the ability to protect
this exchange, there is no guarantee that the protection will be used this exchange, there is no guarantee that the protection will be used
all the time. If such protection is not used, anyone can see data all the time. If such protection is not used, anyone can see data
exchanges. exchanges.
Sensitive data, such as private and financial data, is carried over Sensitive data, such as private and financial data, is carried over
the Control Framework channel. Clients and servers must be properly the Control Framework channel. Clients and servers must be properly
authenticated/authorized and the control channel must permit the use authenticated/authorized and the control channel must permit the use
skipping to change at page 37, line 46 skipping to change at page 39, line 45
TLS is used to authenticate devices and to provide integrity, replay TLS is used to authenticate devices and to provide integrity, replay
protection and confidentiality for the header fields being protection and confidentiality for the header fields being
transported on the control channel. Channel Framework elements MUST transported on the control channel. Channel Framework elements MUST
implement TLS and MUST also implement the TLS ClientExtendedHello implement TLS and MUST also implement the TLS ClientExtendedHello
extended hello information for server name indication as described in extended hello information for server name indication as described in
[RFC5246]. A TLS cipher-suite of [RFC5246]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other
cipher-suites MAY also be supported. cipher-suites MAY also be supported.
11.3. Control Channel Policy Management 12.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control This specification permits the establishment of a dedicated control
channel using SIP. It is also permitted for entities to create channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create general solution, the ability for multiple entities to create
connections and have access to resources could be the cause of connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to this document does not specifically carry any specific mechanism to
overcome such conflicts but will provide a summary of how it can be overcome such conflicts but will provide a summary of how it can be
achieved. achieved.
skipping to change at page 38, line 32 skipping to change at page 40, line 30
that if required, an appropriate policy framework is adopted to that if required, an appropriate policy framework is adopted to
satisfy the requirements for implemented packages. The most robust satisfy the requirements for implemented packages. The most robust
form of policy can be achieved using a strong authentication form of policy can be achieved using a strong authentication
mechanism such as mutual TLS authentication on the control channel. mechanism such as mutual TLS authentication on the control channel.
This specification provide a control channel response code(403) to This specification provide a control channel response code(403) to
indicate to the issuer of a command that it is not permitted. It indicate to the issuer of a command that it is not permitted. It
should be noted that additional policy requirements to those covered should be noted that additional policy requirements to those covered
in this section might be defined and applied in individual packages in this section might be defined and applied in individual packages
that specify a finer granularity for access to resources etc. that specify a finer granularity for access to resources etc.
12. IANA Considerations 13. IANA Considerations
This specification instructs IANA to create a new registry for SIP This specification instructs IANA to create a new registry for SIP
Control Framework parameters. The Channel Framework Parameter Control Framework parameters. The Channel Framework Parameter
registry is a container for sub-registries. This section further registry is a container for sub-registries. This section further
introduces sub-registries for Channel Framework packages, method introduces sub-registries for Channel Framework packages, method
names, status codes, header field names, port and transport protocol. names, status codes, header field names, port and transport protocol.
Additionally, Section 12.6 registers new parameters in existing IANA Additionally, Section 13.6 registers a new new MIME type for use with
registries. SDP..
12.1. Control Packages Registration Information 13.1. Control Packages Registration Information
This specification establishes the Control Packages sub-registry This specification establishes the Control Packages sub-registry
under Control Framework Packages. New parameters in this sub- under Control Framework Packages. New parameters in this sub-
registry must be published in an RFC (either as an IETF submission or registry must be published in an RFC (either as an IETF submission or
RFC Editor submission), using the IANA policy [RFC5226] "RFC RFC Editor submission), using the IANA policy [RFC5226] "RFC
Required". Required".
As this document specifies no package or template-package names, the As this document specifies no package or template-package names, the
initial IANA registration for control packages will be empty. The initial IANA registration for control packages will be empty. The
remainder of the text in this section gives an example of the type of remainder of the text in this section gives an example of the type of
skipping to change at page 39, line 20 skipping to change at page 41, line 17
The table below lists the control packages defined in the "Media The table below lists the control packages defined in the "Media
Control Channel Framework". Control Channel Framework".
Package Name Contact Reference Package Name Contact Reference
------------ ------- --------- ------------ ------- ---------
example1 [contact@example.org] example1 [contact@example.org]
example2 [contact@example.org] [RFCXXXX] example2 [contact@example.org] [RFCXXXX]
example3 [RFCXXXX] example3 [RFCXXXX]
12.1.1. Control Package Registration Template 13.1.1. Control Package Registration Template
To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package
Package Name: Package Name:
(Package names must conform to the syntax described in (Package names must conform to the syntax described in
section 8.1.) section 8.1.)
Published Specification(s): Published Specification(s):
(Control packages require a published RFC.). (Control packages require a published RFC.).
Person & email address to contact for further information: Person & email address to contact for further information:
12.2. Control Framework Method Names 13.2. Control Framework Method Names
This specification establishes the Methods sub-registry under Control This specification establishes the Methods sub-registry under Control
Framework Parameters and initiates its population as follows. New Framework Parameters and initiates its population as follows. New
parameters in this sub-registry must be published in an RFC (either parameters in this sub-registry must be published in an RFC (either
as an IETF submission or RFC Editor submission). as an IETF submission or RFC Editor submission).
CONTROL - [RFCXXXX] CONTROL - [RFCXXXX]
REPORT - [RFCXXXX] REPORT - [RFCXXXX]
SYNC - [RFCXXXX] SYNC - [RFCXXXX]
K-ALIVE - [RFCXXXX]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new Control Framework method: order to register a new Control Framework method:
o The method name. o The method name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
12.3. Control Framework Status Codes 13.3. Control Framework Status Codes
This specification establishes the Status-Code sub-registry under This specification establishes the Status-Code sub-registry under
Channel Framework Parameters. New parameters in this sub-registry Channel Framework Parameters. New parameters in this sub-registry
must be published in an RFC (either as an IETF submission or RFC must be published in an RFC (either as an IETF submission or RFC
Editor submission). Its initial population is defined in Section 9. Editor submission). Its initial population is defined in Section 9.
It takes the following format: It takes the following format:
Code [RFC Number] Code [RFC Number]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new Control Framework status code: order to register a new Control Framework status code:
o The status code number. o The status code number.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
12.4. Control Framework Header Fields 13.4. Control Framework Header Fields
This specification establishes the header field-Field sub-registry This specification establishes the header field-Field sub-registry
under Channel Framework Parameters. New parameters in this sub- under Channel Framework Parameters. New parameters in this sub-
registry must be published in an RFC (either as an IETF submission or registry must be published in an RFC (either as an IETF submission or
RFC Editor submission). Its initial population is defined as RFC Editor submission). Its initial population is defined as
follows: follows:
Control-Package - [RFCXXXX] Control-Package - [RFCXXXX]
Status - [RFCXXXX] Status - [RFCXXXX]
Seq - [RFCXXXX] Seq - [RFCXXXX]
Timeout - [RFCXXXX] Timeout - [RFCXXXX]
Dialog-id - [RFCXXXX] Dialog-ID - [RFCXXXX]
Packages - [RFCXXXX] Packages - [RFCXXXX]
Supported - [RFCXXXX] Supported - [RFCXXXX]
Keep-Alive - [RFCXXXX] Keep-Alive - [RFCXXXX]
Content-Type - [RFCXXXX] Content-Type - [RFCXXXX]
Content-Length - [RFCXXXX] Content-Length - [RFCXXXX]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new Channel Framework header field: order to register a new Channel Framework header field:
o The header field name. o The header field name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
12.5. Control Framework Port 13.5. Control Framework Port
The Control Framework uses TCP port XXXX, from the "registered" port The Control Framework uses TCP port XXXX, from the "registered" port
range. Usage of this value is described in Section 4.1. range. Usage of this value is described in Section 4.1.
12.6. SDP Transport Protocol 13.6. Media Type Registration
The Channel Framework defines the new SDP protocol field values 'TCP/ This section describes the media types and names associated with this
CFW', 'TCP/TLS/CFW', 'SCTP/CFW' and 'SCTP/TLS/CFW", which should be payload format. The registration uses the templates defined in
registered in the sdp-parameters registry under "proto". The values [RFC4288]. It follows [RFC4855].
have the following meaning:
o TCP/CFW: Indicates the SIP Channel Framework when TCP is used as 13.6.1. Registration of MIME Media Type application/cfw
an underlying transport for the control channel.
o TCP/TLS/CFW: Indicates the Channel Framework when TLS over TCP is
used as an underlying transport for the control channel.
o SCTP/CFW: Indicates the Channel Framework when SCTP is used as an
underlying transport for the control channel.
o SCTP/TLS/CFW: Indicates the Channel Framework when TLS over SCTP
is used as an underlying transport for the control channel.
Specifications defining new protocol values must define the rules for MIME media type name: application
the associated media format namespace. The 'TCP/CFW', 'TCP/TLS/CFW',
'SCTP/CFW' and 'SCTP/TLS/CFW' protocol values allow only one value in
the format field (fmt), which is a single occurrence of "*". Actual
format determination is made using the control package extension
specific payloads.
12.7. 'cfw-id' SDP Attribute MIME subtype name: cfw
Required parameters: None
Optional parameters: None
Encoding considerations: See section 4 of RFC XXXX
Security considerations: See Section 12 of RFC XXXX.
Interoperability considerations:
Endpoint compliant to this specification must
use this MIME type. Receivers who cannot support
this specification will reject using appropriate
protocol mechanism.
Published specification: RFC XXXX
Applications that use this media type:
Media Control Channel compliant applications.
Additional information: None
Person and email address to contact for further information:
Chris Boulton: chris@ns-technologies.com
Intended usage: COMMON
Restrictions on usage:
Should be used only in conjunction with this specification,
RFC XXXX.
Author: Chris Boulton
Change controller:
IETF MediaCtrl working group, delegated from the IESG.
13.7. 'cfw-id' SDP Attribute
Contact name: Chris Boulton chris@ns-technologies.com. Contact name: Chris Boulton chris@ns-technologies.com.
Attribute name: "cfw-id". Attribute name: "cfw-id".
Type of attribute Media level. Type of attribute Media level.
Subject to charset: Not. Subject to charset: Not.
Purpose of attribute: The 'cfw-id' attribute indicates Purpose of attribute: The 'cfw-id' attribute indicates
an identifier that can be used to correlate the control an identifier that can be used to correlate the control
channel with the SIP dialog used to negotiate it, when channel with the SIP INVITE dialog used to negotiate it,
the attribute value is used within the control channel. when the attribute value is used within the control
channel.
Allowed attribute values: A token. Allowed attribute values: A token.
12.8. URN Sub-Namespace for 13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes urn:ietf:params:xml:ns:control:framework-attributes
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:control:framework-attributes", per the "urn:ietf:params:xml:ns:control:framework-attributes", per the
guidelines in RFC 3688 [RFC3688]. guidelines in RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group, Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
skipping to change at page 42, line 36 skipping to change at page 46, line 29
<body> <body>
<h1>Namespace for Media Control Channel attributes</h1> <h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2> <h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification. with the RFC number for this specification.
<p>See RFCXXXX</p> <p>See RFCXXXX</p>
</body> </body>
</html> </html>
END END
12.9. XML Schema Registration 13.9. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688]. 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group, Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 16 of this document. Section 16 of this document.
12.10. MIME Media Type Registration for 'application/ 13.10. MIME Media Type Registration for 'application/
framework-attributes+xml' framework-attributes+xml'
This section registers the "application/framework-attributes+xml" This section registers the "application/framework-attributes+xml"
MIME type. MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type Subject: Registration of MIME media type
application/framework-attributes+xml application/framework-attributes+xml
MIME media type name: application MIME media type name: application
MIME subtype name: framework-attributes+xml MIME subtype name: framework-attributes+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: Same as charset parameter application/xml as
Indicates the character encoding of enclosed XML. Default is specified in RFC 3023.
UTF-8. Encoding considerations: Same as encoding considerations of
Encoding considerations: Uses XML, which can employ 8-bit application/xml as specified in RFC 3023.
characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2.
Security considerations: No known security considerations outside Security considerations: No known security considerations outside
of those provided by core Media Control Channel Framework. of those provided by core Media Control Channel Framework.
Interoperability considerations: This content type provides common Interoperability considerations: This content type provides common
constructs for related Media Control Channel packages. constructs for related Media Control Channel packages.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Implementations of Applications which use this media type: Implementations of
appropriate Media Control Channel packages. appropriate Media Control Channel packages.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): (none)
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Chris Person & email address to contact for further information: Chris
Boulton <chris@ns-technologies.com> Boulton <chris@ns-technologies.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: None. Other information: None.
13. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
13.1. Changes from 09 Version 14.1. Changes from 10 Version
o Remove To: and Subject from IANA reg section.
o Added K-ALIVE message to section 12.2.
o Correct K-Alive header to Keep-Alive in examples.
o Fixed multiple SIP call flow nits.
o Reworded sentence relating to 'cfw-id'.
o Clarify text about issuing 202 response.
o Removed .xml from MIME template.
o Added extensibility section.
o Changed ~ to a : for connectionid.
o Add text to formal syntax specifying case in-sensitive unless
otherwise defined.
o Added upper bound for value of Keep-Alive header of 600 seconds.
o SDP Review: Alligned terminology with RFC 5057.
o SDP Review: cfw-id is now unique per endpoint in offer/answer and
the local value is inderted in the CFW Dialog-Id header - for SIP
forking pusposes.
o As per issue:1 from the mailing list, alterted SDP format and
included new MIME type for application/cfw - as per SDP review.
14.2. Changes from 09 Version
o Editorial fixes for strict idnits checking: RFC status, syntax, o Editorial fixes for strict idnits checking: RFC status, syntax,
references, line length. references, line length.
13.2. Changes from 08 Version 14.3. Changes from 08 Version
o Altered definition of 'Transaction-Timeout'. o Altered definition of 'Transaction-Timeout'.
o Removed 'random' reference in preference for globally unique. o Removed 'random' reference in preference for globally unique.
o Clarified passive entity behavior on Keep-Alive timeout. o Clarified passive entity behavior on Keep-Alive timeout.
o Input of Chair comments for final publication. o Input of Chair comments for final publication.
o Removed extra CRLF in ABNF after 'headers'. o Removed extra CRLF in ABNF after 'headers'.
o Clarified 481 behavior. o Clarified 481 behavior.
o Removed definition for extended transaction lifetime o Removed definition for extended transaction lifetime
13.3. Changes from 07 Version 14.4. Changes from 07 Version
o Added '*' to SDP 'm=' line in examples. o Added '*' to SDP 'm=' line in examples.
13.4. Changes from 06 Version 14.5. Changes from 06 Version
o Added 202 Timeout entry to table. o Added 202 Timeout entry to table.
o Fixed some general nits and language. o Fixed some general nits and language.
o Fixed ABNF to be 'control-content = *OCTET'. o Fixed ABNF to be 'control-content = *OCTET'.
o Added general qualifier to sections 6.3.3.1 and 6.3.3.2 so that o Added general qualifier to sections 6.3.3.1 and 6.3.3.2 so that
rules for either tearing down or reconnecting are applied. rules for either tearing down or reconnecting are applied.
13.5. Changes from 05 Version 14.6. Changes from 05 Version
o Reworded 'must' used in Introduction. o Reworded 'must' used in Introduction.
o Added urn namespace definition in IANA section. o Added urn namespace definition in IANA section.
o Added XML schema registration in IANA section. o Added XML schema registration in IANA section.
o Added MIME registration in IANA section. o Added MIME registration in IANA section.
13.6. Changes from 04 Version 14.7. Changes from 04 Version
o Fixed nits as reported by Brian Weis. o Fixed nits as reported by Brian Weis.
o Amended Security text as per secdir review. o Amended Security text as per secdir review.
o Removed optional 'label' part of dialog identifier as per interim o Removed optional 'label' part of dialog identifier as per interim
call. call.
o Added clarifying text at the beginning of section 4 to help o Added clarifying text at the beginning of section 4 to help
describe what the section is about. describe what the section is about.
o Added text at the beginning of section 8 clarifying that the o Added text at the beginning of section 8 clarifying that the
template is not the basis for packages BUT only needs to be template is not the basis for packages BUT only needs to be
included as part of a Control Package. included as part of a Control Package.
13.7. Changes from 03 Version 14.8. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
13.8. Changes from 02 Version 14.9. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
o Fixed broken IANA subsections ordering + naming. o Fixed broken IANA subsections ordering + naming.
13.9. Changes from 01 Version 14.10. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
13.10. Changes from 00 Version 14.11. Changes from 00 Version
o Aligned tokens to be 'CFW' (removed ESCS). o Aligned tokens to be 'CFW' (removed ESCS).
o Content-Length not mandatory for messages with no payload. o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions. o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others. o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF. o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific. o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response. o Added '423' duplicate transaction ID response.
o Added '405' method not allowed. o Added '405' method not allowed.
o Added IANA section. o Added IANA section.
skipping to change at page 46, line 4 skipping to change at page 50, line 18
o Content-Length not mandatory for messages with no payload. o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions. o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others. o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF. o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific. o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response. o Added '423' duplicate transaction ID response.
o Added '405' method not allowed. o Added '405' method not allowed.
o Added IANA section. o Added IANA section.
o Added Security Considerations section (used MSRP and MRCPv2 as a o Added Security Considerations section (used MSRP and MRCPv2 as a
template). template).
o Removed noisy initial REPORT message - *Lorenzo please check o Removed noisy initial REPORT message - *Lorenzo please check
text*. text*.
o Fixed ABNF - PLEASE CHECK. o Fixed ABNF - PLEASE CHECK.
o Removed separate event mechanism and now all tied to CONTROL o Removed separate event mechanism and now all tied to CONTROL
transaction (extended). transaction (extended).
o General scrub of text. o General scrub of text.
o Organised 'Editors Notes' for discussion on the mailing list. o Organised 'Editors Notes' for discussion on the mailing list.
o Fixed ABNF in relation to extra CRLF on Content-Type. o Fixed ABNF in relation to extra CRLF on Content-Type.
14. Contributors 15. Contributors
Asher Shiratzky from Radvision provided valuable support and Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document. contributions to the early versions of this document.
15. Acknowledgments 16. Acknowledgments
The authors would like to thank Ian Evans of Avaya and Michael The authors would like to thank Ian Evans of Avaya, Michael
Bardzinski of NS-Technologies, Adnan Saleem of Radisys, and Dave Bardzinski and John Dally of NS-Technologies, Adnan Saleem of
Morgan for useful review and input to this work. Eric Burger Radisys, and Dave Morgan for useful review and input to this work.
contributed to the early phases of this work. Eric Burger contributed to the early phases of this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work. has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and Ben Campbell carried out the RAI expert review on this draft and
provided a great deal of invaluable input. Brian Weis carried out a provided a great deal of invaluable input. Brian Weis carried out a
thorough security review. Text from Eric Burger was used in the thorough security review. Jonathan Lennox carried out a thorough SDP
introduction in the explanation for using SIP. review which provided some excellent modifications. Text from Eric
Burger was used in the introduction in the explanation for using SIP.
16. Appendix: Common Package Components 17. Appendix: Common Package Components
During the creation of the Control Framework it has become clear that During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages. initial 'Utilities Document' that can be used by Control Packages.
16.1. Common Dialog/Multiparty Reference Schema 17.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing The following schema provides some common attributes for allowing
Control Packages to apply specific commands to a particular SIP media Control Packages to apply specific commands to a particular SIP media
dialog (also referred to as Connection) or conference. If used dialog (also referred to as Connection) or conference. If used
within a Control Package the Connection and multiparty attributes within a Control Package the Connection and multiparty attributes
will be imported and used appropriately to specifically identify will be imported and used appropriately to specifically identify
either a SIP dialog or a conference instance. If used within a either a SIP dialog or a conference instance. If used within a
package, the value contained in the 'connectionid' attribute MUST be package, the value contained in the 'connectionid' attribute MUST be
constructed by concatenating the 'Local' and 'Remote' SIP dialog constructed by concatenating the 'Local' and 'Remote' SIP dialog
identifier tags as defined in [RFC3261]. They MUST then be separated identifier tags as defined in [RFC3261]. They MUST then be separated
using the '~' character. So the format would be: using the ':' character. So the format would be:
'Local Dialog tag' + '~' + 'Remote Dialog tag' 'Local Dialog tag' + ':' + 'Remote Dialog tag'
As an example, for an entity that has a SIP Local dialog identifier As an example, for an entity that has a SIP Local dialog identifier
of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the
'connectionid' attribute for a Control Framework command would be: 'connectionid' attribute for a Control Framework command would be:
7HDY839~HJKSkyHS 7HDY839:HJKSkyHS
It should be noted that Control Framework requests initiated in It should be noted that Control Framework requests initiated in
conjunction with a SIP dialog will produce a different 'connectionid' conjunction with a SIP dialog will produce a different 'connectionid'
value depending on the directionality of the request, for example value depending on the directionality of the request, for example
Local and Remote tags are locally identifiable. Local and Remote tags are locally identifiable.
As with the Connection attribute previously defined, it is also As with the Connection attribute previously defined, it is also
useful to have the ability to apply specific control framework useful to have the ability to apply specific control framework
commands to a number of related dialogs, such as a multiparty call. commands to a number of related dialogs, such as a multiparty call.
This typically consists of a number of media dialogs that are This typically consists of a number of media dialogs that are
logically bound by a single identifier. The following schema allows logically bound by a single identifier. The following schema allows
for control framework commands to explicitly reference such a for control framework commands to explicitly reference such a
grouping through a 'conf' XML container. If used by a Control grouping through a 'conferenceid' XML container. If used by a
Package, any control XML referenced by the attribute applies to all Control Package, any control XML referenced by the attribute applies
related media dialogs. Unlike the dialog attribute, the to all related media dialogs. Unlike the dialog attribute, the
'conferenceid' attribute does not need to be constructed based on the 'conferenceid' attribute does not need to be constructed based on the
overlying SIP dialog. The 'conferenceid' attribute value is system overlying SIP dialog. The 'conferenceid' attribute value is system
specific and should be selected with relevant context and uniqueness. specific and should be selected with relevant context and uniqueness.
It should be noted that the values contained in both the
'connectionid' and 'conferenceid' identifiers MUST be compared case-
sensitive.
The full schema follows: The full schema follows:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema <xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="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">
skipping to change at page 48, line 27 skipping to change at page 52, line 33
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/> <xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/> <xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup> </xsd:attributeGroup>
</xsd:schema> </xsd:schema>
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 49, line 9 skipping to change at page 53, line 17
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
17.2. Informative References 18.2. Informative References
[I-D.burger-mscl-thoughts] [I-D.burger-mscl-thoughts]
Burger, E., "Media Server Control Language and Protocol Burger, E., "Media Server Control Language and Protocol
Thoughts", draft-burger-mscl-thoughts-01 (work in Thoughts", draft-burger-mscl-thoughts-01 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C., "Managing Client Initiated Connections in
Connections in the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress), draft-ietf-sip-outbound-20 (work in progress), June 2009.
October 2008.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
skipping to change at page 50, line 46 skipping to change at page 55, line 22
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rain Willow Communications
Email: tim.melanchuk@gmail.com Email: tim.melanchuk@gmail.com
Scott McGlashan Scott McGlashan
Hewlett-Packard Hewlett-Packard
Gustav III:s boulevard 36 Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com Email: smcg.stds01@mcglashan.org
 End of changes. 136 change blocks. 
405 lines changed or deleted 532 lines changed or added

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