< draft-ietf-mediactrl-sip-control-framework-11.txt   draft-ietf-mediactrl-sip-control-framework-12.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: April 26, 2010 Rain Willow Communications Expires: March 7, 2011 Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
October 23, 2009 September 3, 2010
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-11 draft-ietf-mediactrl-sip-control-framework-12
Abstract
This document describes a framework and protocol for application
deployment where the application programming logic and media
processing are distributed. This implies that application
programming logic can seamlessly gain access to appropriate resources
that are not co-located on the same physical network entity. The
framework uses the Session Initiation Protocol (SIP) to establish an
application-level control mechanism between application servers and
associated external servers such as media servers.
The motivation for the creation of this framework is to provide an
interface suitable to meet the requirements of a centralized
conference system, where the conference system can be distributed, as
defined by the XCON Work Group in the IETF. It is not, however,
limited to this scope.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 7, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a Framework and protocol for application described in the Simplified BSD License.
deployment where the application programming logic and media
processing are distributed. This implies that application
programming logic can seamlessly gain access to appropriate resources
that are not co-located on the same physical network entity. The
framework uses the Session Initiation Protocol (SIP) to establish an
application-level control mechanism between application servers and
associated external servers such as media servers.
The motivation for the creation of this Framework is to provide an
interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the IETF. It is not,
however, limited to this scope and it is envisioned that this generic
Framework will be used for a wide variety of de-coupled control
architectures between network entities.
Table of Contents 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 . . . . . . . . . . . . . 14 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 14
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
skipping to change at page 3, line 29 skipping to change at page 2, line 41
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 20 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 20
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 20 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 20
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 22 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 22
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 23 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 23
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 25 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 25
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 26 7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 26
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 27
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 27 7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 27
7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 27
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 27 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Control Package Name . . . . . . . . . . . . . . . . . . 27 8.1. Control Package Name . . . . . . . . . . . . . . . . . . 27
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 28 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 27
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 28 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 28
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 28 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 28
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 28 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 28
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 29 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 29
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 32 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 32
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 38 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12.1. Session Establishment . . . . . . . . . . . . . . . . . . 39 12.1. Session Establishment . . . . . . . . . . . . . . . . . . 38
12.2. Transport Level Protection . . . . . . . . . . . . . . . 39 12.2. Transport Level Protection . . . . . . . . . . . . . . . 38
12.3. Control Channel Policy Management . . . . . . . . . . . . 39 12.3. Control Channel Policy Management . . . . . . . . . . . . 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
13.1. Control Packages Registration Information . . . . . . . . 40 13.1. Control Packages Registration Information . . . . . . . . 40
13.1.1. Control Package Registration Template . . . . . . . . 41 13.1.1. Control Package Registration Template . . . . . . . . 41
13.2. Control Framework Method Names . . . . . . . . . . . . . 41 13.2. Control Framework Method Names . . . . . . . . . . . . . 41
13.3. Control Framework Status Codes . . . . . . . . . . . . . 42 13.3. Control Framework Status Codes . . . . . . . . . . . . . 42
13.4. Control Framework Header Fields . . . . . . . . . . . . . 42 13.4. Control Framework Header Fields . . . . . . . . . . . . . 42
13.5. Control Framework Port . . . . . . . . . . . . . . . . . 42 13.5. Control Framework Port . . . . . . . . . . . . . . . . . 43
13.6. Media Type Registration . . . . . . . . . . . . . . . . . 43 13.6. Media Type Registration . . . . . . . . . . . . . . . . . 43
13.6.1. Registration of MIME Media Type application/cfw . . . 44 13.6.1. Registration of MIME Media Type application/cfw . . . 44
13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 45 13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 45
13.8. URN Sub-Namespace for 13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 45 urn:ietf:params:xml:ns:control:framework-attributes . . . 45
13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 46 13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 46
13.10. MIME Media Type Registration for 13.10. MIME Media Type Registration for
'application/framework-attributes+xml' . . . . . . . . . 46 'application/framework-attributes+xml' . . . . . . . . . 46
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Changes from 10 Version . . . . . . . . . . . . . . . . . 47 14.1. Changes from 11 Version . . . . . . . . . . . . . . . . . 47
14.2. Changes from 09 Version . . . . . . . . . . . . . . . . . 48 14.2. Changes from 10 Version . . . . . . . . . . . . . . . . . 47
14.3. Changes from 08 Version . . . . . . . . . . . . . . . . . 48 14.3. Changes from 09 Version . . . . . . . . . . . . . . . . . 48
14.4. Changes from 07 Version . . . . . . . . . . . . . . . . . 48 14.4. Changes from 08 Version . . . . . . . . . . . . . . . . . 48
14.5. Changes from 06 Version . . . . . . . . . . . . . . . . . 48 14.5. Changes from 07 Version . . . . . . . . . . . . . . . . . 48
14.6. Changes from 05 Version . . . . . . . . . . . . . . . . . 48 14.6. Changes from 06 Version . . . . . . . . . . . . . . . . . 48
14.7. Changes from 04 Version . . . . . . . . . . . . . . . . . 48 14.7. Changes from 05 Version . . . . . . . . . . . . . . . . . 48
14.8. Changes from 03 Version . . . . . . . . . . . . . . . . . 49 14.8. Changes from 04 Version . . . . . . . . . . . . . . . . . 49
14.9. Changes from 02 Version . . . . . . . . . . . . . . . . . 49 14.9. Changes from 03 Version . . . . . . . . . . . . . . . . . 49
14.10. Changes from 01 Version . . . . . . . . . . . . . . . . . 49 14.10. Changes from 02 Version . . . . . . . . . . . . . . . . . 49
14.11. Changes from 00 Version . . . . . . . . . . . . . . . . . 50 14.11. Changes from 01 Version . . . . . . . . . . . . . . . . . 49
14.12. Changes from 00 Version . . . . . . . . . . . . . . . . . 50
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
17. Appendix: Common Package Components . . . . . . . . . . . . . 51 17. Appendix: Common Package Components . . . . . . . . . . . . . 51
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 51 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 51
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
18.1. Normative References . . . . . . . . . . . . . . . . . . 52 18.1. Normative References . . . . . . . . . . . . . . . . . . 52
18.2. Informative References . . . . . . . . . . . . . . . . . 54 18.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
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 5, line 46 skipping to change at page 5, line 46
megaco. megaco.
SIP [RFC3261] provides the ideal rendezvous mechanism for SIP [RFC3261] provides the ideal rendezvous mechanism for
establishing and maintaining control connections to external server establishing and maintaining control connections to external server
components. The control connections can then be used to exchange components. The control connections can then be used to exchange
explicit command/response interactions that allow for media control explicit command/response interactions that allow for media control
and associated command response results. and associated command response results.
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In document are to be interpreted as described in BCP 14, [RFC2119], as
addition, BCP 15 indicates requirement levels for compliant scoped to those conformance targets.
implementations.
The following additional terms are defined for use in this document: The following additional terms are defined for use in this document:
User Agent Client (UAC): As specified in [RFC3261]. User Agent Client (UAC): As specified in [RFC3261].
User Agent Server (UAS): As specified in [RFC3261]. User Agent Server (UAS): As specified in [RFC3261].
B2BUA: A B2BUA is a Back-to-Back SIP User Agent. B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
Control Server: A Control Server is an entity that performs a Control Server: A Control Server is an entity that performs a
service, such as media processing, on behalf of a Control Client. service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing; announcement; tone For example, a media server offers mixing; announcement; tone
detection and generation; and play and record services. The detection and generation; and play and record services. The
Control Server has a direct RTP [RFC3550] relationship with the Control Server has a direct Real-Time Transport Protocol (RTP)
source or sink of the media flow. In this document, we often [RFC3550] relationship with the source or sink of the media flow.
refer to the Control Server simply as "the Server". In this document, we often refer to the Control Server simply as
"the Server".
Control Client: A Control Client is an entity that requests Control Client: A Control Client is an entity that requests
processing from a Control Server. Note that the Control Client processing from a Control Server. Note that the Control Client
might not have any processing capabilities whatsoever. For might not have any processing capabilities whatsoever. For
example, the Control Client may be an Application Server (B2BUA) example, the Control Client may be an Application Server (B2BUA)
or other endpoint requesting manipulation of a third-party's media or other endpoint requesting manipulation of a third-party's media
stream, that terminates on a media server acting in the role of a stream, that terminates on a media server acting in the role of a
Control Server. In this document, we often refer to the Control Control Server. In this document, we often refer to the Control
Client simply as "the Client". Client simply as "the Client".
Control Channel: A Control Channel is a reliable connection between Control Channel: A Control Channel is a reliable connection between
a Client and Server that is used to exchange Framework messages. a Client and Server that is used to exchange Framework messages.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE. are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.
Control Command: A Control Command is an application level request Control Command: A Control Command is an application level request
from a Client to a Server. Control Commands are carried in the from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in body of CONTROL messages. Control Commands are defined in
separate specifications known as "Control Packages". separate specifications known as "Control Packages".
Framework Transaction: A Framework Transaction is defined as a Framework Transaction: A Framework Transaction is defined as a
sequence composed of a control framework message originated by sequence composed of a control framework message originated by
either a Control Client or Control Server and responded to with a either a Control Client or Control Server and responded to with a
control Framework response code message. Note that the control control Framework response code message. Note that the control
framework has no "provisional" responses. A control framework framework has no "provisional" responses. A control framework
transaction MUST complete within 5 seconds and is referenced transaction is referenced throughout the draft as 'Transaction-
throughout the draft as 'Transaction-Timeout'. Timeout'.
Transaction-Timeout: The maximum allowed time between a Control Transaction-Timeout: The maximum allowed time between a Control
Client or Server issuing a framework message and receiving a Client or Server issuing a framework message and is arriving at
corresponding response. The value for 'Transaction-Timeout' is 5 the destination. The value for 'Transaction-Timeout' is 10
seconds. seconds.
3. Overview 3. Overview
This document details mechanisms for establishing, using, and This document details mechanisms for establishing, using, and
terminating a reliable transport connection channel using SIP and the terminating a reliable transport connection channel using SIP and the
Session Description Protocol offer/answer [RFC3264] exchange. The Session Description Protocol offer/answer [RFC3264] exchange. The
established connection is then used for controlling an external established connection is then used for controlling an external
server. The following text provides a non-normative overview of the server. The following text provides a non-normative overview of the
mechanisms used. Detailed, normative guidelines are provided later mechanisms used. Detailed, normative guidelines are provided later
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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 Session
includes the required information for control channel negotiation and Description Protocol (SDP) payload includes the required information
is the primary mechanism for conveying support for this for control channel negotiation and is the primary mechanism for
specification. The application/cfw MIME type is defined in this conveying support for this specification. The application/cfw MIME
document to convey the appropriate SDP format for compliance to this type is defined in this document to convey the appropriate SDP format
specification. The COMEDIA [RFC4145] specification for setting up for compliance to this specification. The COMEDIA [RFC4145]
and maintaining reliable connections is used as part of the specification for setting up and maintaining reliable connections is
negotiation mechanism (more detail available in later sections). The used as part of the negotiation mechanism (more detail available in
Client also includes the 'cfw-id' SDP attribute, as defined in this later sections). The Client also includes the 'cfw-id' SDP
specification, which is a unique identifier used to correlate the attribute, as defined in this specification, which is a unique
underlying Media Control Channel with the offer/answer exchange. 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=z9hG4bK72d Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
Call-ID: 7823987HJHG6 Call-ID: 7823987HJHG6
Max-Forwards: 70 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 49153 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 and mechanism generates a 200 OK response containing appropriate SDP and
formatted using the application/cfw MIME type specified in this formatted using the application/cfw MIME type specified in this
document. The Server inserts its own unique 'cfw-id' SDP attribute document. The Server inserts its own unique 'cfw-id' SDP attribute
which differs from the one received in the INVITE (offer). which differs from the one received in the INVITE (offer).
skipping to change at page 10, line 34 skipping to change at page 10, line 34
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 (3PCC)
[RFC3725].
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 INVITE dialog usage and dedicated control channel represents the SIP INVITE dialog usage and dedicated control channel
previously described in this overview section. previously described in this overview section.
+--------Control SIP Dialog(1)---------+ +--------Control SIP Dialog(1)---------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
skipping to change at page 11, line 26 skipping to change at page 11, line 26
+--+--+ | | +--+--+ | |
|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 INVITE The link (2) from Figure 2 represents the User Agent SIP INVITE
dialog usage interactions and associated media flow. A User Agent dialog usage interactions and associated media flow. A User Agent
creates a SIP INVITE dialog usage with the Control Client entity. creates a SIP INVITE dialog usage with the Control Client entity.
The Control Client entity then creates a to the Control Server, using The Control Client entity then creates a SIP INVITE dialog usage to
B2BUA type functionality. Using the interaction illustrated by (2), the Control Server, using B2BUA type functionality. Using the
the Control Client negotiates media capabilities with the Control interaction illustrated by (2), the Control Client negotiates media
Server, on behalf of the User Agent, using SIP Third Party Call capabilities with the Control Server, on behalf of the User Agent,
Control [RFC3725]. using SIP Third Party Call Control (3PCC) [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 SIP INVITE dialog usage. 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] but MAY choose an offer- Description Protocol defined in [RFC4566] but MAY choose an offer-
less INVITE as per [RFC3261]. The SDP should be formatted in less INVITE as per [RFC3261]. The SDP SHOULD be formatted in
accordance with the steps below which is registered in this document accordance with the steps below which is registered in this document
as MIME type application/cfw in Section 13. The following as MIME type application/cfw in Section 13. The following
information defines the composition of specific elements of the SDP information defines the composition of specific elements of the SDP
payload the offerer MUST adhere to when used in a SIP based offer/ 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 answer exchange using SDP and the application/cfw MIME type. The SDP
being constructed MUST contain only a single occurrence of a control being constructed MUST contain only a single occurrence of a control
channel definition outlined in this specification. channel definition outlined in this specification but can contain
other media lines if required.
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
skipping to change at page 12, line 37 skipping to change at page 12, line 38
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> <fmt> 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.
details. If the constructing client can't receive incoming If entity constructing the SDP can't receive incoming connections it
connections it MUST still enter a valid port entry. The use of the must still enter a valid port entry. The use of the port value '0'
port value '0' has the same meaning as defined in a SIP Offer/Answer 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 a default port defined
recommended port defined in Section 13.5. This value is not a in Section 13.5. This value is default although a client is free to
default as a client is free to choose explicit port numbers. choose explicit port numbers. However, SDP SHOULD use the default
However, SDP SHOULD use the registered port number, unless local port number, unless local policy prohibits its use. Using the
policy prohibits its use. Using the registered port number allows default port number allows network administrators to manage firewall
network administrators to manage firewall policy for Control policy for Control Framework interactions. The third sub-field,
Framework interactions. The third sub-field, <proto>, MUST equal a <proto>, compliant to this specification, MUST support the values
standard transport value. All implementations compliant to this "TCP" and "TCP/TLS". Implementations MUST support TLS as a
specification MUST support the values "TCP" and "TCP/TLS". transport-level security mechanism for the control channel, although
Implementations MUST support TLS as a transport-level security use of TLS in specific deployments is optional. Control Framework
mechanism for the control channel, although use of TLS in specific implementations MUST support TCP as a transport protocol. When an
deployments is optional. Control Framework implementations MUST entity identifies a transport value but is not willing to establish
support TCP as a transport protocol. When an entity identifies a the session, it MUST respond using the appropriate SIP mechanism.
transport value but is not willing to establish the session, it MUST The <fmt> sub-field MUST contain the value "cfw".
respond using the appropriate SIP mechanism. The <fmt> sub-field
MUST contain the value "cfw".
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.
It is RECOMMENDED that a Controlling UAC initiate a connection to an It is RECOMMENDED that a Controlling UAC initiate a connection to an
external Server but that an external Server MAY negotiate and external Server but that an external Server MAY negotiate and
initiate a connection using COMEDIA, if network topology prohibits initiate a connection using COMEDIA, if network topology prohibits
initiating connections in a certain direction. An example of the initiating connections in a certain direction. An example of the
COMEDIA attributes is: COMEDIA attributes is:
skipping to change at page 13, line 35 skipping to change at page 13, line 34
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 INVITE dialog usage and be sent to the appropriate location. The SIP INVITE dialog usage and
appropriate 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 INVITE dialog usage. to correlate the control channel with this SIP INVITE dialog usage.
The 'cfw-id' attribute MUST be globally unique over space and time The 'cfw-id' attribute MUST be unique in the context of the
(using an appropriate algorithm) and MUST NOT clash with instances of interaction between the UAC and UAS and MUST NOT clash with instances
the 'cfw-id' used in other SIP offer/answer exchanges. The value of the 'cfw-id' used in other SIP offer/answer exchanges. The value
chosen for the 'cfw-id' attribute MUST be used for the entire chosen for the 'cfw-id' attribute MUST be used for the entire
duration of the associated SIP INVITE dialog usage and not be changed duration of the associated SIP INVITE dialog usage and not be changed
during updates to the offer/answer exchange. This applies during updates to the offer/answer exchange. This applies
specifically to the 'connection' attribute as defined in [RFC4145]. specifically to the 'connection' attribute as defined in [RFC4145].
If a SIP UAC wants to change some other parts of the SDP but reuse If a SIP UAC wants to change some other parts of the SDP but reuse
the already established connection it MUST use the value of the already established connection it uses the value of 'existing' in
'existing' in the 'connection' attribute (for example, a=connection: the 'connection' attribute (for example, a=connection:existing). If
existing). If it has noted that a connection has failed and wants to it has noted that a connection has failed and wants to re-establish
re-establish the connection, it MUST use the value of 'new' in the the connection, it uses the value of 'new' in the 'connection'
'connection' attribute (for example, a=connection:new). Throughout attribute (for example, a=connection:new). Throughout this the
this the connection identifier specified in the 'cfw-id' SDP connection identifier specified in the 'cfw-id' SDP parameter MUST
parameter MUST NOT change. One is simply negotiating the underlying NOT change. One is simply negotiating the underlying TCP connection
TCP connection between endpoints but always using the same Control between endpoints but always using the same Control Framework
Framework session, which is 1:1 for the lifetime of the SIP INVITE session, which is 1:1 for the lifetime of the SIP INVITE dialog
dialog usage. usage.
A non-2xx class final SIP response (3xx, 4xx, 5xx and 6xx) received A non-2xx class final SIP response (3xx, 4xx, 5xx and 6xx) received
for the INVITE request indicates that no SIP INVITE dialog usage has for the INVITE request indicates that no SIP INVITE dialog usage has
been created and is treated as specified by SIP [RFC3261]. been created and is treated as specified by SIP [RFC3261].
Specifically, support of this specification is negotiated through the Specifically, support of this specification is negotiated through the
presence of the media type defined in this specification. The presence of the media type defined in this specification. The
receipt of a SIP error response such as "488" indicates that the receipt of a SIP error response such as "488" indicates that the
offer contained in a request is not acceptable. The inclusion of the offer contained in a request is not acceptable. The inclusion of the
media line associated with this specification in such a rejected media line associated with this specification in such a rejected
offer indicates to the client generating the offer that this could be offer indicates to the client generating the offer that this could be
due to the receiving client not supporting this specification. The due to the receiving client not supporting this specification. The
client generating the offer MUST act as it would normally on client generating the offer MUST act as it would normally on
receiving this response, as per [RFC3261]. Media streams can also be receiving this response, as per [RFC3261]. Media streams can also be
rejected by setting the port to "0" in the "m=" line of the session rejected by setting the port to "0" in the "m=" line of the session
description. A client using this specification MUST be prepared to description, as defined in [RFC3264]. A client using this
receive an answer where the "m=" line it inserted for using the specification MUST be prepared to receive an answer where the "m="
Control Framework has been set to "0". In this situation the client line it inserted for using the Control Framework has been set to "0".
will act as it would for any other media type with a port set to "0". In this situation the client will act as it would for any other media
type with a port set to "0".
4.2. Control Server SIP UAS Behavior 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 application/cfw MIME type in the SDP. If the SIP UAS support for the application/cfw MIME type in the SDP. If the SIP UAS
wishes to construct a reliable response that conveys support for the wishes to construct a reliable response that conveys support for the
extension, it MUST follow the mechanisms defined in [RFC3261]. If extension, it MUST follow the mechanisms defined in [RFC3261]. If
support is conveyed in a reliable SIP provisional response, the support is conveyed in a reliable SIP provisional response, the
mechanisms in [RFC3262] MUST also be used. It should be noted that mechanisms in [RFC3262] MUST also be used. It should be noted that
the SDP offer is not restricted to the initial INVITE request and may the SDP offer is not restricted to the initial INVITE request and MAY
appear in any series of messages that are compliant to [RFC3261], appear in any series of messages that are compliant to [RFC3261],
[RFC3262], [RFC3311] and [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 be globally attribute as defined in Section 9.2. This attribute MUST be unique
unique over space and time (using an appropriate algorithm) and MUST in the context of the interaction between the UAC and UAS and MUST
NOT clash with instances of the 'cfw-id' used in other SIP offer/ 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' 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 value received in the offer as it is used to uniquely identify and
distinguish between multiple endpoint generating SDP answers. The distinguish between multiple endpoint generating SDP answers. The
value chosen for the 'cfw-id' attribute MUST be used for the entire 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 duration of the associated SIP INVITE dialog usage and not be changed
during updates to the offer/answer exchange. 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
skipping to change at page 15, line 40 skipping to change at page 15, line 40
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 INVITE dialogs (media dialogs) with given a given established by SIP INVITE dialogs (media dialogs) with a given remote
remote server. For example, the Control Server might send a command server. For example, the Control Server might send a command to
to generate audio media (such as an announcement) on an RTP stream 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 INVITE dialogs used to establish media sessions (see Figure 2) on SIP INVITE dialogs used to establish media sessions (see Figure 2) on
behalf 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
skipping to change at page 17, line 24 skipping to change at page 17, line 24
send the SYNC request. If the UA in the active role for the send the SYNC request. If the UA in the active role for the
connection creation is a SIP UAS and has generated its SDP connection creation is a SIP UAS and has generated its SDP
response in a 2XX class SIP response, it MUST wait for incoming 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 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 role for the connection creation is a SIP UAS and has generated
its SDP response in a reliable 1XX class SIP response, it MUST its SDP response in a reliable 1XX class SIP response, it MUST
wait for incoming SIP PRACK message before issuing the SYNC. If 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 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 it MUST send the SYNC message immediately on establishment of the
control channel. It MUST then wait for a period of at least control channel. It MUST then wait for a period of at least
'Transaction-Timeout' to receive a response. It MAY choose a 2*'Transaction-Timeout' to receive a response. It MAY choose a
longer time to wait but it MUST NOT be shorter than 'Transaction- longer time to wait but it MUST NOT be shorter than 'Transaction-
Timeout'. Timeout'. In general, a control framework transaction MUST
complete within 20 (2*Transaction-Timeout) seconds and is
referenced throughout the draft as '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 INVITE dialog usage. The active UA MUST issue a associated SIP INVITE dialog usage. The active UA MUST issue a
BYE request to terminate the SIP INVITE dialog usage. 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 INVITE means the SYNC request was received but the associated SIP INVITE
dialog usage specified in the SYNC message does not exists. The dialog usage specified in the SYNC message does not exists. The
active client MUST terminate the control channel. The active UA active client MUST terminate the control channel. The active UA
MUST issue a SIP BYE request to terminate the SIP INVITE dialog MUST issue a SIP BYE request to terminate the SIP INVITE dialog
usage. usage.
skipping to change at page 18, line 27 skipping to change at page 18, line 29
Section 9. Note that either entity can act as a control client Section 9. Note that either entity can act as a control client
depending on individual package requirements. Control Commands MUST depending on individual package requirements. Control Commands MUST
also adhere to the syntax defined by the Control Packages negotiated also adhere to the syntax defined by the Control Packages negotiated
in Section 4.1 and Section 4.2 of this document. A Control Client in Section 4.1 and Section 4.2 of this document. A Control Client
MUST create a unique control message transaction and associated MUST create a unique control message transaction and associated
identifier for insertion in the request. The transaction identifier identifier for insertion in the request. The transaction identifier
is then included in the first line of a control framework message is then included in the first line of a control framework message
along with the method type, as defined in the ABNF in Section 9. The along with the method type, as defined in the ABNF in Section 9. The
first line starts with the "CFW" token for the purpose of easily first line starts with the "CFW" token for the purpose of easily
extracting the transaction identifier. The transaction identifier extracting the transaction identifier. The transaction identifier
MUST be globally unique over space and time (using an appropriate MUST be unique in the context of the interaction between the control
algorithm). This unique property helps in the avoidance of clashes client and control server. This unique property helps in the
when multiple client entities could be creating transactions to be avoidance of clashes when multiple client entities could be creating
carried out on a single receiving server. All required mandatory and transactions to be carried out on a single receiving server. All
optional control framework headers are then inserted into the control required, mandatory, and optional control framework headers are then
message with appropriate values (see relevant individual header inserted into the control message with appropriate values (see
information for explicit detail). A "Control-Package" header MUST relevant individual header information for explicit detail). A
also be inserted with the value indicating the Control Package to "Control-Package" header MUST also be inserted with the value
which this specific request applies. Multiple packages can be indicating the Control Package to which this specific request
negotiated per control channel using the SYNC control message applies. Multiple packages can be negotiated per control channel
discussed in Section 6.3.4.2. using the SYNC control message discussed in Section 6.3.4.2.
Any framework message that contains an associated payload MUST also Any framework message that contains an associated payload MUST also
include a 'Content-Type' and 'Content-Length' message header which is include a 'Content-Type' and 'Content-Length' message header which is
the size of the message body in decimal number of octets. The the size of the message body represented as a whole decimal number of
'Content-Type' header is the MIME type of the payload specified by octets. The 'Content-Type' header is the MIME type of the payload
the individual control framework packages. If no associated payload specified by the individual control framework packages. If no
is to be added to the message, the 'Content-Length' header MUST have associated payload is to be added to the message, the 'Content-
a value of '0'. Length' header MUST have a value of '0'.
A Server receiving a framework message request MUST respond with an A Server receiving a framework message request MUST respond with an
appropriate response (as defined in Section 6.2). Control Clients appropriate response (as defined in Section 6.2). Control Clients
MUST wait for a minimum of 'Transaction-Timeout' for a response MUST wait for a minimum of 2*'Transaction-Timeout' for a response
before considering the transaction a failure and tidying state before considering the transaction a failure and tidying state
appropriately depending on the extension package being used. appropriately depending on the extension package being used.
6.2. General Behaviour for Constructing Responses 6.2. General Behaviour for Constructing Responses
An entity acting as a Control Server, on receiving a request, MUST An entity acting as a Control Server, on receiving a request, MUST
generate a response within the 'Transaction-Time', as measured from generate a response within the 'Transaction-Time', as measured from
the Control Client. The response MUST conform to the ABNF defined in the Control Client. The response MUST conform to the ABNF defined in
Section 9. The first line of the response MUST contain the Section 9. The first line of the response MUST contain the
transaction identifier used in first line of the request, as defined transaction identifier used in first line of the request, as defined
skipping to change at page 21, line 14 skipping to change at page 21, line 14
The Control Server should not wait until the last possible The Control Server should not wait until the last possible
opportunity to make the decision of issuing a 202 response code and opportunity to make the decision of issuing a 202 response code and
should ensure that is has plenty for the response to arrive at the should ensure that is has plenty for the response to arrive at the
Control Client. Not doing so will result in transactions being Control Client. Not doing so will result in transactions being
terminated (timed out) at the Control Client before completion. terminated (timed out) at the Control Client before completion.
A Control Server issuing a 202 response MUST ensure the message A Control Server issuing a 202 response MUST ensure the message
contains a Timeout message header. This header MUST have a value in 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 seconds that is the amount of time the recipient of the 202 message
must wait before assuming that there has been a problem and MUST wait before assuming that there has been a problem and
terminating the extended transaction and associated state. 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
terminating the extended transaction and associated state. On terminating the extended transaction and associated state. On
receiving a REPORT message with a 'Status' header of 'update', the receiving a REPORT message with a 'Status' header of 'update', the
Control Client MUST reset the timer for the associated extended Control Client MUST reset the timer for the associated extended
CONTROL transaction to the indicated timeout period. If the timeout CONTROL transaction to the indicated timeout period. If the timeout
period approaches with no intended REPORT messages being generated, period approaches with no intended REPORT messages being generated,
the entity acting as a Control Framework UAS for the interaction MUST the entity acting as a Control Framework UAS for the interaction MUST
generate a REPORT message containing, as defined in this paragraph, a generate a REPORT message containing, as defined in this paragraph, a
'Status' header of 'update' with no associated payload. Such a 'Status' header of 'update' with no associated payload. Such a
message acts as a timeout refresh and in no way impacts the extended message acts as a timeout refresh and in no way impacts the extended
transaction, because no message body or semantics are permitted. It transaction, because no message body or semantics are permitted. It
is RECOMMENDED that a minimum value of 10 and a maximum value of 15 is RECOMMENDED that a minimum value of 10 and a maximum value of 15
seconds be used for the value of the 'Timeout' message header. It is seconds be used for the value of the 'Timeout' message header. It is
also RECOMMENDED that a Control Server refresh the timeout period of also RECOMMENDED that a Control Server refresh the timeout period of
the CONTROL transaction at an interval that is not too close to the the CONTROL transaction at an interval that is not too close to the
expiry time. A value of 80% of the timeout period could be used. expiry time. A value of 80% of the timeout period could be used.
For example, if the timeout period is 10 seconds, the Server would For example, if the timeout period is 10 seconds, the Server would
refresh the transaction after 8 seconds. refresh the transaction after 8 seconds.
Subsequent REPORT messages that provide additional information Subsequent REPORT messages that provide additional information
relating to the extended CONTROL transaction MUST also include and relating to the extended CONTROL transaction MUST also include and
increment by 1 the 'Seq' header value. They MUST also include a increment by 1 the 'Seq' header value. A REPORT message received
'Status' header with a value of 'update'. These REPORT messages sent that has not been incremented by 1 MUST be responded to with a 406
to update the extended CONTROL transaction status MAY contain a response and consider the extended transaction terminated. On
message body, as defined by individual Control Packages and specified receiving a 406 response the extended transaction MUST be terminated.
in Section 9.5. A REPORT message sent updating the extended REPORT messages MUST also include a 'Status' header with a value of
transaction also acts as a timeout refresh, as described earlier in 'update'. These REPORT messages sent to update the extended CONTROL
this section. This will result in a transaction timeout period at transaction status MAY contain a message body, as defined by
the initiator of the original CONTROL request being reset to the individual Control Packages and specified in Section 9.5. A REPORT
interval contained in the 'Timeout' message header. message sent updating the extended transaction also acts as a timeout
refresh, as described earlier in this section. This will result in a
transaction timeout period at the initiator of the original CONTROL
request being reset to the interval contained in the 'Timeout'
message header.
When all processing for an extended CONTROL transaction has taken 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. It MUST also a value of 'terminate' and MAY contain a message body. It MUST also
contain a 'Timeout' message header with a valid value. The inclusion contain a 'Timeout' message header with a valid value. The inclusion
of the 'Timeout' header is for consistency and its value is ignored. of the 'Timeout' header is for consistency and its value is ignored.
A Control Framework UAC can then clean up any pending state A Control Framework UAC can then clean up any pending state
skipping to change at page 22, line 31 skipping to change at page 22, line 35
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 only to the control channel being that the following procedures apply only to the control channel 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 [RFC5626].
[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 INVITE dialog usage has been established and the Once the SIP INVITE dialog usage has been established and the
underlying control channel has been set-up, including the initial underlying control channel has been set-up, including the initial
skipping to change at page 23, line 10 skipping to change at page 23, line 10
entities acting in the 'active' and 'passive' roles, as defined in entities acting in the 'active' and 'passive' roles, as defined in
COMEDIA [RFC4145], MUST start a keep alive timer equal to the value COMEDIA [RFC4145], MUST start a keep alive timer equal to the value
negotiated during the control channel SYNC request/response exchange. negotiated during the control channel SYNC request/response exchange.
This is the value 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 INVITE dialog and recover the associated MUST tear down the SIP INVITE dialog and recover the associated
control channel resources. control channel resources.
skipping to change at page 23, line 38 skipping to change at page 23, line 38
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 INVITE dialog and recover the associated MUST tear down the SIP INVITE dialog and recover the associated
control 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[RFC5626]). The value of the
The value of the Keep-Alive header MUST NOT exceed 600 seconds. Keep-Alive header MUST NOT exceed 600 seconds. The client that
The client that generated the SDP "Answer" (the passive client) generated the SDP "Answer" (the passive client) MUST copy the
MUST copy the Keep-Alive header into the 200 response to the SYNC Keep-Alive header into the 200 response to the SYNC message with
message with the same value. 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.
o If the Client initiating the SDP Offer has a COMEDIA setup o If the Client initiating the SDP Offer has a COMEDIA setup
attribute equal to actpass, the Keep-Alive header parameter MUST attribute equal to actpass, the Keep-Alive header parameter MUST
be included in the SYNC message of the entity who is the active be included in the SYNC message of the entity who is the active
skipping to change at page 26, line 29 skipping to change at page 26, line 29
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 fulfil it. The The server understood the request, but is refusing to fulfil it. 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. 406 Response Code
Message out of sequence.
7.7. 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.
7.7. 421 Response Code 7.8. 421 Response Code
Recipient does not wish to re-negotiate Control Packages at this Recipient does not wish to re-negotiate Control Packages at this
moment in time. moment in time.
7.8. 422 Response Code 7.9. 422 Response Code
Recipient does not support any Control Packages listed in the SYNC Recipient does not support any Control Packages listed in the SYNC
message. message.
7.9. 423 Response Code 7.10. 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.11. 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 INVITE dialog usage does not exist. corresponding SIP INVITE dialog usage does not exist.
7.11. 500 Response Code 7.12. 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
strength statements in this document. A Control Package MAY strength statements in this document. A Control Package MAY
strengthen "SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified strengthen "SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified
by the specific usage of the framework. by the specific usage of the framework.
In addition to the usual sections expected in a standards-track RFC In addition to the usual sections expected in a standards-track RFC
and SIP extension documents, authors of Control Packages need to and SIP extension documents, authors of Control Packages need to
address each of the issues detailed in the following subsections. address each of the issues detailed in the following subsections.
The following sections MUST be used as a template and included The following sections MUST be used as a template and included
appropriately in all Control-Packages. To reiterate, the following appropriately in all Control-Packages specifications. To reiterate,
sections do not solely form the basis of all Control-Package the following sections do not solely form the basis of all Control-
structure but are included as a minimum to provide essential package Package specification but are included as a minimum to provide
level information. A Control-Package can take any valid form it essential package level information. A Control-Package specification
wishes as long as it includes at least the following. can take any valid form it wishes as long as it includes at least the
following information listed in this section.
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 13. The package name MUST also register a contained in Section 13.
version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be
registered where appropriate. An initial version of a package MUST
start with the value '1.0'. Subsequent versions MUST increment this
number if the same package name is to be used. The exact increment
is left to the discretion of the package author. It is RECOMMENDED
that package authors make a clear statement on backwards
compatibility with any new version.
8.2. Framework Message Usage 8.2. Framework Message Usage
The Control Framework defines a number of message primitives that can The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no be used to exchange commands and information. There are no
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document 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.
skipping to change at page 29, line 11 skipping to change at page 29, line 4
this document). An entity that is prepared to receive a payload type this document). An entity that is prepared to receive a payload type
in a REPORT message MUST also be prepared to receive the same payload in a REPORT message MUST also be prepared to receive the same payload
in a 200 response to a CONTROL message. For Control Packages that do in a 200 response to a CONTROL message. For Control Packages that do
not have a control package body, stating such satisfies the MUST not have a control package body, stating such satisfies the MUST
strength of this section in the Control Package document. strength of this section in the Control Package document.
8.6. Audit 8.6. Audit
Auditing of various control package properties such as capabilities Auditing of various control package properties such as capabilities
and resources (meta package level information) is extremely useful. and resources (meta package level information) is extremely useful.
Such meta-data usually has no direct impact on control framework Such meta-data usually has no direct impact on control framework
interactions but allows for contextual information to be learnt. interactions but allows for contextual information to be learnt.
Control Packages are encouraged to make use of Control Framework Control Packages are encouraged to make use of Control Framework
interactions to provide relevant package audit information. interactions to provide relevant package audit information.
This section should include information including: This section SHOULD include information including:
o If an auditing capability is available in this package. o If an auditing capability is available in this package.
o How auditing information is triggered (for example, using Control o How auditing information is triggered (for example, using Control
framework CONTROL message) and delivered (for example in a Control framework CONTROL message) and delivered (for example in a Control
Framework 200 response). Framework 200 response).
o The location of the audit query and response format for the o The location of the audit query and response format for the
payload (for example, it could be a separate XML schema OR part of payload (for example, it could be a separate XML schema OR part of
a larger XML schema). a larger XML schema).
8.7. Examples 8.7. Examples
It is strongly recommended that Control Packages provide a range of It is strongly RECOMMENDED that Control Packages provide a range of
message flows that represent common flows using the package and this message flows that represent common flows using the package and this
framework document. framework document.
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] including
types 'DIGIT', 'CRLF', 'ALPHA', .
Unless otherwise stated in the definition of a particular header Unless otherwise stated in the definition of a particular header
field, field values, parameter names, and parameter values are case field, field values, parameter names, and parameter values are case
in-sensitive 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 CRLF
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
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
skipping to change at page 30, line 50 skipping to change at page 30, line 42
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
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/" alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"
control-content = *OCTET control-content = *OCTET
Content-Type = "Content-Type:" SP media-type Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param ) media-type = type "/" subtype *(SP ";" gen-param )
type = token type = token ;section 4.2 of RFC 4288
subtype = token subtype = token ;section 4.2 of RFC 4288
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)
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
skipping to change at page 31, line 30 skipping to change at page 31, line 22
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
hname = ALPHA *token hname = ALPHA *token
hval = utf8text hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UPALPHA = %x41-5A UPALPHA = %x41-5A
UTF8-NONASCII = %xC0-DF UTF8-CONT UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4; From RFC 3629
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
The following table details a summary of the headers that can be The following table details a summary of the headers that can be
contained in Control Framework interactions. The "where" columns contained in Control Framework interactions. The "where" columns
details where headers can be used: details where headers can be used:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
Blank indicates the header field may appear in either requests or Blank indicates the header field may appear in either requests or
skipping to change at page 35, line 14 skipping to change at page 34, line 30
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 client.example.com;branch=z9hG4bK123 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 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
Content-Length: [..] Content-Length: 206
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 49153 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 SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc2.example.com> Contact: <sip:control-server@pc2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [..] Content-Length: 203
v=0 v=0
o=responder 2890844600 2890842900 IN IP4 controller.example,com o=responder 2890844600 2890842900 IN IP4 controller.example.com
s=- s=-
c=IN IP4 control-server.example.com c=IN IP4 control-server.example.com
m=application 7575 TCP cfw m=application 49153 TCP cfw
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=cfw-id:7JeDi23i7eiysi32 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.
skipping to change at page 37, line 50 skipping to change at page 37, line 32
14. Control Client->Control Server (SIP): BYE 14. Control Client->Control Server (SIP): BYE
BYE sip:control-server@pc2.example.com SIP/2.0 BYE sip:control-server@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498 From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
CSeq: 2 BYE CSeq: 2 BYE
Max-Forwards: 70 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-Length: [..] Content-Length: 0
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:client@example.com>;tag=8937498 From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5 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> Contact: <sip:control-server@pc1.example.com>
Content-Length: [..] Content-Length: 0
11. Extensibility 11. Extensibility
The Media Control Channel Framework was designed to be only minimally The Media Control Channel Framework was designed to be only minimally
extensible. New methods, header fields, and status codes can be extensible. New methods, header fields, and status codes can be
defined in standards-track RFCs. The Media Control Channel Framework defined in standards-track RFCs. The Media Control Channel Framework
does not contain a version number or any negotiation mechanism to does not contain a version number or any negotiation mechanism to
require or discover new features. If an extension is specified in require or discover new features. If an extension is specified in
the future that requires negotiation, the specification will need to the future that requires negotiation, the specification will need to
describe how the extension is to be negotiated in the encapsulating describe how the extension is to be negotiated in the encapsulating
skipping to change at page 38, line 41 skipping to change at page 38, line 24
understand, it MUST ignore the header field and process the request understand, it MUST ignore the header field and process the request
or response as if the header field was not present. If a Media or response as if the header field was not present. If a Media
Control Channel device receives a request with an unknown method, it Control Channel device receives a request with an unknown method, it
MUST return a 500 response. MUST return a 500 response.
12. Security Considerations 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, as discussed in the remainder of
this section.
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.
12.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 INVITE dialog. In order described by SDP within the context of a SIP INVITE dialog. In order
to 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[RFC5751], when deployed in open networks.
12.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
of confidentiality, replay protection and integrity for the data. To of confidentiality, replay protection and integrity for the data. To
ensure control channel protection, Control Framework clients and ensure control channel protection, Control Framework clients and
servers MUST support TLS and SHOULD use it by default unless servers MUST support TLS and SHOULD use it by default unless
alternative control channel protection is used or a protected alternative control channel protection is used or a protected
environment is guaranteed by the administrator of the network. environment is guaranteed by the administrator of the network.
Alternative control channel protection MAY be used if desired Alternative control channel protection MAY be used if desired
(e.g.IPsec). (e.g.IPsec[RFC5246]).
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.
When a TLS client establishes a connection with a server, it is
presented with the server's X.509 certificate. Authentication
proceeds as described in Section 7.3 ("Client behavior") of RFC 5922
[RFC5922].
A TLS server conformant to this specification MUST ask for a client
certificate; if the client possesses a certificate, it will be
presented to the server for mutual authentication, and authentication
proceeds as described in Section 7.4 ("Server behavior") of RFC 5922
[RFC5922].
12.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
skipping to change at page 40, line 11 skipping to change at page 40, line 4
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.
It can be determined that access to resources and use of control It can be determined that access to resources and use of control
channels relates to policy. It can be considered implementation and channels relates to policy. It can be considered implementation and
deployment detail that dictates the level of policy that is adopted. deployment detail that dictates the level of policy that is adopted.
The authorization and associated policy of a control channel can be The authorization and associated policy of a control channel can be
linked to the authentication mechanisms described in this section. linked to the authentication mechanisms described in this section.
For example, strictly authenticating a control channel either using For example, strictly authenticating a control channel using TLS
SIP digest or TLS authentication allows entities to protect resources authentication allows entities to protect resources and ensure the
and ensure the required level of granularity. Such policy can be required level of granularity. Such policy can be applied at the
applied at the package level or even as low as a structure like a package level or even as low as a structure like a conference
conference instance (control channel X is not permitted to issue instance (control channel X is not permitted to issue commands for
commands for control package y OR control channel A is not permitted control package y OR control channel A is not permitted to issue
to issue commands for conference instance B). Systems should ensure commands for conference instance B). Systems should ensure that if
that if required, an appropriate policy framework is adopted to required, an appropriate policy framework is adopted to satisfy the
satisfy the requirements for implemented packages. The most robust requirements for implemented packages. The most robust form of
form of policy can be achieved using a strong authentication policy can be achieved using a strong authentication mechanism such
mechanism such as mutual TLS authentication on the control channel. as mutual TLS authentication on the control channel. This
This specification provide a control channel response code(403) to 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. The
should be noted that additional policy requirements to those covered 403 response MUST be issued to control framework requests that are
in this section might be defined and applied in individual packages not permitted under the implemented policy. If a 403 response is
that specify a finer granularity for access to resources etc. received a control framework client MAY choose to re-submit the
request with differing requirements or the request is abandoned. The
403 response does not provide any additional information on the
policy failure due to the generic nature of this specification.
Individual control packages can supply additional information if
required. The mechanism for providing such additional information is
not mandated in this specification. It should be noted that
additional policy requirements to those covered in this section might
be defined and applied in individual packages that specify a finer
granularity for access to resources etc.
13. 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 13.6 registers a new new MIME type for use with Additionally, Section 13.6 registers a new new MIME type for use with
skipping to change at page 41, line 11 skipping to change at page 41, line 14
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
information to be maintained by the IANA; it also demonstrates all information to be maintained by the IANA; it also demonstrates all
three possible permutations of package type, contact, and reference. three possible permutations of package type, contact, and reference.
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 Reference
------------ ------- --------- ------------ ---------
example1 [contact@example.org] example1 [RFCXXXX]
example2 [contact@example.org] [RFCXXXX]
example3 [RFCXXXX]
13.1.1. Control Package Registration Template 13.1.1. Control Package Registration Template
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):
skipping to change at page 42, line 13 skipping to change at page 42, line 13
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
13.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] Description
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.
o A brief desciption of the status code.
13.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 Independent submission). Its initial population is
follows: defined as 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]
skipping to change at page 44, line 15 skipping to change at page 44, line 15
13.6.1. Registration of MIME Media Type application/cfw 13.6.1. Registration of MIME Media Type application/cfw
MIME media type name: application MIME media type name: application
MIME subtype name: cfw MIME subtype name: cfw
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: See section 4 of RFC XXXX Encoding considerations: Binary and see section 4 of RFC XXXX
Security considerations: See Section 12 of RFC XXXX. Security considerations: See Section 12 of RFC XXXX.
Interoperability considerations: Interoperability considerations:
Endpoint compliant to this specification must Endpoint compliant to this specification must
use this MIME type. Receivers who cannot support use this MIME type. Receivers who cannot support
this specification will reject using appropriate this specification will reject using appropriate
protocol mechanism. protocol mechanism.
Published specification: RFC XXXX Published specification: RFC XXXX
Applications that use this media type: Applications that use this media type:
Media Control Channel compliant applications. Media Control Channel compliant applications.
Additional information: None Additional Information: Magic Number(s): (none)
File extension(s): (none)
Macintosh File Type Code(s): (none)
Person and email address to contact for further information: Person and email address to contact for further information:
Chris Boulton: chris@ns-technologies.com Chris Boulton: chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
Should be used only in conjunction with this specification, Should be used only in conjunction with this specification,
skipping to change at page 47, line 5 skipping to change at page 47, line 5
(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.
13.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: Same as charset parameter application/xml as Optional parameters: Same as charset parameter of application/xml as
specified in RFC 3023. specified in RFC 3023.
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023. application/xml as specified in RFC 3023.
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): (none) 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.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 10 Version 14.1. Changes from 11 Version
o Addresses 'nits', 'comments' and 'DISCUSS' from IESG review.
14.2. Changes from 10 Version
o Remove To: and Subject from IANA reg section. o Remove To: and Subject from IANA reg section.
o Added K-ALIVE message to section 12.2. o Added K-ALIVE message to section 12.2.
o Correct K-Alive header to Keep-Alive in examples. o Correct K-Alive header to Keep-Alive in examples.
o Fixed multiple SIP call flow nits. o Fixed multiple SIP call flow nits.
o Reworded sentence relating to 'cfw-id'. o Reworded sentence relating to 'cfw-id'.
o Clarify text about issuing 202 response. o Clarify text about issuing 202 response.
o Removed .xml from MIME template. o Removed .xml from MIME template.
o Added extensibility section. o Added extensibility section.
o Changed ~ to a : for connectionid. o Changed ~ to a : for connectionid.
o Add text to formal syntax specifying case in-sensitive unless o Add text to formal syntax specifying case in-sensitive unless
otherwise defined. otherwise defined.
o Added upper bound for value of Keep-Alive header of 600 seconds. o Added upper bound for value of Keep-Alive header of 600 seconds.
o SDP Review: Alligned terminology with RFC 5057. o SDP Review: Alligned terminology with RFC 5057.
o SDP Review: cfw-id is now unique per endpoint in offer/answer and 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 the local value is inderted in the CFW Dialog-Id header - for SIP
forking pusposes. forking pusposes.
o As per issue:1 from the mailing list, alterted SDP format and o As per issue:1 from the mailing list, alterted SDP format and
included new MIME type for application/cfw - as per SDP review. included new MIME type for application/cfw - as per SDP review.
14.2. Changes from 09 Version 14.3. 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.
14.3. Changes from 08 Version 14.4. 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
14.4. Changes from 07 Version 14.5. Changes from 07 Version
o Added '*' to SDP 'm=' line in examples. o Added '*' to SDP 'm=' line in examples.
14.5. Changes from 06 Version 14.6. 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.
14.6. Changes from 05 Version 14.7. 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.
14.7. Changes from 04 Version 14.8. 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.
14.8. Changes from 03 Version 14.9. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
14.9. Changes from 02 Version 14.10. 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.
14.10. Changes from 01 Version 14.11. 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.
skipping to change at page 49, line 47 skipping to change at page 50, line 4
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
14.11. Changes from 00 Version 14.12. 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 53, line 26 skipping to change at page 53, line 31
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. 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
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. 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.
skipping to change at page 54, line 8 skipping to change at page 54, line 8
[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.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
18.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]
Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009.
[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
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
skipping to change at page 55, line 5 skipping to change at page 54, line 49
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
RFC 5125, February 2008. RFC 5125, February 2008.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rain Willow Communications
 End of changes. 104 change blocks. 
300 lines changed or deleted 330 lines changed or added

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