< draft-boulton-sip-control-framework-04.txt   draft-boulton-sip-control-framework-05.txt >
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation Internet-Draft Ubiquity Software Corporation
Intended status: Informational T. Melanchuk Expires: August 11, 2007 T. Melanchuk
Expires: April 26, 2007 BlankSpace BlankSpace
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
A. Shiratzky A. Shiratzky
Radvision Radvision
October 23, 2006 February 7, 2007
A Control Framework for the Session Initiation Protocol (SIP) A Control Framework for the Session Initiation Protocol (SIP)
draft-boulton-sip-control-Framework-04 draft-boulton-sip-control-framework-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 26, 2007. This Internet-Draft will expire on August 11, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a Framework and protocol for application This document describes a Framework and protocol for application
deployment where the application logic and processing are deployment where the application logic and processing are
distributed. The framework uses the Session Initiation Protocol distributed. The framework uses the Session Initiation Protocol
(SIP) to establish an application-level control mechanism between (SIP) to establish an application-level control mechanism between
application servers and associated external servers such as media application servers and associated external servers such as media
servers. servers.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
variety of de-coupled control architectures between network entities. variety of de-coupled control architectures between network entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Locating External Server Resources . . . . . . . . . . . . . . 10 4. Locating External Server Resources . . . . . . . . . . . . . . 10
5. Control Client SIP UAC Behavior - Control Channel Setup . . . 10 5. Control Client SIP UAC Behavior - Control Channel Setup . . . 10
5.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12 5.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12
6. Control Server SIP UAS Behavior - Control Channel Setup . . . 13 6. Control Server SIP UAS Behavior - Control Channel Setup . . . 12
7. Control Framework Interactions . . . . . . . . . . . . . . . . 14 7. Control Channel Keep-Alive . . . . . . . . . . . . . . . . . . 14
7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 15 7.1. Timeout Negotiation . . . . . . . . . . . . . . . . . . . 14
7.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 16 7.2. Generating Keep-Alive Messages . . . . . . . . . . . . . . 15
7.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 16 8. Control Framework Interactions . . . . . . . . . . . . . . . . 16
7.2. Constructing Responses . . . . . . . . . . . . . . . . . . 18 8.1. Constructing Requests . . . . . . . . . . . . . . . . . . 17
8. Response Code Descriptions . . . . . . . . . . . . . . . . . . 19 8.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 18
8.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 19 8.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 18
8.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 19 8.2. Constructing Responses . . . . . . . . . . . . . . . . . . 20
8.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 19 9. Response Code Descriptions . . . . . . . . . . . . . . . . . . 21
8.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 19 9.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 21
8.5. 481 Response Code . . . . . . . . . . . . . . . . . . . . 19 9.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 21
8.6. 500 Response Code . . . . . . . . . . . . . . . . . . . . 20 9.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 21
9. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 21
9.1. Control Package Name . . . . . . . . . . . . . . . . . . . 20 9.5. 481 Response Code . . . . . . . . . . . . . . . . . . . . 21
9.2. Framework Message Usage . . . . . . . . . . . . . . . . . 20 9.6. 500 Response Code . . . . . . . . . . . . . . . . . . . . 22
9.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 21 10. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 22
9.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 21 10.1. Control Package Name . . . . . . . . . . . . . . . . . . . 22
9.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 21 10.2. Framework Message Usage . . . . . . . . . . . . . . . . . 22
9.5.1. Events . . . . . . . . . . . . . . . . . . . . . . . . 21 10.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 23
9.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 23
10. Network Address Translation (NAT) . . . . . . . . . . . . . . 22 10.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 23
11. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 10.5.1. Events . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. SIP Formal Syntax . . . . . . . . . . . . . . . . . . . . 22 10.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.2. Control Framework Formal Syntax . . . . . . . . . . . . . 22 11. Network Address Translation (NAT) . . . . . . . . . . . . . . 24
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12.1. SIP Formal Syntax . . . . . . . . . . . . . . . . . . . . 24
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 12.2. Control Framework Formal Syntax . . . . . . . . . . . . . 24
14.1. IANA Registration of the 'escs' Option Tag . . . . . . . . 29
14.2. Control Package Registration Information . . . . . . . . . 29 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2.1. Control Package Registration Template . . . . . . . . 29 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14.3. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14.3.1. TCP/ESCS . . . . . . . . . . . . . . . . . . . . . . . 29 15.1. IANA Registration of the 'escs' Option Tag . . . . . . . . 32
14.3.2. TCP/TLS/ESCS . . . . . . . . . . . . . . . . . . . . . 30 15.2. Control Package Registration Information . . . . . . . . . 32
14.4. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 30 15.2.1. Control Package Registration Template . . . . . . . . 32
14.5. SIP Response Codes . . . . . . . . . . . . . . . . . . . . 30 15.3. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 32
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 15.3.1. TCP/ESCS . . . . . . . . . . . . . . . . . . . . . . . 32
16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15.3.2. TCP/TLS/ESCS . . . . . . . . . . . . . . . . . . . . . 32
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 30 15.4. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 32
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.5. SIP Response Codes . . . . . . . . . . . . . . . . . . . . 32
17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
17.2. Informative References . . . . . . . . . . . . . . . . . . 32 17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 35 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
Applications are often developed using an architecture where the Applications are often developed using an architecture where the
application logic and processing activities are distributed. application logic and processing activities are distributed.
Commonly, the application logic runs on "application servers" whilst Commonly, the application logic runs on "application servers" whilst
the processing runs on external servers, such as "media servers". the processing runs on external servers, such as "media servers".
This document focuses on the framework and protocol between the This document focuses on the framework and protocol between the
application server and external processing server. The motivation application server and external processing server. The motivation
for this framework comes from a set of requirements for Media Server for this framework comes from a set of requirements for Media Server
Control, which can be found in the 'Media Control Protocol Framework' Control, which can be found in the 'Media Control Protocol Framework'
document[8]. While the Framework is not media server control document[8]. While the Framework is not media server control
specific, it is the primary driver and use case for this work. It is specific, it is the primary driver and use case for this work. It is
intended that the framework contained in this document will be used intended that the framework contained in this document will be used
for a plethora of appropriate device control scenarios. for a plethora of appropriate device control scenarios.
This document does not define a SIP based extension that can be used This document does not define a SIP based extension that can be used
directly for the control of external components. The framework directly for the control of external components. The framework
mechanism must be extended by other documents that are known as mechanism must be extended by other documents that are known as
"Control Packages". A comprehensive set of guidelines for creating "Control Packages". A comprehensive set of guidelines for creating
"Control Packages" is described in Section 9. "Control Packages" is described in Section 10.
Current IETF transport device control protocols, such as megaco [7], Current IETF transport device control protocols, such as megaco [7],
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 Application servers traditionally use SIP third party call control
RFC 3725 [11] to establish media sessions from SIP user agents to a RFC 3725 [12] to establish media sessions from SIP user agents to a
media server. SIP, as defined in RFC 3261 [2], also provides the media server. SIP, as defined in RFC 3261 [2], also provides the
ideal rendezvous mechanism for establishing and maintaining control ideal rendezvous mechanism for establishing and maintaining control
connections to external server components. The control connections connections to external server components. The control connections
can then be used to exchange explicit command/response interactions can then be used to exchange explicit command/response interactions
that allow for media control and associated command response results. that allow for media control and associated command response results.
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [1] defines the key words "MUST", In this document, BCP 14/RFC 2119 [1] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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:
B2BUA: A B2BUA is a Back-to-Back SIP User Agent. B2BUA: A B2BUA is a Back-to-Back SIP User Agent.
Control Server: A Control Server is an entity that performs a Control Server: A Control Server is an entity that performs a
service, such as media processing, on behalf of a Control Client. service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing, announcement, tone For example, a media server offers mixing, announcement, tone
detection and generation, and play and record services. The detection and generation, and play and record services. The
Control Server in this case, has a direct RTP [14] relationship Control Server in this case, has a direct RTP [15] relationship
with the source or sink of the media flow. In this document, we with the source or sink of the media flow. In this document, we
often refer to the Control Server simply as "the Server". 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
may not have any processing capabilities whatsoever. For example, may not have any processing capabilities whatsoever. For example,
the Control Client may be an Application Server (B2BUA) or other the Control Client may be an Application Server (B2BUA) or other
endpoint requesting manipulation of a third-party's media stream, endpoint requesting manipulation of a third-party's media stream,
that terminates on a media server acting in the role of a Control that terminates on a media server acting in the role of a Control
Server. In this document, we often refer to the Control Client Server. In this document, we often refer to the Control Client
simply as "the Client". simply as "the Client".
Control Channel: A Control Channel is a reliable connection between Control Channel: A Control Channel is a reliable connection between
a Client and Server that is used to exchange Framework messages. a Client and Server that is used to exchange Framework messages.
The term "Connection" is used synonymously within this document. The term "Connection" is used synonymously within this document.
Framework Message: A Framework Message is a message on a Control Framework Message: A Framework Message is a message on a Control
Channel that has a type corresponding to one of the Methods Channel that has a type corresponding to one of the Methods
defined in this document. A Framework message is often referred defined in this document. A Framework message is often referred
to by its method, such as a "CONTROL message". to by its method, such as a "CONTROL message".
Method: A Method is the type of a framework message. Three Methods Method: A Method is the type of a framework message. Three Methods
are defined in this document: SYNCH, CONTROL, and REPORT. are defined in this document: SYNCH, CONTROL, REPORT, and K-ALIVE.
Control Command: A Control Command is an application level request Control Command: A Control Command is an application level request
from a Client to a Server. Control Commands are carried in the from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in body of CONTROL messages. Control Commands are defined in
separate specifications known as "Control Packages". separate specifications known as "Control Packages".
framework transaction: A framework transaction is defined as a framework transaction: A framework transaction is defined as a
sequence composed of a control framework message originated by sequence composed of a control framework message originated by
either a Control Client or Control Server and responded to with a either a Control Client or Control Server and responded to with a
control Framework response code message. Note that the control control Framework response code message. Note that the control
framework has no "provisional" responses. A control framework framework has no "provisional" responses. A control framework
transaction MUST complete within Transaction-Timeout time. transaction MUST complete within Transaction-Timeout time.
extended framework transaction: An extended framework transaction is extended framework transaction: An extended framework transaction is
used to extend the lifetime of a CONTROL method transaction when used to extend the lifetime of a CONTROL method transaction when
the Control Command it carries cannot be completed within Command- the Control Command it carries cannot be completed within Command-
Timeout milliseconds. A Server extends the lifetime of a CONTROL Timeout milliseconds. A Server extends the lifetime of a CONTROL
method transaction by sending a 202 response code followed by one method transaction by sending a 202 response code followed by one
or more REPORT transactions as specified in Section 7.1.2. or more REPORT transactions as specified in Section 8.1.2.
Extended framework transactions allow command failures to be Extended framework transactions allow command failures to be
discovered at the transaction layer. discovered at the transaction layer.
Transaction-Timeout: the maximum allowed time between a control Transaction-Timeout: the maximum allowed time between a control
Client or Server issuing a framework message and receiving a Client or Server issuing a framework message and receiving a
corresponding response. The value for the timeout should be based corresponding response. The value for the timeout should be based
on a multiple of the network RTT plus Command-Timeout milliseconds on a multiple of the network RTT plus Command-Timeout milliseconds
to allow for message parsing and processing. to allow for message parsing and processing.
[timm: Do we want to differentiate between Control and Report
transaction times - the latter does need to allow for command
processing. Do we even need a transaction time for REPORT
messages or is it sufficient to simply have transaction times for
CONTROL messages and rely on TCP for REPORT?] What about SYNCH?
It currently has its own independent timing.
3. Overview 3. Overview
This document details mechanisms for establishing, using, and This document details mechanisms for establishing, using, and
terminating a reliable channel using SIP for the purpose of terminating a reliable channel using SIP for the purpose of
controlling an external server. The following text provides a non- controlling an external server. The following text provides a non-
normative overview of the mechanisms used. Detailed, normative normative overview of the mechanisms used. Detailed, normative
guidelines are provided later in the document. guidelines are provided later in the document.
Control channels are negotiated using standard SIP mechanisms that Control channels are negotiated using standard SIP mechanisms that
would be used in a similar manner to creating a SIP voice session. would be used in a similar manner to creating a SIP voice session.
skipping to change at page 6, line 41 skipping to change at page 6, line 34
o Security mechanisms - Leverage established security mechanisms o Security mechanisms - Leverage established security mechanisms
such as Transport Layer Security (TLS) and Client Authentication. such as Transport Layer Security (TLS) and Client Authentication.
o Connection maintenance - The ability to re-negotiate a connection, o Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, audit parameters, and so forth. ensure it is active, audit parameters, and so forth.
o Agnostic - Generic protocol allows for easy extension. o Agnostic - Generic protocol allows for easy extension.
As mentioned in the previous list, one of the main benefits of using As mentioned in the previous list, one of the main benefits of using
SIP as the session control protocol is the "Service Location" SIP as the session control protocol is the "Service Location"
facilities provided. This applies at both a routing level, where RFC facilities provided. This applies at both a routing level, where RFC
3263 [4] provides the physical location of devices, and at the 3263 [4] provides the physical location of devices, and at the
Service level, using Caller Preferences[12] and Callee Service level, using Caller Preferences[13] and Callee
Capabilities[13]. The ability to select a Control Server based on Capabilities[14]. The ability to select a Control Server based on
Service level capabilities is extremely powerful when considering a Service level capabilities is extremely powerful when considering a
distributed, clustered architecture containing varying services (for distributed, clustered architecture containing varying services (for
example Voice, Video, IM). More detail on locating Control Server example Voice, Video, IM). More detail on locating Control Server
resources using these techniques is outlined in Section 5 of this resources using these techniques is outlined in Section 5 of this
document. document.
+--------------SIP Traffic--------------+ +--------------SIP Traffic--------------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
skipping to change at page 7, line 15 skipping to change at page 7, line 4
+--------------SIP Traffic--------------+ +--------------SIP Traffic--------------+
| | | |
v v v v
+-----+ +--+--+ +-----+ +--+--+
| SIP | | SIP | | SIP | | SIP |
|Stack| |Stack| |Stack| |Stack|
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Control | | Control | | Control | | Control |
| Client |<----Control Channel---->| Server | | Client |<----Control Channel---->| Server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Basic Architecture Figure 1: Basic Architecture
The example from Figure 1 conveys a 1:1 connection between the The example from Figure 1 conveys a 1:1 connection between the
Control Client and the Control Server. It is possible, if required, Control Client and the Control Server. It is possible, if required,
for multiple control channels using separate SIP dialogs to be for multiple control channels using separate SIP dialogs to be
established between the Control Client and the Control Server established between the Control Client and the Control Server
entities. Any of the connections created between the two entities entities. Any of the connections created between the two entities
can then be used for Server control interactions. The control can then be used for Server control interactions. The control
connections are agnostic to any media sessions. Specific media connections are agnostic to any media sessions. Specific media
session information can be incorporated in control interaction session information can be incorporated in control interaction
commands (which themselves are defined in external packages) using commands (which themselves are defined in external packages) using
the XML schema defined in Section 16. The ability to have multiple the XML schema defined in Section 17. The ability to have multiple
control channels allows for stronger redundancy and the ability to control channels allows for stronger redundancy and the ability to
manage high volumes of traffic in busy systems. manage high volumes of traffic in busy systems.
[Editors Note: Still under discussion. How does an app server know, [Editors Note: Still under discussion. How does an app server know,
when there are multiple external servers, which specific server has when there are multiple external servers, which specific server has
any given media session? Next version of the draft will discuss the any given media session? Next version of the draft will discuss the
correlation procedures. The App server needs a control channel with correlation procedures. The App server needs a control channel with
the media server and needs to know which channel to use once the the media server and needs to know which channel to use once the
media session has been established. Sounds like a GRUU usage?] media session has been established. Sounds like a GRUU usage?]
skipping to change at page 11, line 35 skipping to change at page 11, line 26
The first "sub-field" <media> MUST equal the value "application". The first "sub-field" <media> MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the The second sub-field, <port>, MUST represent a port on which the
constructing client can receive an incoming connection if required. constructing client can receive an incoming connection if required.
The port is used in combination with the address specified in the The port is used in combination with the address specified in the
'Connection Data line defined previously to supply connection 'Connection Data line defined previously to supply connection
details. If the constructing client can't receive incoming details. If the constructing client can't receive incoming
connections it MUST still enter a valid port range entry. The use of connections it MUST still enter a valid port range entry. The use of
the port value '0' has the same meaning as defined in the SDP the port value '0' has the same meaning as defined in the SDP
specification[9]. The third sub-field, <proto>, MUST equal the value specification[9]. The third sub-field, <proto>, MUST equal the value
"TCP/ESCS" as defined in Section 14.3.2 of this document. "TCP/ESCS" as defined in Section 15.3.2 of this document.
[Editors note: Need to cover other protocols so not TCP specific] [Editors note: Need to cover other protocols so not TCP specific]
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 specification. The are specifically defined in the COMEDIA specification. The
attributes provide connection negotiation and maintenance parameters. attributes provide connection negotiation and maintenance parameters.
A client conforming to this specification SHOULD support all the A client conforming to this specification SHOULD support all the
possible values defined for media attributes from the COMEDIA [6] possible values defined for media attributes from the COMEDIA [6]
specification but MAY choose not to support values if it can specification but MAY choose not to support values if it can
definitely determine they will never be used (for example will only definitely determine they will never be used (for example will only
skipping to change at page 12, line 38 skipping to change at page 12, line 30
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 [10], for media label attribute (B2BUA functionality), as defined in [10], for
each "m=" definition. A Control Client constructing the SDP MAY each "m=" definition. A Control Client constructing the SDP MAY
choose not to include the media label SDP attribute if it does not choose not to include the media label SDP attribute if it does not
require direct control on a per media stream basis. require direct control on a per media stream basis.
This framework identifies the common re-use of referencing media This framework identifies the common re-use of referencing media
dialogs and has specified a connection reference attribute that can dialogs and has specified a connection reference attribute that can
optionally be imported into any Control Package. It is intended that optionally be imported into any Control Package. It is intended that
this will reduce repetitive specifying of dialog reference language. this will reduce repetitive specifying of dialog reference language.
The schema can be found in Section 16.1 in Appendix A. The schema can be found in Section 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
media dialogs is also identified as a common structure that could be media dialogs is also identified as a common structure that could be
defined and re-used (for example playing a prompt to all participants defined and re-used (for example playing a prompt to all participants
in a Conference). The schema for such operations can also be found in a Conference). The schema for such operations can also be found
in Section 16.1 in Appendix A. 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 9. part of each Control Package definition, as detailed in Section 10.
6. Control Server SIP UAS Behavior - Control Channel Setup 6. Control Server SIP UAS Behavior - Control Channel Setup
On receiving a SIP INVITE request, an external Server(UAS) inspects On receiving a SIP INVITE request, an external Server(UAS) inspects
the message for indications of support for the mechanisms defined in the message for indications of support for the mechanisms defined in
this specification. This is achieved through the presence of the SIP this specification. This is achieved through the presence of the SIP
Supported and Require headers containing the option tag 'escs'. If Supported and Require headers containing the option tag 'escs'. If
the external Server wishes to construct a reliable response that the external Server wishes to construct a reliable response that
conveys support for the extension, it should follow the mechanisms conveys support for the extension, it should follow the mechanisms
defined in RFC 3261 [2] for responding to SIP supported and Require defined in RFC 3261 [2] for responding to SIP supported and Require
skipping to change at page 13, line 33 skipping to change at page 13, line 22
a=setup:passive a=setup:passive
a=connection:new a=connection:new
Once the SIP success response has been constructed, it is sent using Once the SIP success response has been constructed, it is sent using
standard SIP mechanisms. Depending on the contents of the SDP standard SIP mechanisms. Depending on the contents of the SDP
payloads that were negotiated using the Offer/Answer exchange, a payloads that were negotiated using the Offer/Answer exchange, a
reliable connection will be established between the Controlling UAC reliable connection will be established between the Controlling UAC
and external Server UAS entities. The connection is now available to and external Server UAS entities. The connection is now available to
exchange commands, as defined in "Control Packages" and described in exchange commands, as defined in "Control Packages" and described in
Section 9. The state of the SIP Dialog and the associated Control Section 10. The state of the SIP Dialog and the associated Control
channel are now explicitly linked. If either party wishes to channel are now explicitly linked. If either party wishes to
terminate a Control channel is simply issues a SIP termination terminate a Control channel is simply issues a SIP termination
request (SIP BYE request). The Control Channel therefore lives for request (SIP BYE request). The Control Channel therefore lives for
the duration of the SIP dialog. the duration of the SIP dialog.
If the UAS does not support the extension contained in a SIP If the UAS does not support the extension contained in a SIP
Supported or Require header it MUST respond as detailed in RFC 3261 Supported or Require header it MUST respond as detailed in RFC 3261
[2]. If the UAS does support the SIP extension contained in a SIP [2]. If the UAS does support the SIP extension contained in a SIP
Require or Supported header but does not support one or more of the Require or Supported header but does not support one or more of the
Control packages, as represented in the "Control-Packages" SIP Control packages, as represented in the "Control-Packages" SIP
skipping to change at page 14, line 14 skipping to change at page 14, line 5
A SIP entity receiving a SIP OPTIONS request MUST respond A SIP entity receiving a SIP OPTIONS request MUST respond
appropriately as defined in RFC 3261 [2]. This involves providing appropriately as defined in RFC 3261 [2]. This involves providing
information relating to supported SIP extensions in the 'Supported' information relating to supported SIP extensions in the 'Supported'
message header. For this extension a value of 'escs' MUST be message header. For this extension a value of 'escs' MUST be
included. Additionally, a SIP entity MUST include all the additional included. Additionally, a SIP entity MUST include all the additional
control packages that are associated with the Control channel. This control packages that are associated with the Control channel. This
is achieved by including a 'Control-Packages' SIP message header is achieved by including a 'Control-Packages' SIP message header
listing all relevant supported Control package tokens. listing all relevant supported Control package tokens.
7. Control Framework Interactions 7. Control Channel Keep-Alive
It is reasonable to expect this document to be used in various
network architectures. This will include a wide range of deployments
where the clients could be co-located in a secured, private domain or
spread across disparate domains that require traversal of devices
such as Network Address Translators (NAT) and Firewalls (which is
covered in Section 11). It is important, therefore, that this
document provides a 'keep-alive' mechanism that enables the control
channel being created to firstly be kept active during times of
inactivity (most Firewalls have a timeout period after which
connections are closed) and also provide the ability for application
level failure detection. It should be noted at this point that the
following procedures apply explicitly to the control channel being
created and for details relating to a SIP keep-alive mechanism
implementers should seek guidance from SIP Outbound [11]. The
following 'keep-alive' procedures SHOULD be implemented by all
entities but MAY NOT be implemented if it can be guaranteed that
deployments will only occur with entities in a co-located domain. It
should be noted that choosing to not implement the 'keep-alive'
mechanism in this section, even when in a co-located architecture,
will reduce the ability to detect application level errors -
especially during long periods of in-activity.
7.1. Timeout Negotiation
During the SIP dialog negotiation the clients will also negotiate a
timeout period for the control channel 'keep-alive' mechanism. The
following rules MUST be obeyed in conjunction with COMEDIA[6]:
o If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'active', the 'k-alive' 'Control-
Packages' SIP header parameter MUST be included. The value of the
'k-alive' header parameter SHOULD be in the range of 95 and 120
seconds (this is consistent with SIP Outbound[11]). The client
generating the subsequent answer ('passive' client) MUST copy the
'k-alive' 'Control-Packages' header parameter into the response
with the same value.
o If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'passive', the 'k-alive' Control-
Packages SIP header parameter MUST NOT be included. The client
generating the subsequent answer ('active' client) MUST include
the 'k-alive' header parameter. The value of the 'k-alive' header
parameter SHOULD be in the range of 95 and 120 seconds.
o If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'actpass', the 'k-alive' 'Control-
Packages' header parameter MUST be included. The value of the
'k-alive' header parameter SHOULD be in the range of 95 to 120
seconds. If the client generating the subsequent answer places a
value of 'active' in the COMEDIA 'setup' attribute, It MUST
include a 'k-alive' header parameter and MAY choose a value that
is different from that received in the request. The value SHOULD
be in the range 95 to 120 seconds. If the client generating the
subsequent answer places a value of 'passive' in the COMDEDIA
'setup' attribute, it MUST copy the 'k-alive' header and value
from the request into the 'k-alive' 'Control-Packages' SIP header
parameter.
o The 'Control-Packages' 'k-alive' header parameter MUST not be
included when the COMEDIA 'setup' attribute is equal to
'holdconn'.
o Following the previous steps ensures that the entity initiating
the control channel connection is always the one specifying the
keep-alive timeout period. It will always be the initiator of the
connection who generates the 'K-ALIVE' Control Framework level
messages. The following section describes in more detail how to
generate the Control Framework 'K-ALIVE' message.
7.2. Generating Keep-Alive Messages
Once the SIP dialog has been established using the offer answer
mechanism and the control channel has been established (including the
initial identity handshake using SYNCH as discussed in section
Section 8), both the 'active' and 'passive' (as defined in
COMEDIA[6]) clients MUST start a keep-alive timer equal to the value
negotiated during the offer/answer exchange (from the 'k-alive'
'Control-Packages' SIP header parameter).
When acting as an 'active' client, a 'K-ALIVE' Control Framework
message MUST be generated before the local 'keep-alive' timer fires.
An active client is free to send the K-ALIVE Control Framework
message when ever it chooses. A guideline of 80% of the local 'keep-
alive' timer is suggested. The 'passive' client MUST generate a 200
OK Control Framework response to the K-ALIVE message and reset the
local 'keep-alive' timer. No other Control Framework response is
valid. On receiving the 200 OK Control Framework message, the
'active' client MUST reset the local 'keep-alive' timer. If no 200
OK response is received to the K-ALIVE Control Framework message,
before the local 'keep-alive' timer fires, the 'active' client SHOULD
tear down the SIP dialog and recover the associated control channel
resources. The 'active' client MAY choose to try and recover the
connection by renegotiation using COMEDIA.
When acting as a 'passive' client, a 'K-ALIVE' Control Framework
message MUST be received before the local 'keep-alive' timer fires.
The 'passive' client MUST generate a 200 OK control framework
response to the K-ALIVE Control Framework message. On sending the
200 OK response, the 'passive' client MUST reset the local 'keep-
alive' timer. If no K-ALIVE message is received before the local
'keep-alive' timer fires, the 'passive' client SHOULD tear down the
SIP dialog and recover the associated control channel resources. The
'active' client MAY try to and recover the connection by
renegotiating using COMEDIA.
8. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of the Control Channel to be set up in either direction as a result of the
SIP INVITE transaction. While providing a flexible negotiation SIP INVITE transaction. While providing a flexible negotiation
mechanism, it does provide certain correlation problems between the mechanism, it does provide certain correlation problems between the
channel and the overlying SIP dialog. Remember that the two are channel and the overlying SIP dialog. Remember that the two are
implicitly linked and so need a robust correlation mechanism. A implicitly linked and so need a robust correlation mechanism. A
Control Client receiving an incoming connection (whether it be acting Control Client receiving an incoming connection (whether it be acting
in the role of UAC or UAS) has no way of identifying the associated in the role of UAC or UAS) has no way of identifying the associated
SIP dialog as it could be simply listening for all incoming SIP dialog as it could be simply listening for all incoming
connections on a specific port. As a consequence, some rules are connections on a specific port. As a consequence, some rules are
applied to allow a connecting (defined as 'active' role in COMEDIA) applied to allow a connecting (defined as 'active' role in COMEDIA)
client to identify the associated SIP dialog that triggered the client to identify the associated SIP dialog that triggered the
connection. The following steps provide an identification mechanism connection. The following steps provide an identification mechanism
that MUST be carried out before any other signaling is carried out on that MUST be carried out before any other signaling is carried out on
the newly created Control channel. the newly created Control channel.
o Once connected, the client initiating the connection (as o Once connected, the client initiating the connection (as
determined by COMEDIA) MUST immediately send a Control Framework determined by COMEDIA) MUST immediately send a Control Framework
SYNCH request. The SYNCH request will be constructed as defined SYNCH request. The SYNCH request will be constructed as defined
in Section 11.2 and MUST only contain one message header, in Section 12.2 and MUST only contain one message header,
'dialog-id', which contains the SIP dialog information. 'dialog-id', which contains the SIP dialog information.
o The 'dialog-id' message header is constructed by concatenating the o The 'dialog-id' message header is constructed by concatenating the
Local-tag, Call-ID and Remote-tag (as defined in Section 11.2) Local-tag, Call-ID and Remote-tag (as defined in Section 12.2)
from the SIP dialog and separating with a '~'. See syntax defined from the SIP dialog and separating with a '~'. See syntax defined
in Section 16.1 in Appendix A and examples in Section 9.6. For in Section 17.1 in Appendix A and examples in Section 10.6. For
example, if the SIP dialog had values of 'Local-tag=HKJDH', example, if the SIP dialog had values of 'Local-tag=HKJDH',
'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the 'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the
'dialog-id' header would look like this: 'dialog-id' header would look like this:
'dialog-id=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'. 'dialog-id=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'.
o The client who initiated the connection MUST then send the SYNCH o The client who initiated the connection MUST then send the SYNCH
request. It should then wait for a period of 5 seconds to receive request. It should then wait for a period of 5 seconds to receive
a response. It MAY choose a longer time to wait but it should not a response. It MAY choose a longer time to wait but it should not
be shorter than 5 seconds. be shorter than 5 seconds.
o If no response is received for the SYNCH control message, a o If no response is received for the SYNCH control message, a
timeout occurs and the control channel is terminated along with timeout occurs and the control channel is terminated along with
skipping to change at page 15, line 28 skipping to change at page 17, line 23
Once a successful control channel has been established, as defined in Once a successful control channel has been established, as defined in
Section 5 and Section 6 (and the connection has been correlated, as Section 5 and Section 6 (and the connection has been correlated, as
described in previous paragraph), the two entities are now in a described in previous paragraph), the two entities are now in a
position to exchange relevant control framework messages. The position to exchange relevant control framework messages. The
remainder of this section provides details of the core set of methods remainder of this section provides details of the core set of methods
and responses that MUST be supported for the core control framework. and responses that MUST be supported for the core control framework.
Future extensions to this document MAY define new methods and Future extensions to this document MAY define new methods and
responses. responses.
7.1. Constructing Requests 8.1. Constructing Requests
An entity acting as a Control Client is now able to construct and An entity acting as a Control Client is now able to construct and
send new requests on a control channel and MUST adhere to the syntax send new requests on a control channel and MUST adhere to the syntax
defined in Section 11. Control Commands MUST also adhere to the defined in Section 12. Control Commands MUST also adhere to the
syntax defined by the Control Packages negotiated in Section 5 and syntax defined by the Control Packages negotiated in Section 5 and
Section 6 of this document. A Control Client MUST create a unique Section 6 of this document. A Control Client MUST create a unique
transaction and associated identifier per request transaction. The transaction and associated identifier per request transaction. The
transaction identifier is then included in the first line of a transaction identifier is then included in the first line of a
control framework message along with the method type (as defined in control framework message along with the method type (as defined in
the ABNF in Section 11). The first line starts with the SCFW token the ABNF in Section 12). The first line starts with the SCFW token
for the purpose of easily extracting the transaction identifier. The for the purpose of easily extracting the transaction identifier. The
transaction identifier MUST be globally unique over space and time. transaction identifier MUST be globally unique over space and time.
All required mandatory and optional control framework headers are All required mandatory and optional control framework headers are
then inserted into the control message with appropriate values (see then inserted into the control message with appropriate values (see
relevant individual header information for explicit detail). A relevant individual header information for explicit detail). A
"Control-Package" header MUST also be inserted with the value "Control-Package" header MUST also be inserted with the value
indicating the Control Package to which this specific request applies indicating the Control Package to which this specific request applies
(Multiple packages can be negotiated per control channel). (Multiple packages can be negotiated per control channel).
Any framework message that contains an associated payload MUST also Any framework message that contains an associated payload MUST also
include a 'Content-Length' message header which represents the size include a 'Content-Length' message header which represents the size
of the message body in decimal number of octets. If no associated of the message body in decimal number of octets. If no associated
payload is to be added to the message, a 'Content-Length' header with payload is to be added to the message, a 'Content-Length' header with
a value of '0' MUST be included. a value of '0' MUST be included.
When all of the headers have been included in the framework message, When all of the headers have been included in the framework message,
it is sent down the control channel established in Section 5. it is sent down the control channel established in Section 5.
It is a requirement that a Server receiving such a request respond It is a requirement that a Server receiving such a request respond
quickkly with an appropriate response (as defined in Section 7.2). A quickkly with an appropriate response (as defined in Section 8.2). A
Control Client entity needs to wait for Transaction-Time time for a Control Client entity needs to wait for Transaction-Time time for a
response before considering the transaction a failure. response before considering the transaction a failure.
7.1.1. Sending CONTROL 8.1.1. Sending CONTROL
A 'CONTROL' message is used by Control Client to invoke control A 'CONTROL' message is used by Control Client to invoke control
commands on a Control Server. The message is constructed in the same commands on a Control Server. The message is constructed in the same
way as any standard Control Framework message, as discussed way as any standard Control Framework message, as discussed
previously in Section 7.1 and defined in Section 11. A CONTROL previously in Section 8.1 and defined in Section 12. A CONTROL
message MAY contain a message body. The explicit control command(s) message MAY contain a message body. The explicit control command(s)
of the message payload contained in a CONTROL message are specified of the message payload contained in a CONTROL message are specified
in separate Control Package specifications. These specifications in separate Control Package specifications. These specifications
MUST conform to the format defined in Section 9.4. MUST conform to the format defined in Section 10.4.
7.1.2. Sending REPORT 8.1.2. Sending REPORT
A 'REPORT' message is used by a Control Server in two situations. A 'REPORT' message is used by a Control Server in two situations.
The first situation occurs when processing of a Control Command The first situation occurs when processing of a Control Command
extends beyond a Command-Timeout. In this case a 202 response is extends beyond a Command-Timeout. In this case a 202 response is
returned. Status updates and the final results of the command are returned. Status updates and the final results of the command are
then returned in subsequent REPORT messages. The second situation then returned in subsequent REPORT messages. The second situation
allows REPORT to be used as an event notification mechanism where allows REPORT to be used as an event notification mechanism where
events are correlated with the original CONTROL message. In this events are correlated with the original CONTROL message. In this
case, REPORT messages may be sent after the original transaction or case, REPORT messages may be sent after the original transaction or
extended transaction has completed. extended transaction has completed.
All REPORT messages MUST contain the same transaction ID in the All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL request start line that was present in the original CONTROL
transaction. This allows both extended transactions and event transaction. This allows both extended transactions and event
notifications to be correlated with the original CONTROL transaction. notifications to be correlated with the original CONTROL transaction.
7.1.2.1. Reporting the Status of Extended Transactions 8.1.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within On receiving a CONTROL message, a Control Server MUST respond within
Command-Timeout with a status code for the request, as specified in Command-Timeout with a status code for the request, as specified in
Section 7.2. If the command completed within that time, a 200 Section 8.2. If the command completed within that time, a 200
response code would have been sent. If the command did not complete response code would have been sent. If the command did not complete
within that time, the response code 202 would have been sent within that time, the response code 202 would have been sent
indicating that the requested command is still being processed and indicating that the requested command is still being processed and
the CONTROL transaction is being extended. The REPORT method is used the CONTROL transaction is being extended. The REPORT method is used
to update the status of the extended transaction. to update the status of the extended transaction.
A Control Server issuing a 202 response MUST immediately issue a A Control Server issuing a 202 response MUST immediately issue a
REPORT message. The initial REPORT message MUST contain a 'Seq' REPORT message. The initial REPORT message MUST contain a 'Seq'
(Sequence) message header with a value equal to '1' (It should be (Sequence) message header with a value equal to '1' (It should be
noted that the 'Seq' numbers at both Control Client Control Server noted that the 'Seq' numbers at both Control Client Control Server
skipping to change at page 18, line 8 skipping to change at page 20, line 5
When all processing for an extended CONTROL transaction has taken When all processing for an extended CONTROL transaction has taken
place, the entity acting as a Control Server MUST send a terminating place, the entity acting as a Control Server MUST send a terminating
REPORT message. The terminating REPORT message MUST increment the REPORT message. The terminating REPORT message MUST increment the
value in the 'Seq' message header by the value of '1' from the value in the 'Seq' message header by the value of '1' from the
previous REPORT message. It MUST also include a 'Status' header with previous REPORT message. It MUST also include a 'Status' header with
a value of 'terminate' and MAY contain a message body. A Control a value of 'terminate' and MAY contain a message body. A Control
Framework UAC can then clean up any pending state associated with the Framework UAC can then clean up any pending state associated with the
original control transaction. original control transaction.
7.1.2.2. Reporting Asynchronous Events 8.1.2.2. Reporting Asynchronous Events
Commands that are carried in CONTROL messages can request that the Commands that are carried in CONTROL messages can request that the
Server notify the Client about events that occur sometime in the Server notify the Client about events that occur sometime in the
future. It is not desirable to use extended Control transactions for future. It is not desirable to use extended Control transactions for
these types of commands for two reasons. First, an event never these types of commands for two reasons. First, an event never
occurring is often correct behavior. Second, events may occur long occurring is often correct behavior. Second, events may occur long
after the original request for their notification. after the original request for their notification.
REPORT messages can be used to notify events. REPORT messages that REPORT messages can be used to notify events. REPORT messages that
notify events MUST contain a 'Status' header of 'Notify'. They MUST notify events MUST contain a 'Status' header of 'Notify'. They MUST
NOT contain either a 'Timeout' or 'Seq' header and any such headers NOT contain either a 'Timeout' or 'Seq' header and any such headers
MUST be ignored when the REPORT message has a 'Status' of 'notify'. MUST be ignored when the REPORT message has a 'Status' of 'notify'.
The REPORT message MAY contain a message body. The REPORT message MAY contain a message body.
7.2. Constructing Responses 8.2. Constructing Responses
A Control Client or Server, on receiving a request, MUST generate a A Control Client or Server, on receiving a request, MUST generate a
response within Command-Time time. The response MUST conform to the response within Command-Time time. The response MUST conform to the
ABNF defined in Section 11. The first line of the response MUST ABNF defined in Section 12. The first line of the response MUST
contain the transaction identifier used in first line of the request, contain the transaction identifier used in first line of the request,
as defined in Section 7.1. Responses MUST NOT include the 'Status' as defined in Section 8.1. Responses MUST NOT include the 'Status'
or 'Timeout' message headers - if they are included they have no or 'Timeout' message headers - if they are included they have no
meaning or semantics. meaning or semantics.
A Control Client or Server MUST then include a status code in the A Control Client or Server MUST then include a status code in the
first line of the constructed response. A CONTROL request that has first line of the constructed response. A CONTROL request that has
been understood, and either the relevant actions for the control been understood, and either the relevant actions for the control
command have completed or a control command error is detected, uses command have completed or a control command error is detected, uses
the 200 status code as defined in Section 8.1. A 200 response MAY the 200 status code as defined in Section 9.1. A 200 response MAY
include message bodies. If a 200 response does contain a payload it include message bodies. If a 200 response does contain a payload it
MUST include a Content-Length header. A 200 is the only response MUST include a Content-Length header. A 200 is the only response
defined in this specification that allows a message body to be defined in this specification that allows a message body to be
included. A client receiving a 200 class response then considers the included. A client receiving a 200 class response then considers the
control command completed. A CONTROL request that is received and control command completed. A CONTROL request that is received and
understood but requires processing that extends beyond Command-Time understood but requires processing that extends beyond Command-Time
time will return a 202 status code in the response. This will be time will return a 202 status code in the response. This will be
followed immediately by an initial REPORT message as defined in followed immediately by an initial REPORT message as defined in
Section 7.1.2. A Control Package SHOULD explicitly define the Section 8.1.2. A Control Package SHOULD explicitly define the
circumstances under which either 200 or 202 with subsequent circumstances under which either 200 or 202 with subsequent
processing takes place. processing takes place.
If a Control Client or Server encounters problems with either a If a Control Client or Server encounters problems with either a
REPORT or CONTROL request, an appropriate error code should be used REPORT or CONTROL request, an appropriate error code should be used
in the response, as listed in Section 8. The generation of a non 2xx in the response, as listed in Section 9. The generation of a non 2xx
class response code to either a CONTROL or REPORT message will result class response code to either a CONTROL or REPORT message will result
in failure of the transaction, and all associated state and resources in failure of the transaction, and all associated state and resources
should be terminated. The response code may provide an explicit should be terminated. The response code may provide an explicit
indication of why the transaction failed, which might result in a re- indication of why the transaction failed, which might result in a re-
submission of the request. submission of the request.
[timm]: how can an error response provide an explicit indication of [timm]: how can an error response provide an explicit indication of
the reason for the transaction failure when only a 200 response the reason for the transaction failure when only a 200 response
allows message bodies? allows message bodies?
8. Response Code Descriptions 9. Response Code Descriptions
The following response codes are defined for transaction responses to The following response codes are defined for transaction responses to
methods defined in Section 7.1. All response codes in this section methods defined in Section 8.1. All response codes in this section
MUST be supported and can be used in response to both CONTROL and MUST be supported and can be used in response to both CONTROL and
REPORT messages except that a 202 MUST NOT be generated in response REPORT messages except that a 202 MUST NOT be generated in response
to a REPORT message. to a REPORT message.
Note that these response codes apply to framework transactions only. Note that these response codes apply to framework transactions only.
Success or error indications for control commands MUST be treated as Success or error indications for control commands MUST be treated as
the result of a control command and returned in either a 200 response the result of a control command and returned in either a 200 response
or REPORT message. or REPORT message.
8.1. 200 Response Code 9.1. 200 Response Code
The 200 code indicates the completion of a successful transaction. The 200 code indicates the completion of a successful transaction.
8.2. 202 Response Code 9.2. 202 Response Code
The 202 response code indicates the completion of a successful The 202 response code indicates the completion of a successful
transaction with additional information to be provided at a later transaction with additional information to be provided at a later
time through the REPORT mechanism defined in Section 7.1.2. time through the REPORT mechanism defined in Section 8.1.2.
8.3. 400 Response Code 9.3. 400 Response Code
The 400 response indicates that the request was syntactically The 400 response indicates that the request was syntactically
incorrect. incorrect.
8.4. 403 Response Code 9.4. 403 Response Code
The 400 response indicates that the requested operation is illegal. The 400 response indicates that the requested operation is illegal.
8.5. 481 Response Code 9.5. 481 Response Code
The 481 response indicates that the intended target of the request The 481 response indicates that the intended target of the request
does not exist. does not exist.
8.6. 500 Response Code 9.6. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
request request
9. Control Packages 10. Control Packages
"Control Packages" are intended to specify behavior that extends the "Control Packages" are intended to specify behavior that extends the
the capability defined in this document. "Control Packages" are not the capability defined in this document. "Control Packages" are not
allowed to weaken "MUST" and "SHOULD" strength statements that are allowed to weaken "MUST" and "SHOULD" strength statements that are
detailed in this document. A "Control Package" may strengthen detailed in this document. A "Control Package" may strengthen
"SHOULD" to "MUST" if justified by the specific usage of the "SHOULD" to "MUST" if justified by the specific usage of the
framework. framework.
In addition to normal sections expected in a standards-track RFC and In addition to normal sections expected in a standards-track RFC and
SIP extension documents, authors of "Control Packages" need to SIP extension documents, authors of "Control Packages" need to
address each of the issues detailed in the following subsections. address each of the issues detailed in the following subsections.
The following sections MUST be used as a template and included The following sections MUST be used as a template and included
appropriately in all Control-Packages. appropriately in all Control-Packages.
9.1. Control Package Name 10.1. Control Package Name
This section MUST be present in all extensions to this document and This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the include information that appears in the IANA registration of the
token. Information on registering control package event tokens is token. Information on registering control package event tokens is
contained in Section 14. The package name MUST also register a contained in Section 15. The package name MUST also register a
version number for the package. This enables updates to the package version number for the package. This enables updates to the package
to be registered where appropriate. An initial version of a package to be registered where appropriate. An initial version of a package
MUST start with the value '1.0'. Subsequent versions MUST increment MUST start with the value '1.0'. Subsequent versions MUST increment
this number if the same package name is to be used. The exact this number if the same package name is to be used. The exact
increment is left to the discretion of the package author. increment is left to the discretion of the package author.
9.2. Framework Message Usage 10.2. Framework Message Usage
The Control Framework defines a number of message primitives that can The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no be used to exchange commands and information. There are no
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document should control channel. This section of a Control package document should
explicitly detail the control messages that can be used as well as explicitly detail the control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. include which role type is allowed to initiate a request type.
[Editors Note: Need to examine text.] [Editors Note: Need to examine text.]
9.3. Common XML Support 10.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required. attributes for media dialog or Conference reference are required.
The Control Package will make strong statements (MUST strength) if The Control Package will make strong statements (MUST strength) if
the XML schema defined in Section 16.1 in Appendix A is to be the XML schema defined in Section 17.1 in Appendix A is to be
supported. If only part of the schema is required (for example just supported. If only part of the schema is required (for example just
'connection-id' or just conf-id), the Control Package will make 'connection-id' or just conf-id), the Control Package will make
equally strong (MUST strength) statements. equally strong (MUST strength) statements.
9.4. CONTROL Message Bodies 10.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 7 (or that no control package body is required). This Section 8 (or that no control package body is required). This
section should indicate the location of detailed syntax definitions section should indicate the location of detailed syntax definitions
and semantics for the appropriate body types. and semantics for the appropriate body types.
9.5. REPORT Message Bodies 10.5. REPORT Message Bodies
This mandatory section of a Control Package defines the REPORT body This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in that can be contained within a REPORT command request, as defined in
Section 7 (or that no report package body is required). This section Section 8 (or that no report package body is required). This section
should indicate the location of detailed syntax definitions and should indicate the location of detailed syntax definitions and
semantics for the appropriate body types. It should be noted that semantics for the appropriate body types. It should be noted that
the Control Framework specification does allow for payloads to exist the Control Framework specification does allow for payloads to exist
in 200 responses to CONTROL messages (as defined in this document). in 200 responses to CONTROL messages (as defined in this document).
An entity that is prepared to receive a payload type in a REPORT An entity that is prepared to receive a payload type in a REPORT
message MUST also be prepared to receive the same payload in a 200 message MUST also be prepared to receive the same payload in a 200
response to a CONTROL message. response to a CONTROL message.
9.5.1. Events 10.5.1. Events
A Control Package can optionally include one or more subscriptions A Control Package can optionally include one or more subscriptions
that allow a controlling client to receive specific event updates in that allow a controlling client to receive specific event updates in
REPORT message bodies. The mechanisms that installs/un-installs REPORT message bodies. The mechanisms that installs/un-installs
subscriptions is not specified in document and is considered out of subscriptions is not specified in document and is considered out of
scope. Event notifications are always carried in REPORT messages scope. Event notifications are always carried in REPORT messages
MUST conform to the rules detailed in Section 7.1.2.2. This section MUST conform to the rules detailed in Section 8.1.2.2. This section
of a Control Package definition MUST specify details of the payload of a Control Package definition MUST specify details of the payload
expected to be received from subscriptions that have been installed. expected to be received from subscriptions that have been installed.
[Editors Note: Ongoing discussions relating to a generic [Editors Note: Ongoing discussions relating to a generic
subscription/event mechanism across all packages.] subscription/event mechanism across all packages.]
9.6. Examples 10.6. Examples
It is strongly RECOMMENDED that Control Packages provide a range of It is strongly RECOMMENDED that Control Packages provide a range of
message flows that represent common flows using the package and this message flows that represent common flows using the package and this
framework document. framework document.
10. Network Address Translation (NAT) 11. Network Address Translation (NAT)
[Editors Note: This section will look at geographically distributed [Editors Note: This section will look at geographically distributed
systems where NAT traversal might be an issue. It will look at both systems where NAT traversal might be an issue. It will look at both
the SIP media dialog traversal and the control channel traversal.] the SIP media dialog traversal and the control channel traversal.]
11. Formal Syntax 12. Formal Syntax
11.1. SIP Formal Syntax 12.1. SIP Formal Syntax
The ABNF for the "Control-Packages" SIP header is as follows: The ABNF for the "Control-Packages" SIP header is as follows:
Control-Packages = "Control-Packages" HCOLON control-package-value Control-Packages = "Control-Packages" HCOLON control-package-value
*(COMMA control-package-value) *(COMMA control-package-value) *( SEMI package-params )
control-package-value = control-package-name "/" control-package-version control-package-value = control-package-name "/" control-package-version
control-package-name = token control-package-name = token
control-package-version = 1*DIGIT "." 1*DIGIT control-package-version = 1*DIGIT "." 1*DIGIT
package-params = k-alive-param *(SEMI extension-param)
k-alive-param = "keep-alive" EQUAL delta-seconds
delta-seconds = 1*DIGIT
extension-param = generic-param
11.2. Control Framework Formal Syntax 12.2. 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 [15]. The syntax in this section uses format as defined in RFC3629 [16]. The syntax in this section uses
the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [16]. the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [17].
control-req-or-resp = control-request / control-response control-req-or-resp = control-request / control-response
control-request = control-req-start headers [control-content] control-request = control-req-start headers [control-content]
control-response = control-resp-start headers control-response = control-resp-start headers
control-req-start = pSCFW SP transact-id SP method CRLF control-req-start = pSCFW SP transact-id SP method CRLF
control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pSCFW = %x53.43.46.57; SCFW in caps pSCFW = %x53.43.46.57; SCFW in caps
transact-id = alpha-num-token transact-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNCH / other-method method = mCONTROL / mREPORT / mSYNCH / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNCH = %x53.59.4E.43.48; SYNCH in caps mSYNCH = %x53.59.4E.43.48; SYNCH in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this and other documents status-code = 3DIGIT ; any code defined in this and other documents
headers = Content-Length headers = Content-Length
/Control-Package /Control-Package
/Status /Status
/Seq /Seq
/Timeout /Timeout
/Dialog-id /Dialog-id
/ext-header /ext-header
skipping to change at page 25, line 5 skipping to change at page 27, line 16
___________________________________________________ ___________________________________________________
Content-Length o o - Content-Length o o -
Control-Package R m - - Control-Package R m - -
Seq - m - Seq - m -
Status R - m - Status R - m -
Timeout R - m - Timeout R - m -
Dialog-id R - - m Dialog-id R - - m
Figure 11: Table 1 Figure 11: Table 1
12. Examples 13. Examples
The following examples provide an abstracted flow of Control Channel The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document. Control Framework interactions defined in this document.
Control Client Control Server Control Client Control Server
| | | |
| (1) SIP INVITE | | (1) SIP INVITE |
| ----------------------------------------> | | ----------------------------------------> |
skipping to change at page 29, line 32 skipping to change at page 32, line 5
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774 To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498 From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE CSeq: 2 BYE
Require: escs Require: escs
Control-Packages: <example-package> Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
13. Security Considerations 14. Security Considerations
Security Considerations to be included in later versions of this Security Considerations to be included in later versions of this
document. document.
14. IANA Considerations 15. IANA Considerations
14.1. IANA Registration of the 'escs' Option Tag 15.1. IANA Registration of the 'escs' Option Tag
14.2. Control Package Registration Information 15.2. Control Package Registration Information
14.2.1. Control Package Registration Template 15.2.1. Control Package Registration Template
14.3. SDP Transport Protocol 15.3. SDP Transport Protocol
14.3.1. TCP/ESCS 15.3.1. TCP/ESCS
14.3.2. TCP/TLS/ESCS
14.4. SDP Attribute Names 15.3.2. TCP/TLS/ESCS
14.5. SIP Response Codes 15.4. SDP Attribute Names
15. Acknowledgments 15.5. SIP Response Codes
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 Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for
useful review and input to this work. Eric Burger contributed to the useful review and input to this work. Eric Burger contributed to the
early phases of this work. early phases of this work.
16. 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.
16.1. Common Dialog/Multiparty Reference Schema 17.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing The following schema provides some common attributes for allowing
Control Packages to apply specific commands to a particular SIP media Control Packages to apply specific commands to a particular SIP media
dialog (also referred to as Connection) or conference. If used dialog (also referred to as Connection) or conference. If used
within a Control Package the Connection and multiparty attributes within a Control Package the Connection and multiparty attributes
will be imported and used appropriately to specifically identify will be imported and used appropriately to specifically identify
either a SIP dialog or a conference instance. If used within a either a SIP dialog or a conference instance. If used within a
package, the value contained in the 'connection-id' attribute MUST be package, the value contained in the 'connection-id' attribute MUST be
constructed by concatenating the 'Local' and 'Remote' SIP dialog constructed by concatenating the 'Local' and 'Remote' SIP dialog
identifier tags as defined in RFC3261 [2]. They MUST then be identifier tags as defined in RFC3261 [2]. They MUST then be
skipping to change at page 32, line 23 skipping to change at page 34, line 28
<xsd:annotation> <xsd:annotation>
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation> <xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="connection-id" type="xsd:string"/> <xsd:attribute name="connection-id" type="xsd:string"/>
<xsd:attribute name="conf-id" type="xsd:string"/> <xsd:attribute name="conf-id" type="xsd:string"/>
</xsd:attributeGroup> </xsd:attributeGroup>
</xs:schema> </xs:schema>
17. References 18. References
17.1. Normative References 18.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References 18.2. Informative References
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
skipping to change at page 33, line 18 skipping to change at page 35, line 26
September 2006. September 2006.
[9] Handley, M., "SDP: Session Description Protocol", [9] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[10] Levin, O. and G. Camarillo, "The SDP (Session Description [10] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress), draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005. January 2005.
[11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [11] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-07 (work in progress), January 2007.
[12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004. April 2004.
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [14] 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.
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[16] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
skipping to change at page 35, line 7 skipping to change at page 37, line 7
Asher Shiratzky Asher Shiratzky
Radvision Radvision
24 Raoul Wallenberg st 24 Raoul Wallenberg st
Tel-Aviv, Israel Tel-Aviv, Israel
Email: ashers@radvision.com Email: ashers@radvision.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 97 change blocks. 
152 lines changed or deleted 261 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/