draft-ietf-mediactrl-sip-control-framework-02.txt   draft-ietf-mediactrl-sip-control-framework-03.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft Avaya
Expires: October 27, 2008 T. Melanchuk Expires: January 15, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
April 25, 2008 July 14, 2008
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-02 draft-ietf-mediactrl-sip-control-framework-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2008. This Internet-Draft will expire on January 15, 2009.
Abstract Abstract
This document describes a Framework and protocol for application This document describes a Framework and protocol for application
deployment where the application logic and processing are deployment where the application programming logic and processing are
distributed. The framework uses the Session Initiation Protocol distributed. This implies that application programming logic can
(SIP) to establish an application-level control mechanism between seamlessly gain access to appropriate resources that are not co-
application servers and associated external servers such as media located on the same physical network entity. The framework uses the
servers. 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 The motivation for the creation of this Framework is to provide an
interface suitable to meet the requirements of a distributed, interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the IETF. It is not, centralized conference system, as defined by the IETF. It is not,
however, limited to this scope and it is envisioned that this generic however, limited to this scope and it is envisioned that this generic
Framework will be used for a wide variety of de-coupled control Framework will be used for a wide variety of de-coupled control
architectures between network entities. architectures between network entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 12 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 14 6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 15 6.1. General Behaviour for Constructing Requests . . . . . . . 16
6.2. General Behaviour for Constructing Responses . . . . . . . 16 6.2. General Behaviour for Constructing Responses . . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 17 6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 17 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 18 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 18
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 19 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 20
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 21 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 21
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 23 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 23 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 25
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 24 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 25 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 25
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 25 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 25 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 26
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 25 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 26
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 25 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 26
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 26 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 27
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 29 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 30
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 35 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
11.2. Transport Level Protection . . . . . . . . . . . . . . . . 35 11.2. Transport Level Protection . . . . . . . . . . . . . . . . 36
11.3. Control Channel Policy Management . . . . . . . . . . . . 35 11.3. Control Channel Policy Management . . . . . . . . . . . . 36
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
12.1. Control Packages Registration Information . . . . . . . . 36 12.1. Control Packages Registration Information . . . . . . . . 37
12.1.1. Control Package Registration Template . . . . . . . . 37 12.1.1. Control Package Registration Template . . . . . . . . 38
12.2. Control Framework Method Names . . . . . . . . . . . . . . 37 12.2. Control Framework Method Names . . . . . . . . . . . . . . 38
12.3. Control Framework Status Codes . . . . . . . . . . . . . . 37 12.3. Control Framework Status Codes . . . . . . . . . . . . . . 38
12.4. Control Framework Header Fields . . . . . . . . . . . . . 38 12.4. Control Framework Header Fields . . . . . . . . . . . . . 39
12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 38 12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 39
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 38 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 39
13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 39 13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 40
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 39 14.1. Changes from 02 Version . . . . . . . . . . . . . . . . . 40
14.2. Changes from 00 Version . . . . . . . . . . . . . . . . . 40 14.2. Changes from 01 Version . . . . . . . . . . . . . . . . . 41
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.3. Changes from 00 Version . . . . . . . . . . . . . . . . . 41
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 41 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 41 17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 42
18. Normative References . . . . . . . . . . . . . . . . . . . . . 43 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46 18.1. Normative References . . . . . . . . . . . . . . . . . . . 44
18.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
Real-time media applications are often developed using an Real-time media applications are often developed using an
architecture where the application logic and processing activities architecture where the application logic and processing activities
are distributed. Commonly, the application logic runs on are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers, "application servers" but the processing runs on external servers,
such as "media servers". This document focuses on the framework and such as "media servers". This document focuses on the framework and
protocol between the application server and external processing protocol between the application server and external processing
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
requirements for Media Server Control, which can be found in the requirements for Media Server Control, which can be found in the
'Media Server Control Protocol Requirements' document[RFC5167]. 'Media Server Control Protocol Requirements' document[RFC5167].
While the Framework is not media server control specific, it is the While the Framework is not media server control specific, it is the
primary driver and use case for this work. It is intended that the primary driver and use case for this work. It is intended that the
framework contained in this document will be applicable for a variety framework contained in this document will can be used for a variety
of device control scenarios. of device control scenarios (for example, conference control).
This document does not define a SIP based extension that can be used This document does not define a SIP protocol driven extension that
directly for the control of external components. The framework can be used directly for the control of external components. The
mechanism must be extended by other documents that are known as framework mechanism must be extended by other documents that are
"Control Packages". A comprehensive set of guidelines for creating known as "Control Packages". A comprehensive set of guidelines for
"Control Packages" is described in Section 8. creating "Control Packages" is described in Section 8.
Current IETF device control protocols, such as megaco [RFC3525], Current IETF device control protocols, such as megaco [RFC3525],
while excellent for controlling media gateways that bridge separate while excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in networks, are troublesome for supporting media-rich applications in
SIP networks, because they duplicate many of the functions inherent SIP networks, because they duplicate many of the functions inherent
in SIP. Rather than relying on single protocol session in SIP. Rather than relying on single protocol session
establishment, application developers need to translate between two establishment, application developers need to translate between two
separate mechanisms. separate mechanisms.
Application servers traditionally use SIP third party call control SIP [RFC3261] provides the ideal rendezvous mechanism for
[RFC3725] to establish media sessions from SIP user agents to a media establishing and maintaining control connections to external server
server. SIP [RFC3261], also provides the ideal rendezvous mechanism components. The control connections can then be used to exchange
for establishing and maintaining control connections to external explicit command/response interactions that allow for media control
server components. The control connections can then be used to and associated command response results.
exchange explicit command/response interactions that allow for media
control and associated command response results.
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST", In this document, BCP 14 [RFC2119] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant addition, BCP 15 indicates requirement levels for compliant
implementations. implementations.
The following additional terms are defined for use in this document: The following additional terms are defined for use in this document:
skipping to change at page 6, line 15 skipping to change at page 6, line 15
Transaction-Timeout: the maximum allowed time between a control Transaction-Timeout: the maximum allowed time between a control
Client or Server issuing a framework message and receiving a Client or Server issuing a framework message and receiving a
corresponding response. The value for the timeout should be based corresponding response. The value for the timeout should be based
on a multiple of the network RTT plus an appropriate number on a multiple of the network RTT plus an appropriate number
milliseconds to allow for message parsing and processing. The milliseconds to allow for message parsing and processing. The
value for 'Transaction-Timeout' is 5 seconds. value for 'Transaction-Timeout' is 5 seconds.
3. Overview 3. Overview
This document details mechanisms for establishing, using, and This document details mechanisms for establishing, using, and
terminating a reliable channel using SIP for the purpose of terminating a reliable transport connection channel using SIP and the
controlling an external server. The following text provides a non- Session Description Protocol offer/answer [RFC3264] exchange. The
normative overview of the mechanisms used. Detailed, normative established connection is then used for controlling an external
guidelines are provided later in the document. server. The following text provides a non-normative overview of the
mechanisms used. Detailed, normative guidelines are provided later
in the document.
Control channels are negotiated using standard SIP mechanisms that Control channels are negotiated using standard SIP mechanisms that
would be used in a similar manner to creating a SIP multimedia would be used in a similar manner to creating a SIP multimedia
session. Figure 1 illustrates a simplified view of the mechanism. session. Figure 1 illustrates a simplified view of the mechanism.
It highlights a separation of the SIP signaling traffic and the It highlights a separation of the SIP signaling traffic and the
associated control channel that is established as a result of the SIP associated control channel that is established as a result of the SIP
interactions. interactions.
Initial analysis into the control framework, as documented in
[I-D.burger-mscl-thoughts], established the following. One might
ask, "If all we are doing is establishing a TCP connection to control
the media server, what do we need SIP for?" This is a reasonable
question. The key is to be using SIP for media session
establishment. If we are using SIP for media session establishment,
then we need to ensure the URI used for session establishment
resolves to the same node as the node for session control. Using the
SIP routing mechanism, and having the server initiate the TCP
connection back, ensures this works. For example, the URI sip:
myserver.example.com may resolve to sip:
server21.farm12.northeast.example.net, whereas the
URIhttp://myserver.example.com may resolve to
http://server41.httpfarm.central.example.net. That is, the host part
is NOT NECESSARILY unambiguous.
The use of SIP for to negotiate the control-channel provides many The use of SIP for to negotiate the control-channel provides many
inherent capabilities which include: inherent capabilities which include:
o Service location - Use SIP Proxies or Back-to-Back User Agents for o Service location - Use SIP Proxies or Back-to-Back User Agents for
discovering Control Servers. discovering Control Servers.
o Security mechanisms - Leverage established security mechanisms o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication. such as Transport Layer Security (TLS) and Client Authentication.
o Connection maintenance - The ability to re-negotiate a connection, o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, audit parameters, and so forth. ensure it is active, and so forth.
o Application agnostic - Generic protocol allows for easy extension. o Application agnostic - Generic protocol allows for easy extension.
As mentioned in the previous list, one of the main benefits of using As mentioned in the previous list, one of the main benefits of using
SIP as the session control protocol is the "Service Location" SIP as the session control protocol is the "Service Location"
facilities provided. This applies at both a routing level, where facilities provided. This applies at both a routing level, where
[RFC3263] provides the physical location of devices, and at the [RFC3263] provides the physical location of devices, and at the
Service level, using Caller Preferences [RFC3840] and Callee Service level, using Caller Preferences [RFC3840] and Callee
Capabilities [RFC3841]. The ability to select a Control Server based Capabilities [RFC3841]. The ability to select a Control Server based
on Service level capabilities is extremely powerful when considering on Service level capabilities is extremely powerful when considering
a distributed, clustered architecture containing varying services a distributed, clustered architecture containing varying services
skipping to change at page 10, line 9 skipping to change at page 10, line 36
create a related dialog to the Control Server (B2BUA type create a related dialog to the Control Server (B2BUA type
functionality). Using the interaction illustrated by (2), the functionality). Using the interaction illustrated by (2), the
Control Client negotiates media capabilities with the Control Server, Control Client negotiates media capabilities with the Control Server,
on behalf of the User Agent, using SIP Third Party Call Control on behalf of the User Agent, using SIP Third Party Call Control
[RFC3725]. [RFC3725].
4. Control Channel Setup 4. Control Channel Setup
4.1. Control Client SIP UAC Behavior 4.1. Control Client SIP UAC Behavior
On creating a new SIP INVITE request for control channel setup, a UAC When a UAC wishes to establish a control channel, it MUST construct
MUST construct the protocol message as defined in [RFC3261]. and transmit a new SIP INVITE request for control channel setup, a
UAC MUST construct the protocol message as defined in [RFC3261].
If a reliable response is received (as defined [RFC3261] and If a reliable response is received (as defined [RFC3261] and
[RFC3262]), the mechanisms defined in this document are applicable to [RFC3262]), the mechanisms defined in this document are applicable to
the newly created dialog. the newly created dialog.
The UAC MAY 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] (*note - SIP also allows an Description Protocol defined in [RFC4566] (*note - SIP also allows an
'offer-less' INVITE which is also maintained by this specification). 'offer-less' INVITE which is also maintained by this specification).
The following information defines the composition of some specific The following information defines the composition of some specific
elements of the SDP payload that MUST be adhered to for compliancy to elements of the SDP payload that MUST be adhered to for compliancy to
this specification when used in an SIP SDP offer. this specification when used in an SIP SDP offer.
The Connection Data line in the SDP payload is constructed as The Connection Data line in the SDP payload is constructed as
specified in [RFC4566]: specified in [RFC4566]:
skipping to change at page 12, line 4 skipping to change at page 12, line 32
from the owner of the SDP payload. The connection details are from the owner of the SDP payload. The connection details are
contained in the SDP answer received from the UAS. A full example of contained in the SDP answer received from the UAS. A full example of
an SDP payload compliant to this specification can be viewed in an SDP payload compliant to this specification can be viewed in
Section 3. Once the SDP has been constructed along with the Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in [RFC3261]), it can remainder of the SIP INVITE request (as defined in [RFC3261]), it can
be sent to the appropriate location. The SIP dialog and appropriate be sent to the appropriate location. The SIP dialog and appropriate
control connection is then established. control connection is then established.
A client constructing an offer MUST include the 'cfw-id' SDP A client 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 used within the control indicates an identifier that can be used within the control channel
channel to correlate the control channel with this SIP dialog. This to correlate the control channel with this SIP dialog. This
attribute MUST contain an appropriately random value that will not attribute MUST contain an appropriately random value of at least 64
clash with other offer/answer exchanges that will take place and is bits of randomness that will not clash with other offer/answer
globally unique over space and time. The value chosen for the exchanges that will take place and is globally unique over space and
'cfw-id' attribute MUST be used for the entire duration of the time. The value chosen for the 'cfw-id' attribute MUST be used for
associated SIP dialog and not be changed during updates to the offer/ the entire duration of the associated SIP dialog and not be changed
answer exchange. during updates to the offer/answer exchange.
A non-2xx class error (4xx, 5xx and 6xx) SIP response received for A non-2xx class final response (4xx, 5xx and 6xx) SIP response
the INVITE request indicates that no SIP dialog has been created and received for the INVITE request indicates that no SIP dialog has been
is treated as specified [RFC3261]. Specifically, support of this created and is treated as specified [RFC3261]. Specifically, support
specification is negotiated through the presence of the media type of this specification is negotiated through the presence of the media
defined in this specification. The receipt of a SIP error response type defined in this specification. The receipt of a SIP error
like "488" indicates that the offer contained in a request is not response like "488" indicates that the offer contained in a request
acceptable. The inclusion of the media line associated with this is not acceptable. The inclusion of the media line associated with
specification in such a rejected offer should indicate to the client this specification in such a rejected offer should indicate to the
generating the offer that this could be due to the receiving client client generating the offer that this could be due to the receiving
not supporting this specification. The client generating the offer client not supporting this specification. The client generating the
should act as it would normally on receiving this response, as per offer MUST act as it would normally on receiving this response, as
[RFC3261]. Media streams can also be rejected by setting the port to per [RFC3261]. Media streams can also be rejected by setting the
"0" in the "m=" line of the session description. A client using this port to "0" in the "m=" line of the session description. A client
specification should be prepared to receive an answer where the "m=" using this specification should be prepared to receive an answer
line it inserted for using the Control Framework has been set to "0". where the "m=" line it inserted for using the Control Framework has
been set to "0". In this situation the client will act as it would
for any other media type with a port set to "0".
4.2. Control Server SIP UAS Behavior 4.2. Control Server SIP UAS Behavior
On receiving a SIP INVITE request, an external Server(UAS) inspects On receiving a SIP INVITE request, an external Server(UAS) inspects
the message for indications of support for the mechanisms defined in the message for indications of support for the mechanisms defined in
this specification. This is achieved through inspection of the this specification. This is achieved through inspection of the
Sessions Description of the SIP INVITE message and identifying Sessions Description of the offer message and identifying support for
support for the appropriate media type. If the external Server the appropriate media type. If the external Server wishes to
wishes to construct a reliable response that conveys support for the construct a reliable response that conveys support for the extension,
extension, it should follow the mechanisms defined in [RFC3261]. If it should follow the mechanisms defined in [RFC3261]. If support is
support is conveyed in a reliable SIP provisional response, the conveyed in a reliable SIP provisional response, the mechanisms in
mechanisms in [RFC3262] MUST also be used. It should be noted that [RFC3262] MUST also be used. It should be noted that the SDP offer
the SDP offer is not restricted to the initial INVITE request and may is not restricted to the initial INVITE request and may appear in any
appear in any series of messages that are compliant to [RFC3261], series of messages that are compliant to [RFC3261], [RFC3262], and
[RFC3262], and [RFC3264] [RFC3264].
When constructing an answer, the SDP payload MUST be constructed When constructing an answer, the SDP payload MUST be constructed
using the semantics(Connection, Media and attribute) defined in using the semantics(Connection, Media and attribute) defined in
Section 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 copy the attribute as defined in Section 9.2. This attribute MUST copy the
value which appeared in the initial offer. value which appeared in the initial offer.
Once the SIP success response has been constructed, it is sent using Once the SDP answer has been constructed, it is sent using standard
standard SIP mechanisms. Depending on the contents of the SDP SIP mechanisms. Depending on the contents of the SDP payloads that
payloads that were negotiated using the Offer/Answer exchange, a were negotiated using the Offer/Answer exchange, a reliable
reliable connection will be established between the Controlling UAC connection will be established between the Controlling UAC and
and external Server UAS entities. The newly established connection external Server UAS entities. The newly established connection is
is now available to exchange control command primitives. The state now available to exchange control command primitives. The state of
of the SIP Dialog and the associated Control channel are now the SIP Dialog and the associated Control channel are now implicitly
implicitly linked. If either party wishes to terminate a Control linked. If either party wishes to terminate a Control channel it
channel it simply issues a SIP termination request (SIP BYE request). simply issues a SIP termination request (for example a SIP BYE
The Control Channel therefore lives for the duration of the SIP request, or appropriate response in an early dialog). The Control
dialog. Channel therefore lives for the duration of the SIP dialog.
If the UAS does not support the extension defined in this document, If the UAS does not support the extension defined in this document,
as identified by the media contained in the Session Description, it as identified by the media contained in the Session Description, it
SHOULD respond as detailed in [RFC3261] with a "SIP 488" response should respond as detailed in [RFC3261] with a "SIP 488" response
code. If multiple media descriptions exist it MAY choose to continue code. If multiple media descriptions exist it might choose to
processing the request and mark the port field equal to "0". continue processing the request and mark the port field equal to "0".
A SIP entity receiving a SIP OPTIONS request MUST respond A SIP entity receiving a SIP OPTIONS request MUST respond
appropriately as defined in [RFC3261]. This involves providing appropriately as defined in [RFC3261]. This involves providing
information relating to supported SIP extensions and media types in a information relating to supported SIP extensions and media types in a
200 OK response. For this extension the media types supported MUST 200 OK response. For this extension the media types supported MUST
be included in the SIP 200 OK response in a SIP "Accept" header to be included in the SIP 200 OK response in a SIP "Accept" header to
indicate a valid media type. indicate a valid media type.
5. Establishing Media Streams - Control Client SIP UAC Behavior 5. Establishing Media Streams - Control Client SIP UAC Behavior
skipping to change at page 14, line 4 skipping to change at page 14, line 34
primary functions will be the use of the control channel to apply primary functions will be the use of the control channel to apply
specific Control package commands to media sessions established by specific Control package commands to media sessions established by
SIP dialogs (media dialogs) with the same remote server. For SIP dialogs (media dialogs) with the same remote server. For
example, to apply a command to generate audio media (such as an example, to apply a command to generate audio media (such as an
announcement) on an RTP session between a User Agent and a Media announcement) on an RTP session between a User Agent and a Media
Server. Server.
SIP dialogs used to establish media sessions (see Figure 2) on behalf SIP dialogs used to establish media sessions (see Figure 2) on behalf
of User Agents may contain more than one Media Description (as of User Agents may contain more than one Media Description (as
defined by "m=" in the SDP). The Control Client SHOULD include a defined by "m=" in the SDP). The Control Client SHOULD include a
media label attribute (B2BUA functionality), as defined in [RFC4574], media label attribute, as defined in [RFC4574], for each "m="
for each "m=" definition. A Control Client constructing the SDP MAY definition received that is to be directed to an entity using the
choose not to include the media label SDP attribute if it does not control framework. This allows the Control Client to later
require direct control on a per media stream basis. explicitly direct commands on the control channel at a specific media
line(m=). A Control Client constructing the SDP MAY choose not to
include the media label SDP attribute if it does not require direct
control on a per media stream basis.
This framework identifies the common re-use of referencing media This framework identifies the referencing of such associated media
dialogs and has specified a connection reference attribute that can dialogs as extremely important. A connection reference attribute has
optionally be imported into any Control Package. It is intended that been specified that can optionally be imported into any Control
this will reduce repetitive specifying of dialog reference language. Package. It is intended that this will reduce repetitive specifying
The schema can be found in Section 17.1 in Appendix A. of dialog reference language. The schema can be found in
Section 17.1 in Appendix A.
Similarly, the ability to identify and apply commands to a group of Similarly, the ability to identify and apply commands to a group of
associated media dialogs (multiparty) is also identified as a common associated media dialogs (multiparty) is also identified as a common
structure that could be defined and re-used (for example playing a structure that could be defined and re-used (for example playing a
prompt to all participants in a Conference). The schema for such prompt to all participants in a Conference). The schema for such
operations can also be found in Section 17.1 in Appendix A. operations can also be found in Section 17.1 in Appendix A.
Support for both the common attributes described here is specified as Support for both the common attributes described here is specified as
part of each Control Package definition, as detailed in Section 8. part of each Control Package definition, as detailed in Section 8.
skipping to change at page 14, line 48 skipping to change at page 15, line 35
SHOULD be carried out before any other signaling on the newly created SHOULD be carried out before any other signaling on the newly created
Control channel. An alternative dialog association mechanism MAY be Control channel. An alternative dialog association mechanism MAY be
specified in extensions to this document. specified in extensions to this document.
o Once the connection has been established, the UA acting in the o Once the connection has been established, the UA acting in the
active role (active UA) to initiate the connection MUST active role (active UA) to initiate the connection MUST
immediately send a Control Framework SYNC request. The SYNC immediately send a Control Framework SYNC request. The SYNC
request MUST be constructed as defined in Section 9.1 and MUST request MUST be constructed as defined in Section 9.1 and MUST
contain the message header, 'Dialog-ID', which contains the SIP contain the message header, 'Dialog-ID', which contains the SIP
dialog information. dialog information.
o The 'Dialog-ID' message header value is the value contained in the o The 'Dialog-ID' message header value is the value contained in the
'cfw-id' SDP attribute. This allows for a correlation between the 'cfw-id' SDP media level attribute. This allows for a correlation
control channel and its associated SIP dialog. between the control channel and its associated SIP dialog.
o On creating the SYNC request the active UA MUST follow the o On creating the SYNC request the active UA MUST follow the
procedures outlined in Section 6.3.3 . This provides details of procedures outlined in Section 6.3.3 . This provides details of
connection keep-alive messages. connection keep-alive messages.
o On creating the SYNC request the active UA MUST also follow the o On creating the SYNC request the active UA MUST also follow the
procedures outlined in Section 6.3.4.2. This provides details of procedures outlined in Section 6.3.4.2. This provides details of
the negotiation mechanism used to determine the Protocol Data the negotiation mechanism used to determine the Protocol Data
Units (PDUs) that can be exchanged on the established control Units (PDUs) that can be exchanged on the established control
channel connection. channel connection.
o The active UA MUST then send the SYNC request. It MUST then wait o The active UA MUST then send the SYNC request. It MUST then wait
for a period of at least 'Transaction-Timeout' to receive a for a period of at least 'Transaction-Timeout' to receive a
skipping to change at page 16, line 12 skipping to change at page 16, line 49
Section 9 (Note: either entity can act as a control client depending Section 9 (Note: either entity can act as a control client depending
on individual package requirements). Control Commands MUST also on individual package requirements). Control Commands MUST also
adhere to the syntax defined by the Control Packages negotiated in adhere to the syntax defined by the Control Packages negotiated in
Section 4.1 and Section 4.2 of this document. A Control Client MUST Section 4.1 and Section 4.2 of this document. A Control Client MUST
create a unique control message transaction and associated identifier create a unique control message transaction and associated identifier
for insertion in the request. The transaction identifier is then for insertion in the request. The transaction identifier is then
included in the first line of a control framework message along with included in the first line of a control framework message along with
the method type (as defined in the ABNF in Section 9). The first the method type (as defined in the ABNF in Section 9). The first
line starts with the "CFW" token for the purpose of easily extracting line starts with the "CFW" token for the purpose of easily extracting
the transaction identifier. The transaction identifier MUST be the transaction identifier. The transaction identifier MUST be
globally unique over space and time. All required mandatory and globally unique over space and time with at least 64 bits of
optional control framework headers are then inserted into the control randomness. All required mandatory and optional control framework
message with appropriate values (see relevant individual header headers are then inserted into the control message with appropriate
information for explicit detail). A "Control-Package" header MUST values (see relevant individual header information for explicit
also be inserted with the value indicating the Control Package to detail). A "Control-Package" header MUST also be inserted with the
which this specific request applies (Multiple packages can be value 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-Length' and 'Content-Type' message header which include a 'Content-Type' and 'Content-Length' message header which
represents the size of the message body in decimal number of octets. represents the size of the message body in decimal number of octets.
If no associated payload is to be added to the message, a 'Content- The 'Content-Type' header represents the MIME payload to be used as
Length' header with a value of '0' is considered the same as one not specified by the individual control frameowrk packages. If no
being present. associated payload is to be added to the message, a 'Content-Length'
header with a value of '0' is considered the same as one not being
present.
When all of the headers have been included in the framework message, When all of the headers have been included in the framework message,
it is sent down the control channel. it is sent down the control channel.
A Server receiving such a request needs to respond quickly with an A Server receiving such a request needs to respond quickly with an
appropriate response (as defined in Section 6.2). Control Clients appropriate response (as defined in Section 6.2). Control Clients
MUST wait for a minimum of 'Transaction-Timeout' for a response MUST wait for a minimum of 'Transaction-Timeout' for a response
before considering the transaction a failure. before considering the transaction a failure and tidying state
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'. The response MUST generate a response within the 'Transaction-Time'. The response MUST
conform to the ABNF defined in Section 9. The first line of the conform to the ABNF defined in Section 9. The first line of the
response MUST contain the transaction identifier used in first line response MUST contain the transaction identifier used in first line
of the request, as defined in Section 6.1. Responses MUST NOT of the request, as defined in Section 6.1. Responses MUST NOT
include the 'Status' or 'Timeout' message headers, and these MUST be include the 'Status' or 'Timeout' message headers, and these MUST be
ignored if received by a Client in a response. ignored if received by a Client in a response.
A Control Server MUST then include a status code in the first line of A Control Server MUST then include a status code in the first line of
the constructed response. A Control Framework request (like CONTROL) the constructed response. A Control Framework request (like CONTROL)
that has been understood, and either the actions for the control that has been received, and either the actions specified by the
command have completed or a control command error is detected, uses request have completed or a control command error is detected, uses
the 200 Control Framework status code as defined in Section 7.1. A the 200 Control Framework status code as defined in Section 7.1 in
200 response MAY include message bodies. If a 200 response does the response. A 200 response MAY include message bodies. If a 200
contain a payload it MUST include Content-Length and Content-Type response does contain a payload it MUST include Content-Length and
headers. A 200 is the only response defined in this specification Content-Type headers. A 200 is the only response defined in this
that allows a message body to be included. A client receiving a 200 specification that allows a message body to be included. The
class response then considers the control command transaction 'Content-Type' header represents the MIME payload to be used as
completed. A Control Framework request (like CONTROL) that is specified by the individual control framework packages. A client
received and understood but requires processing that extends beyond receiving a 200 class response then considers the control command
'Transaction-Timeout' will return a 202 status code in the response. transaction completed. A Control Framework request (like CONTROL)
This will be followed by one or more REPORT messages as defined in that is received and understood but requires processing that extends
Section 6.3.2. A Control Package SHOULD explicitly define the beyond 'Transaction-Timeout' will result in a 202 status code in the
circumstances under which either 200 or 202 with subsequent response. This will be followed by one or more REPORT messages as
defined in Section 6.3.2. A Control Package SHOULD explicitly define
the circumstances under which either 200 or 202 with subsequent
processing takes place. processing takes place.
If a Control Server encounters problems with a Control Framework If a Control Server encounters problems with a Control Framework
request (like REPORT or CONTROL), an appropriate error code should be request (like REPORT or CONTROL), an appropriate error code should be
used in the response, as listed in Section 7. The generation of a used in the response, as listed in Section 7. The generation of a
non 2xx class response code to a Control Framework request (like non 2xx class response code to a Control Framework request (like
CONTROL or REPORT) will indicate failure of the transaction, and all CONTROL or REPORT) will indicate failure of the transaction, and all
associated state and resources should be terminated. The response associated state and resources should be terminated. The response
code may provide an explicit indication of why the transaction code may provide an explicit indication of why the transaction
failed, which might result in a re-submission of the request. failed, which might result in a re-submission of the request
depending on the extension package being used.
6.3. Transaction Processing 6.3. Transaction Processing
The Control Framework defines four types of messages (methods): The Control Framework defines four types of requests (methods):
CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support
sending and receiving all four methods. Future extensions to this sending and receiving all four methods. Future extensions to this
document MAY define new methods and responses. document MAY define new methods and responses.
The following sub-sections specify each Control Framework method and The following sub-sections specify each Control Framework method and
its associated transaction processing. its associated transaction processing.
6.3.1. CONTROL Transactions 6.3.1. CONTROL Transactions
A 'CONTROL' message is used by Control Client pass control related A 'CONTROL' message is used by the Control Client to pass control
information, such as invoking commands or notifying events, to a related information to a Control Server. It is also used as the
Control Server. The message is constructed in the same way as any event reporting mechanism in the control framework. Reporting events
standard Control Framework message, as discussed previously in is simply another usage of the 'CONTROL' message which is permitted
Section 6.1 and defined in Section 9. A CONTROL message MAY contain to be sent in either direction between two participants in a session,
a message body. The explicit control command(s) of the message carrying the appropriate payload for an event. The message is
payload contained in a CONTROL message are specified in separate constructed in the same way as any standard Control Framework
Control Package specifications. These specifications MUST conform to message, as discussed previously in Section 6.1 and defined in
the format defined in Section 8.4. A CONTROL message containing a Section 9. A CONTROL message MAY contain a message body. The
payload MUST include a 'Content-Type' header indicating the payload explicit control command(s) of the message payload contained in a
type defined by the control package. CONTROL message are specified in separate Control Package
specifications. These specifications MUST conform to the format
defined in Section 8.4. A CONTROL message containing a payload MUST
include a 'Content-Type' header indicating the payload type defined
by the control package.
6.3.2. REPORT Transactions 6.3.2. REPORT Transactions
A 'REPORT' message is used by a Control Server when processing of a A 'REPORT' message is used by a Control Server when processing of a
CONTROL Command extends beyond a 'Transaction-Timeout'. In this case CONTROL Command extends beyond a 'Transaction-Timeout'. In this case
a 202 response is returned. Status updates and the final results of a 202 response is returned. Status updates and the final results of
the command are then returned in subsequent REPORT messages. the command are then returned in subsequent REPORT messages.
All REPORT messages MUST contain the same transaction ID in the All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL request start line that was present in the original CONTROL
transaction. This allows both extended transactions and event transaction. This allows extended transactions to be correlated with
notifications to be correlated with the original CONTROL transaction. the original CONTROL transaction. A REPORT message containing a
A REPORT message containing a payload MUST include a 'Content-Length payload MUST include a 'Content-Length and 'Content-Type' header
and 'Content-Type' header indicating the payload type defined by the indicating the payload MIME[RFC2045] type defined by the control
control package and its length. package and its length.
6.3.2.1. Reporting the Status of Extended Transactions 6.3.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within On receiving a CONTROL message, a Control Server MUST respond within
'Transaction-Timeout' with a status code for the request, as 'Transaction-Timeout' with a status code for the request, as
specified in Section 6.2. If the command completed within that time, specified in Section 6.2. If the command completed within that time,
a 200 response code would have been sent. If the command did not a 200 response code would have been sent. If the command did not
complete within that time, the response code 202 would have been sent complete within that time, the response code 202 would have been sent
indicating that the requested command is still being processed and indicating that the requested command is still being processed and
the CONTROL transaction is being extended. The REPORT method is then the CONTROL transaction is being extended. The REPORT method is then
skipping to change at page 22, line 37 skipping to change at page 23, line 29
response code. The response MUST contain a "Packages" header that response code. The response MUST contain a "Packages" header that
lists the supported packages that are in common with those from the lists the supported packages that are in common with those from the
"Packages" header of the request (either all or a subset). This list "Packages" header of the request (either all or a subset). This list
forms a common set of Control Packages that are supported by both forms a common set of Control Packages that are supported by both
parties. Any Control Packages supported by the server that are not parties. Any Control Packages supported by the server that are not
listed in the "Packages" header of the SYNC request, MAY be placed in listed in the "Packages" header of the SYNC request, MAY be placed in
the "Supported" header of the response. This provides a hint to the the "Supported" header of the response. This provides a hint to the
client that generated the SYNC request of the additional packages client that generated the SYNC request of the additional packages
supported by the server. supported by the server.
If no packages are supported by the server receiving the SYNC If no common packages are supported by the server receiving the SYNC
message, it MUST respond with a 422 error response code. The error message, it MUST respond with a 422 error response code. The error
response MUST contain a "Supported" header indicating the packages response MUST contain a "Supported" header indicating the packages
that are supported. The initiating client can then choose to either that are supported. The initiating client can then choose to either
re-submit a new SYNC message based on the 422 response or consider re-submit a new SYNC message based on the 422 response or consider
the interaction as a failure. This would lead to termination of the the interaction as a failure. This would lead to termination of the
associated SIP dialog by sending a SIP BYE request, as per [RFC3261]. associated SIP dialog by sending a SIP BYE request, as per [RFC3261].
Once the initial SYNC transaction is completed, either client MAY Once the initial SYNC transaction is completed, either client MAY
choose to send a subsequent new SYNC Control Framework message to re- choose to send a subsequent new SYNC Control Framework message to re-
negotiate the packages that are supported within the control channel. negotiate the packages that are supported within the control channel.
skipping to change at page 23, line 29 skipping to change at page 24, line 20
REPORT messages except that a 202 MUST NOT be generated in response REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message. to a REPORT message.
Note that these response codes apply to framework transactions only. Note that these response codes apply to framework transactions only.
Success or error indications for control commands MUST be treated as Success or error indications for control commands MUST be treated as
the result of a control command and returned in either a 200 response the result of a control command and returned in either a 200 response
or REPORT message. or REPORT message.
7.1. 200 Response Code 7.1. 200 Response Code
The 200 code indicates the completion of a successful transaction. The 200 code indicates the completion of a successful framework
protocol transaction.
7.2. 202 Response Code 7.2. 202 Response Code
The 202 response code indicates the completion of a successful The 202 response code indicates the completion of a successful
transaction with additional information to be provided at a later framework protocol transaction with additional information to be
time through the REPORT mechanism defined in Section 6.3.2. provided at a later time through the REPORT mechanism defined in
Section 6.3.2.
7.3. 400 Response Code 7.3. 400 Response Code
The 400 response indicates that the request was syntactically The 400 response indicates that the request was syntactically
incorrect. incorrect.
7.4. 403 Response Code 7.4. 403 Response Code
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfill it.
The request SHOULD NOT be repeated. The request SHOULD NOT be repeated.
skipping to change at page 24, line 22 skipping to change at page 25, line 12
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.8. 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.9. 423 Response Code
Recipient already has a transaction with the same transaction ID. Recipient has an existing transaction with the same transaction ID.
7.10. 481 Response Code 7.10. 481 Response Code
The 481 response indicates that the transaction of the request does The 481 response indicates that the transaction of the request does
not exist. In response to a SYNC request, it indicates that the not exist. In response to a SYNC request, it indicates that the
corresponding SIP dialog does not exist. corresponding SIP dialog does not exist.
7.11. 500 Response Code 7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
skipping to change at page 25, line 17 skipping to change at page 26, line 4
This section MUST be present in all extensions to this document and This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the include information that appears in the IANA registration of the
token. Information on registering control package tokens is token. Information on registering control package tokens is
contained in Section 12. The package name MUST also register a contained in Section 12. The package name MUST also register a
version number for the package which is separated with a '/' symbol version number for the package which is separated with a '/' symbol
e.g. package_name/1.0. This enables updates to the package to be e.g. package_name/1.0. This enables updates to the package to be
registered where appropriate. An initial version of a package MUST registered where appropriate. An initial version of a package MUST
start with the value '1.0'. Subsequent versions MUST increment this start with the value '1.0'. Subsequent versions MUST increment this
number if the same package name is to be used. The exact increment number if the same package name is to be used. The exact increment
is left to the discretion of the package author. 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 should control channel. This section of a Control package document should
explicitly detail the control messages that can be used as well as explicitly detail the control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. include which role type is allowed to initiate a request type.
8.3. Common XML Support 8.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required. attributes for media dialog or Conference reference are required, as
The Control Package will make strong statements (MUST strength) if defined and discussed in Section 17.1 in Appendix A. The Control
the XML schema defined in Section 17.1 in Appendix A is to be Package will make strong statements (using language from RFC 2119
supported. If only part of the schema is required (for example just [RFC2119]) if the XML schema defined in Section 17.1 in Appendix A is
'connectionid' or just conferenceid), the Control Package will make to be supported. If only part of the schema is required (for example
equally strong (MUST strength) statements. just 'connectionid' or just conferenceid), the Control Package will
make equally strong (using language from RFC 2119 [RFC2119])
statements.
8.4. CONTROL Message Bodies 8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 6 (or that no control package body is required). This Section 6 (or that no control package body is required). This
section should indicate the location of detailed syntax definitions section should indicate the location of detailed syntax definitions
and semantics for the appropriate body types. and semantics for the appropriate MIME[RFC2045] body type that apply
to a CONTROL command request and optionally the associated 200
response.
8.5. REPORT Message Bodies 8.5. REPORT Message Bodies
This mandatory section of a Control Package defines the REPORT body This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in that can be contained within a REPORT command request, as defined in
Section 6 (or that no report package body is required). This section Section 6 (or that no report package body is required). This section
should indicate the location of detailed syntax definitions and should indicate the location of detailed syntax definitions and
semantics for the appropriate body types. It should be noted that semantics for the appropriate MIME[RFC2045] body type. It should be
the Control Framework specification does allow for payloads to exist noted that the Control Framework specification does allow for
in 200 responses to CONTROL messages (as defined in this document). payloads to exist in 200 responses to CONTROL messages (as defined in
An entity that is prepared to receive a payload type in a REPORT this document). An entity that is prepared to receive a payload type
message MUST also be prepared to receive the same payload in a 200 in a REPORT message MUST also be prepared to receive the same payload
response to a CONTROL message. in a 200 response to a CONTROL message.
8.6. Audit 8.6. Audit
Auditing of various control package properties is extremely useful. Auditing of various control package properties such as capabilities
and resources(meta package level information) is extremely useful.
Such meta-data usually has no direct impact on control framework
interactions but allows for contextual information to be learnt.
Control Packages are encouraged to make use of Control Framework 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
skipping to change at page 32, line 4 skipping to change at page 32, line 43
Cotent-Length: [..] Cotent-Length: [..]
v=0 v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=- s=-
c=IN IP4 control-client.example.com c=IN IP4 control-client.example.com
m=application 7575 TCP/CFW m=application 7575 TCP/CFW
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cfw-id:fndskuhHKsd783hjdla a=cfw-id:fndskuhHKsd783hjdla
2. Control Server->Control Client (SIP): 200 OK
2. Control Server->Control Client (SIP): 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc2.example.com> Contact: <sip:control-client@pc2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [..] Content-Length: [..]
skipping to change at page 32, line 44 skipping to change at page 33, line 42
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
5. Control Server-->Control Client (Control Framework Message): 5. Control Server-->Control Client (Control Framework Message):
200. 200.
CFW 8djae7khauj 200 CFW 8djae7khauj 200
Keep-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
6. Control Client opens a TCP connection to the Control Server. 6. Once the SYNC process has completed, the connection can now be
The connection can now be used to exchange control framework used to exchange control framework messages. Control
messages. Control Client-->Control Server (Control Framework Client-->Control Server (Control Framework Message): CONTROL.
Message): CONTROL.
CFW i387yeiqyiq CONTROL CFW i387yeiqyiq CONTROL
Control-Package: <package-name> Control-Package: <package-name>
Content-Type: example_content/example_content Content-Type: example_content/example_content
Content-Length: 11 Content-Length: 11
<XML BLOB/> <XML BLOB/>
7. Control Server-->Control Client (Control Framework Message): 7. Control Server-->Control Client (Control Framework Message):
202. 202.
skipping to change at page 35, line 7 skipping to change at page 36, line 7
the connected host is the host that it meant to connect to and that the connected host is the host that it meant to connect to and that
the connection has not been hijacked. the connection has not been hijacked.
Channel Framework is designed to comply with the security-related Channel Framework is designed to comply with the security-related
requirements documented in the control protocol requirements requirements documented in the control protocol requirements
document[RFC5167]. Specific security measures employed by the document[RFC5167]. Specific security measures employed by the
Channel Framework are summarized in the following subsections. Channel Framework are summarized in the following subsections.
11.1. Session Establishment 11.1. Session Establishment
ChannelFramework sessions are established as media sessions described Channel Framework sessions are established as media sessions
by SDP within the context of a SIP dialog. In order to ensure secure described by SDP within the context of a SIP dialog. In order to
rendezvous between Control Framework clients and servers, the Media ensure secure rendezvous between Control Framework clients and
Channel Control Framework should make full use of mechanism provided servers, the Media Channel Control Framework should make full use of
by the SIP protocol. mechanism provided by the SIP protocol.
11.2. Transport Level Protection 11.2. Transport Level Protection
When using only TCP connections, the Channel Framework security is When using only TCP connections, the Channel Framework security is
weak. Although the Channel Framework requires the ability to protect weak. Although the Channel Framework requires the ability to protect
this exchange, there is no guarantee that the protection will be used this exchange, there is no guarantee that the protection will be used
all the time. If such protection is not used, anyone can see data all the time. If such protection is not used, anyone can see data
exchanges. exchanges.
Sensitive data is carried over the Control Framework channel. Sensitive data is carried over the Control Framework channel.
skipping to change at page 36, line 39 skipping to change at page 37, line 39
names, status codes, header field names, port and transport protocol. names, status codes, header field names, port and transport protocol.
Additionally, Section 12.6 registers new parameters in existing IANA Additionally, Section 12.6 registers new parameters in existing IANA
registries. registries.
12.1. Control Packages Registration Information 12.1. Control Packages Registration Information
This specification establishes the Control Packages sub-registry This specification establishes the Control Packages sub-registry
under Control Framework Packages. New parameters in this sub- under Control Framework Packages. New parameters in this sub-
registry must be published in an RFC (either as an IETF submission or registry must be published in an RFC (either as an IETF submission or
RFC Editor submission). RFC Editor submission), using the well-known IANA policy "RFC
Required", [RFC5226].
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".
skipping to change at page 38, line 30 skipping to change at page 39, line 30
Control-Package - [RFCXXXX] Control-Package - [RFCXXXX]
Status - [RFCXXXX] Status - [RFCXXXX]
Seq - [RFCXXXX] Seq - [RFCXXXX]
Timeout - [RFCXXXX] Timeout - [RFCXXXX]
Dialog-id - [RFCXXXX] Dialog-id - [RFCXXXX]
Packages - [RFCXXXX] Packages - [RFCXXXX]
Supported - [RFCXXXX] Supported - [RFCXXXX]
Keep-alive - [RFCXXXX] Keep-alive - [RFCXXXX]
Content-Type - [RFCXXXX] Content-Type - [RFCXXXX]
Content-Length - [RFCXXXX]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new Channel Framework header field: order to register a new Channel Framework header field:
o The header field name. o The header field name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
12.5. Control Framework Port 12.5. Control Framework Port
The Control Framework uses TCP port XXXX, from the "registered" port The Control Framework uses TCP port XXXX, from the "registered" port
skipping to change at page 39, line 40 skipping to change at page 40, line 42
an identifier that can be used to correlate the control an identifier that can be used to correlate the control
channel with the SIP dialog used to negotiate it, when channel with the SIP dialog used to negotiate it, when
the attribute value is used within the control channel. the attribute value is used within the control channel.
Allowed attribute values: A token. Allowed attribute values: A token.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 01 Version 14.1. Changes from 02 Version
o RAI review version. See comments.
14.2. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
skipping to change at page 40, line 16 skipping to change at page 41, line 24
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.2. Changes from 00 Version 14.3. 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 40, line 46 skipping to change at page 42, line 8
o Fixed ABNF in relation to extra CRLF on Content-Type. o Fixed ABNF in relation to extra CRLF on Content-Type.
15. Contributors 15. Contributors
Asher Shiratzky from Radvision provided valuable support and Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document. contributions to the early versions of this document.
16. Acknowledgments 16. Acknowledgments
The authors would like to thank Ian Evans and Michael Bardzinski of The authors would like to thank Ian Evans and Michael Bardzinski of
Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and
useful review and input to this work. Eric Burger contributed to the input to this work. Eric Burger contributed to the early phases of
early phases of this work. this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work. has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and
provided a great deal of invaluable input. Text from Eric Burger was
used in the introduction in the explanation for using SIP.
17. Appendix A 17. Appendix A
During the creation of the Control Framework it has become clear that During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages. initial 'Utilities Document' that can be used by Control Packages.
skipping to change at page 43, line 5 skipping to change at page 44, line 25
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation> <xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/> <xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/> <xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup> </xsd:attributeGroup>
</xsd:schema> </xsd:schema>
18. Normative References 18. References
[I-D.ietf-sip-outbound] 18.1. Normative References
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
draft-ietf-sip-outbound-13 (work in progress), March 2008. Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 43, line 39 skipping to change at page 45, line 14
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002. RFC 3268, June 2002.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[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.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[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.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
skipping to change at page 44, line 34 skipping to change at page 45, line 38
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [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.
18.2. Informative References
[I-D.burger-mscl-thoughts]
Burger, E., "Media Server Control Language and Protocol
Thoughts", draft-burger-mscl-thoughts-01 (work in
progress), June 2006.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Avaya Avaya
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: cboulton@avaya.com
 End of changes. 64 change blocks. 
247 lines changed or deleted 321 lines changed or added

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