draft-ietf-mediactrl-sip-control-framework-06.txt   draft-ietf-mediactrl-sip-control-framework-07.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft Avaya
Expires: May 4, 2009 T. Melanchuk Expires: May 28, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
October 31, 2008 November 24, 2008
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-06 draft-ietf-mediactrl-sip-control-framework-07
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 May 4, 2009. This Internet-Draft will expire on May 28, 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 programming logic and processing are deployment where the application programming logic and processing are
distributed. This implies that application programming logic can distributed. This implies that application programming logic can
seamlessly gain access to appropriate resources that are not co- seamlessly gain access to appropriate resources that are not co-
located on the same physical network entity. The framework uses the located on the same physical network entity. The framework uses the
Session Initiation Protocol (SIP) to establish an application-level Session Initiation Protocol (SIP) to establish an application-level
control mechanism between application servers and associated external control mechanism between application servers and associated external
skipping to change at page 3, line 25 skipping to change at page 3, line 25
12.4. Control Framework Header Fields . . . . . . . . . . . . . 40 12.4. Control Framework Header Fields . . . . . . . . . . . . . 40
12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41 12.5. Control Framework Port . . . . . . . . . . . . . . . . . 41
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 41
12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41 12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41
12.8. URN Sub-Namespace for 12.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes . . . 42 urn:ietf:params:xml:ns:control:framework-attributes . . . 42
12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42 12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42
12.10. MIME Media Type Registration for 12.10. MIME Media Type Registration for
'application/framework-attributes+xml' . . . . . . . . . 43 'application/framework-attributes+xml' . . . . . . . . . 43
13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Changes from 05 Version . . . . . . . . . . . . . . . . . 43 13.1. Changes from 06 Version . . . . . . . . . . . . . . . . . 43
13.2. Changes from 04 Version . . . . . . . . . . . . . . . . . 44 13.2. Changes from 05 Version . . . . . . . . . . . . . . . . . 44
13.3. Changes from 03 Version . . . . . . . . . . . . . . . . . 44 13.3. Changes from 04 Version . . . . . . . . . . . . . . . . . 44
13.4. Changes from 02 Version . . . . . . . . . . . . . . . . . 44 13.4. Changes from 03 Version . . . . . . . . . . . . . . . . . 44
13.5. Changes from 01 Version . . . . . . . . . . . . . . . . . 44 13.5. Changes from 02 Version . . . . . . . . . . . . . . . . . 44
13.6. Changes from 00 Version . . . . . . . . . . . . . . . . . 45 13.6. Changes from 01 Version . . . . . . . . . . . . . . . . . 44
13.7. Changes from 00 Version . . . . . . . . . . . . . . . . . 45
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 46 16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46 16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.1. Normative References . . . . . . . . . . . . . . . . . . 47 17.1. Normative References . . . . . . . . . . . . . . . . . . 47
17.2. Informative References . . . . . . . . . . . . . . . . . 49 17.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 51
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
skipping to change at page 12, line 34 skipping to change at page 12, line 34
This example demonstrates a new connection that will be initiated This example demonstrates a new connection that will be initiated
from the owner of the SDP payload. The connection details are from the owner of the SDP payload. The connection details are
contained in the SDP answer received from the UAS. A full example of contained in the SDP answer received from the UAS. A full example of
an SDP payload compliant to this specification can be viewed in an SDP payload compliant to this specification can be viewed in
Section 3. Once the SDP has been constructed along with the Section 3. Once the SDP has been constructed along with the
remainder of the SIP INVITE request (as defined in [RFC3261]), it can remainder of the SIP INVITE request (as defined in [RFC3261]), it can
be sent to the appropriate location. The SIP dialog and appropriate be sent to the appropriate location. The SIP 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 SIP UAC constructing an offer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. The 'cfw-id' attribute attribute as defined in Section 9.2. The 'cfw-id' attribute
indicates an identifier that can be used within the control channel indicates an identifier that can be used within the control channel
to correlate the control channel with this SIP dialog. This to correlate the control channel with this SIP dialog. This
attribute MUST contain an appropriately random value of at least 64 attribute MUST contain an appropriately random value of at least 64
bits of randomness that will not clash with other offer/answer bits of randomness that will not clash with other offer/answer
exchanges that will take place and is globally unique over space and exchanges that will take place and is globally unique over space and
time. The value chosen for the 'cfw-id' attribute MUST be used for time. The value chosen for the 'cfw-id' attribute MUST be used for
the entire duration of the associated SIP dialog and not be changed the entire duration of the associated SIP dialog and not be changed
during updates to the offer/answer exchange. This applies to during updates to the offer/answer exchange. This applies to
specifically to the 'connection' attribute as defined in [RFC4145]. specifically to the 'connection' attribute as defined in [RFC4145].
If a client entity wants to change some other parts of the SDP but If a SIP UAC wants to change some other parts of the SDP but reuse
reuse the already established connection it should use the value of the already established connection it should use the value of
'existing' in the 'connection' attribute (for example, a=connection: 'existing' in the 'connection' attribute (for example, a=connection:
existing). If it has noted that a connection has failed and wants to existing). If it has noted that a connection has failed and wants to
re-establish, it uses the value of 'new' in the 'connection' re-establish, it uses the value of 'new' in the 'connection'
attribute (for example, a=connection:new). Throughout this the attribute (for example, a=connection:new). Throughout this the
connection identifier specified in the 'cfw-id' SDP parameter does connection identifier specified in the 'cfw-id' SDP parameter does
not change. You are simply negotiated the underlying TCP between not change. You are simply negotiating the underlying TCP connection
endpoints but always using the same Control Framework session, which between endpoints but always using the same Control Framework
is 1:1 for the lifetime of the SIP dialog. session, which is 1:1 for the lifetime of the SIP dialog.
A non-2xx class final response (4xx, 5xx and 6xx) SIP response A non-2xx class final response (4xx, 5xx and 6xx) SIP response
received for the INVITE request indicates that no SIP dialog has been received for the INVITE request indicates that no SIP dialog has been
created and is treated as specified [RFC3261]. Specifically, support created and is treated as specified [RFC3261]. Specifically, support
of this specification is negotiated through the presence of the media of this specification is negotiated through the presence of the media
type defined in this specification. The receipt of a SIP error type defined in this specification. The receipt of a SIP error
response like "488" indicates that the offer contained in a request response like "488" indicates that the offer contained in a request
is not acceptable. The inclusion of the media line associated with is not acceptable. The inclusion of the media line associated with
this specification in such a rejected offer should indicate to the this specification in such a rejected offer should indicate to the
client generating the offer that this could be due to the receiving client generating the offer that this could be due to the receiving
client not supporting this specification. The client generating the client not supporting this specification. The client generating the
offer MUST act as it would normally on receiving this response, as offer MUST act as it would normally on receiving this response, as
per [RFC3261]. Media streams can also be rejected by setting the per [RFC3261]. Media streams can also be rejected by setting the
port to "0" in the "m=" line of the session description. A client port to "0" in the "m=" line of the session description. A client
using this specification should be prepared to receive an answer using this specification MUST be prepared to receive an answer where
where the "m=" line it inserted for using the Control Framework has the "m=" line it inserted for using the Control Framework has been
been set to "0". In this situation the client will act as it would set to "0". In this situation the client will act as it would for
for any other media type with a port set to "0". 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(SIP UAS)
the message for indications of support for the mechanisms defined in inspects the message for indications of support for the mechanisms
this specification. This is achieved through inspection of the defined in this specification. This is achieved through inspection
Sessions Description of the offer message and identifying support for of the Sessions Description of the offer message and identifying
the appropriate media type. If the external Server wishes to support for the appropriate media type. If the SIP UAS wishes to
construct a reliable response that conveys support for the extension, construct a reliable response that conveys support for the extension,
it should follow the mechanisms defined in [RFC3261]. If support is it MUST follow the mechanisms defined in [RFC3261]. If support is
conveyed in a reliable SIP provisional response, the mechanisms in conveyed in a reliable SIP provisional response, the mechanisms in
[RFC3262] MUST also be used. It should be noted that the SDP offer [RFC3262] MUST also be used. It should be noted that the SDP offer
is not restricted to the initial INVITE request and may appear in any is not restricted to the initial INVITE request and may appear in any
series of messages that are compliant to [RFC3261], [RFC3262], and series of messages that are compliant to [RFC3261], [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 semantic (Connection, Media and attribute) defined in
Section 4.1 using valid local settings and also with full compliance Section 4.1 using valid local settings and also with full compliance
to the COMEDIA[RFC4145] specification. For example, the SDP to the COMEDIA[RFC4145] specification. For example, the SDP
attributes included in the answer constructed for the example offer attributes included in the answer constructed for the example offer
provided in Section 4.1 would look as illustrated below: provided in Section 4.1 would look as illustrated below:
a=setup:passive a=setup:passive
a=connection:new a=connection:new
A client constructing an answer MUST include the 'cfw-id' SDP A client constructing an answer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. This attribute MUST copy the attribute as defined in Section 9.2. This attribute MUST exactly
value which appeared in the initial offer. copy the value which appeared in the initial offer.
Once the SDP answer has been constructed, it is sent using standard Once the SDP answer has been constructed, it is sent using standard
SIP mechanisms. Depending on the contents of the SDP payloads that SIP mechanisms. Depending on the contents of the SDP payloads that
were negotiated using the Offer/Answer exchange, a reliable were negotiated using the Offer/Answer exchange, a reliable
connection will be established between the Controlling UAC and connection will be established between the Controlling UAC and
external Server UAS entities. The newly established connection is external Server UAS entities. The newly established connection is
now available to exchange control command primitives. The state of now available to exchange control command primitives. The state of
the SIP Dialog and the associated Control channel are now implicitly the SIP Dialog and the associated Control channel are now implicitly
linked. If either party wishes to terminate a Control channel it linked. If either party wishes to terminate a Control channel it
simply issues a SIP termination request (for example a SIP BYE simply issues a SIP termination request (for example a SIP BYE
request, or appropriate response in an early dialog). The Control request, or appropriate response in an early dialog). The Control
Channel therefore lives for the duration of the SIP 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 SIP UAS does not support the extension defined in this
as identified by the media contained in the Session Description, it document, as identified by the media contained in the Session
should respond as detailed in [RFC3261] with a "SIP 488" response Description, it should respond as detailed in [RFC3261] with a "SIP
code. If multiple media descriptions exist it might choose to 488" response code. If multiple media descriptions exist it might
continue processing the request and mark the port field equal to "0". choose to 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 15, line 20 skipping to change at page 15, line 21
This framework identifies the referencing of such associated media This framework identifies the referencing of such associated media
dialogs as extremely important. A connection reference attribute has dialogs as extremely important. A connection reference attribute has
been specified that can optionally be imported into any Control been specified that can optionally be imported into any Control
Package. It is intended that this will reduce repetitive specifying Package. It is intended that this will reduce repetitive specifying
of dialog reference language. The schema can be found in of dialog reference language. The schema can be found in
Section 16.1 in Appendix A. Section 16.1 in Appendix A.
Similarly, the ability to identify and apply commands to a group of Similarly, the ability to identify and apply commands to a group of
associated media dialogs (multiparty) is also identified as a common associated media dialogs (multiparty) is also identified as a common
structure that could be defined and re-used (for example playing a structure that could be defined and re-used, for example playing a
prompt to all participants in a Conference). The schema for such prompt to all participants in a Conference. The schema for such
operations can also be found in Section 16.1 in Appendix A. operations can also be found in Section 16.1 in Appendix A.
Support for both the common attributes described here is specified as Support for both the common attributes described here is specified as
part of each Control Package definition, as detailed in Section 8. part of each Control Package definition, as detailed in Section 8.
6. Control Framework Interactions 6. Control Framework Interactions
The use of the COMEDIA specification in this document allows for a The use of the COMEDIA specification in this document allows for a
Control Channel to be set up in either direction as a result of a SIP Control Channel to be set up in either direction as a result of a SIP
INVITE transaction. SIP provides a flexible negotiation mechanism to INVITE transaction. SIP provides a flexible negotiation mechanism to
skipping to change at page 16, line 18 skipping to change at page 16, line 18
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
response. It MAY choose a longer time to wait but it should not response. It MAY choose a longer time to wait but it MUST not be
be shorter than 'Transaction-Timeout'. shorter than 'Transaction-Timeout'.
o If no response is received for the SYNC control message, a timeout o If no response is received for the SYNC control message, a timeout
occurs and the control channel is terminated along with the occurs and the control channel is terminated along with the
associated SIP dialog (issue a BYE request). associated SIP dialog (issue a BYE request).
o If the active UA receives a 481 response, this implies that the o If the active UA receives a 481 response, this implies that the
SYNC request was received but no associated SIP dialog exists. SYNC request was received but no associated SIP dialog exists.
This also results in the control channel being terminated along This also results in the control channel being terminated along
with the associated SIP dialog (issue a BYE request). with the associated SIP dialog (issue a BYE request).
o All other error responses received for the SYNC request are o All other error responses received for the SYNC request are
treated as detailed in this specification and also result in the treated as detailed in this specification and also result in the
termination of the control channel and the associated SIP dialog termination of the control channel and the associated SIP dialog
(issue a BYE request). (issue a BYE request).
o The receipt of a 200 response to a SYNC message implies that the o The receipt of a 200 response to a SYNC message implies that the
SIP dialog and control connection have been successfully SIP dialog and control connection have been successfully
correlated. The control channel can now be used for further correlated. The control channel can now be used for further
interactions. interactions.
SYNC messages can be sent at any point while the Control Channel is SYNC messages can be sent at any point while the Control Channel is
open from either side, once the initial exchange is complete. If open from either side, once the initial exchange is complete. If
present, the contents of the "Keep-Alive" and "Dialog-ID" headers present, the contents of the "Keep-Alive" and "Dialog-ID" headers
should not change and new values have no relevance as they are both MUST not change. New values of the "Keep-Alive" and "Dialog-ID"
negotiated for the lifetime of the session. headers have no relevance as they are negotiated for the lifetime of
the Media Control Channel Framework session.
Once a successful control channel has been established, as defined in Once a successful control channel has been established, as defined in
Section 4.1 and Section 4.2 (and the connection has been correlated, Section 4.1 and Section 4.2, and the connection has been correlated,
as described in previous paragraphs), the two entities are now in a as described in previous paragraphs, the two entities are now in a
position to exchange control framework messages. The following sub- position to exchange control framework messages. The following sub-
sections specify the general behaviour for constructing control sections specify the general behaviour for constructing control
framework requests and responses. Section 6.3 specifies the core framework requests and responses. Section 6.3 specifies the core
Control Framework methods and their transaction processing. Control Framework methods and their transaction processing.
6.1. General Behaviour for Constructing Requests 6.1. General Behaviour for Constructing Requests
An entity acting as a Control Client that constructs and sends An entity acting as a Control Client that constructs and sends
requests on a control channel MUST adhere to the syntax defined in requests on a control channel MUST adhere to the syntax defined in
Section 9 (Note: either entity can act as a control client depending Section 9 (Note: either entity can act as a control client depending
skipping to change at page 17, line 27 skipping to change at page 17, line 27
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 with at least 64 bits of globally unique over space and time with at least 64 bits of
randomness. This unique property helps in the avoidance of clashes randomness. This unique property helps in the avoidance of clashes
when multiple client entities could be creating transactions to be when multiple client entities could be creating transactions to be
carried out on a single receiving server. All required mandatory and carried out on a single receiving server. All required mandatory and
optional control framework headers are then inserted into the control optional control framework headers are then inserted into the control
message with appropriate values (see relevant individual header message with appropriate values (see relevant individual header
information for explicit detail). A "Control-Package" header MUST information for explicit detail). A "Control-Package" header MUST
also be inserted with the value indicating the Control Package to also be inserted with the value indicating the Control Package to
which this specific request applies (Multiple packages can be which this specific request applies. Multiple packages can be
negotiated per control channel using the SYNC control message negotiated per control channel using the SYNC control message
discussed in Section 6.3.4.2). discussed in Section 6.3.4.2.
Any framework message that contains an associated payload MUST also Any framework message that contains an associated payload MUST also
include a 'Content-Type' and 'Content-Length' message header which 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.
The 'Content-Type' header represents the MIME payload to be used as The 'Content-Type' header represents the MIME payload to be used as
specified by the individual control framework packages. If no specified by the individual control framework packages. If no
associated payload is to be added to the message, a 'Content-Length' 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 header with a value of '0' is considered the same as one not being
present. present.
skipping to change at page 21, line 32 skipping to change at page 21, line 32
control channel being created. For details relating to a SIP keep control channel being created. For details relating to a SIP keep
alive mechanism, implementers should seek guidance from SIP Outbound alive mechanism, implementers should seek guidance from SIP Outbound
[I-D.ietf-sip-outbound]. [I-D.ietf-sip-outbound].
The following keep alive procedures MUST be implemented. Specific The following keep alive procedures MUST be implemented. Specific
deployments MAY choose not to use the keep alive mechanism if both deployments MAY choose not to use the keep alive mechanism if both
entities are in a co-located domain. Note that choosing not to use entities are in a co-located domain. Note that choosing not to use
the keep alive mechanism defined in this section, even when in a co- the keep alive mechanism defined in this section, even when in a co-
located architecture, will reduce the ability to detect application located architecture, will reduce the ability to detect application
level errors - especially during long periods of in-activity. level errors - especially during long periods of in-activity.
Extensions to this specification MAY specify alternate Control
Channel keep alive mechanisms.
Once the SIP dialog has been established and the underlying control Once the SIP dialog has been established and the underlying control
channel has been set-up (including the initial correlation handshake channel has been set-up (including the initial correlation handshake
using SYNC as discussed in Section 6), both entities acting in the using SYNC as discussed in Section 6), both entities acting in the
'active' and 'passive' roles (as defined in COMEDIA [RFC4145]) MUST 'active' and 'passive' roles (as defined in COMEDIA [RFC4145]) MUST
start a keep alive timer equal to the value negotiated during the start a keep alive timer equal to the value negotiated during the
control channel SYNC request/response exchange (the value from the control channel SYNC request/response exchange (the value from the
'Keep-Alive' header in seconds). 'Keep-Alive' header in seconds).
6.3.3.1. Behaviour for an Entity in an Active Role 6.3.3.1. Behaviour for an Entity in an Active Role
When acting in an 'active' role, a 'K-ALIVE' Control Framework When acting in an 'active' role, a 'K-ALIVE' Control Framework
message MUST be generated before the local keep alive timer fires. message MUST be generated before the local keep alive timer fires.
An active entity is free to send the K-ALIVE Control Framework An active entity is free to send the K-ALIVE Control Framework
message whenever it chooses. A guideline of 80% of the local keep message whenever it chooses. A guideline of 80% of the local keep
alive timer is suggested. On receiving a 200 OK Control Framework alive timer is suggested. On receiving a 200 OK Control Framework
message for the K-ALIVE request, the 'active' entity MUST reset the message for the K-ALIVE request, the 'active' entity MUST reset the
local keep alive' timer. If no 200 OK response is received to 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 K-ALIVE Control Framework message (or a transport level problem is
detected by some other means) before the local keep alive timer
fires, the 'active' entity SHOULD tear down the SIP dialog and fires, the 'active' entity SHOULD tear down the SIP dialog and
recover the associated control channel resources. The 'active' recover the associated control channel resources. The 'active'
entity MAY choose to try and recover the connection by renegotiation entity MAY choose to try and recover the connection by renegotiation
using COMEDIA. using COMEDIA.
6.3.3.2. Behaviour for an Entity in an Passive Role 6.3.3.2. Behaviour for an Entity in an Passive Role
When acting as a 'passive' entity, a 'K-ALIVE' Control Framework When acting as a 'passive' entity, a 'K-ALIVE' Control Framework
message must be received before the local keep alive timer fires. message must be received before the local keep alive timer fires.
When a K-ALIVE request is received, the 'passive' entity MUST When a K-ALIVE request is received, the 'passive' entity MUST
generate a 200 OK control framework response and reset the local keep generate a 200 OK control framework response and reset the local keep
alive timer. No other Control Framework response is valid. If no alive timer. No other Control Framework response is valid. If no
K-ALIVE message is received before the local keep alive timer fires, K-ALIVE message is received (or a transport level problem is detected
the 'passive' entity SHOULD tear down the SIP dialog and recover the by some other means) before the local keep alive timer fires, the
'passive' entity SHOULD tear down the SIP dialog and recover the
associated control channel resources. The 'active' entity MAY try to associated control channel resources. The 'active' entity MAY try to
and recover the connection by renegotiating using COMEDIA. and recover the connection by renegotiating using COMEDIA.
6.3.4. SYNC Transactions 6.3.4. SYNC Transactions
The initial SYNC request on a control channel is used to negotiate The initial SYNC request on a control channel is used to negotiate
the timeout period for the control-channel keep alive mechanism and the timeout period for the control-channel keep alive mechanism and
to allow clients and servers to learn the Control Packages that each to allow clients and servers to learn the Control Packages that each
supports. Subsequent SYNC requests may be used to change the set of supports. Subsequent SYNC requests may be used to change the set of
Control Packages that can be used on the control-channel. Control Packages that can be used on the control-channel.
skipping to change at page 23, line 45 skipping to change at page 23, line 45
As part of the SYNC message exchange a client generating the request As part of the SYNC message exchange a client generating the request
MUST include a "Packages" header, as defined in Section 9. The MUST include a "Packages" header, as defined in Section 9. The
"Packages " header will contain a list of all Control Framework "Packages " header will contain a list of all Control Framework
packages that can be supported within this control session (from the packages that can be supported within this control session (from the
perspective of the client creating the SYNC message). All tokens perspective of the client creating the SYNC message). All tokens
MUST be Channel Framework packages that adhere to the rules set out MUST be Channel Framework packages that adhere to the rules set out
in Section 8. The "Packages" header of the initial SYNC message MUST in Section 8. The "Packages" header of the initial SYNC message MUST
contain at least one value. contain at least one value.
An server receiving the initial SYNC request should examine the A server receiving the initial SYNC request MUST examine the contents
contents of the "Packages" header. If the server supports at least of the "Packages" header. If the server supports at least one of the
one of the packages listed in the request, it MUST respond with a 200 packages listed in the request, it MUST respond with a 200 response
response code. The response MUST contain a "Packages" header that code. The response MUST contain a "Packages" header that lists the
lists the supported packages that are in common with those from the supported packages that are in common with those from the "Packages"
"Packages" header of the request (either all or a subset). This list header of the request (either all or a subset). This list forms a
forms a common set of Control Packages that are supported by both common set of Control Packages that are supported by both parties.
parties. Any Control Packages supported by the server that are not Any Control Packages supported by the server that are not listed in
listed in the "Packages" header of the SYNC request, MAY be placed in the "Packages" header of the SYNC request, MAY be placed in the
the "Supported" header of the response. This provides a hint to 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 common packages are supported by the server receiving the SYNC If no common packages are supported by the server receiving the SYNC
message, it MUST respond with a 422 error response code. The error message, it MUST respond with a 422 error response code. The error
response MUST contain a "Supported" header indicating the packages 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].
skipping to change at page 26, line 15 skipping to change at page 26, line 15
7.11. 500 Response Code 7.11. 500 Response Code
The 500 response indicates that the recipient does not understand the The 500 response indicates that the recipient does not understand the
request request
8. Control Packages 8. Control Packages
"Control Packages" 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. To reiterate, the following appropriately in all Control-Packages. To reiterate, the following
sections do not solely form the basis of all Control-Package sections do not solely form the basis of all Control-Package
structure but are included as a minimum to provide essential package structure but are included as a minimum to provide essential package
skipping to change at page 29, line 30 skipping to change at page 29, line 30
Keep-alive = "Keep-Alive:" SP kalive-seconds Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token dialog-id-string = alpha-num-token
package-name = alpha-num-token package-name = alpha-num-token
supported-alphanum = alpha-num-token supported-alphanum = alpha-num-token
kalive-seconds = 1*DIGIT kalive-seconds = 1*DIGIT
alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char
alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "="
control-content = data CRLF control-content = *OCTET
Content-Type = "Content-Type:" SP media-type Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param ) media-type = type "/" subtype *( ";" gen-param )
type = token type = token
subtype = token subtype = token
gen-param = pname [ "=" pval ] gen-param = pname [ "=" pval ]
pname = token pname = token
pval = token / quoted-string pval = token / quoted-string
skipping to change at page 30, line 5 skipping to change at page 30, line 5
; token is compared case-insensitive ; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII / UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\" BACKSLASH = "\"
UPALPHA = %x41-5A UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT ALPHANUM = ALPHA / DIGIT
data = *OCTET
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
hname = ALPHA *token hname = ALPHA *token
hval = utf8text hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UPALPHA = %x41-5A UPALPHA = %x41-5A
UTF8-NONASCII = %xC0-DF UTF8-CONT UTF8-NONASCII = %xC0-DF UTF8-CONT
skipping to change at page 31, line 12 skipping to change at page 31, line 12
o: The header field is optional. o: The header field is optional.
-: The header field is not applicable (ignored if present). -: The header field is not applicable (ignored if present).
Header field Where CONTROL REPORT SYNC K-ALIVE Header field Where CONTROL REPORT SYNC K-ALIVE
___________________________________________________________ ___________________________________________________________
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 - -
Timeout 202 - m - -
Dialog-ID R - - m - Dialog-ID R - - m -
Packages - - m - Packages - - m -
Supported r - - o - Supported r - - o -
Keep-Alive R - - o - Keep-Alive R - - o -
Content-Type o o - - Content-Type o o - -
Figure 3: Table 1 Figure 3: Table 1
9.2. Control Framework Dialog Identifier SDP Attribute 9.2. Control Framework Dialog Identifier SDP Attribute
skipping to change at page 31, line 48 skipping to change at page 32, line 4
10. Examples 10. Examples
The following examples provide an abstracted flow of Control Channel The following examples provide an abstracted flow of Control Channel
establishment and Control Framework message exchange. The SIP establishment and Control Framework message exchange. The SIP
signaling is prefixed with the token 'SIP'. All other messages are signaling is prefixed with the token 'SIP'. All other messages are
Control Framework interactions defined in this document. Control Framework interactions defined in this document.
In this example, the Control Client establishes a control channel, In this example, the Control Client establishes a control channel,
SYNCs with the Control Server, and issues a CONTROL request that SYNCs with the Control Server, and issues a CONTROL request that
can't be completed within the 'Transaction-Timeout' of, so the can't be completed within the 'Transaction-Timeout', so the Control
Control Server returns a 202 response code to extend the transaction. Server returns a 202 response code to extend the transaction. The
The Control Server then follows with REPORTs until the requested Control Server then follows with REPORTs until the requested action
action has been completed. The SIP dialog is then terminated. has been completed. The SIP dialog is then terminated.
Control Client Control Server Control Client Control Server
| | | |
| (1) SIP INVITE | | (1) SIP INVITE |
| ----------------------------------------> | | ----------------------------------------> |
| | | |
| (2) SIP 200 | | (2) SIP 200 |
| <--------------------------------------- | | <--------------------------------------- |
| | | |
| (3) SIP ACK | | (3) SIP ACK |
skipping to change at page 34, line 31 skipping to change at page 34, line 31
a=cfw-id:fndskuhHKsd783hjdla a=cfw-id:fndskuhHKsd783hjdla
3. Control Client->Control Server (SIP): ACK 3. Control Client->Control Server (SIP): ACK
4. Control Client opens a TCP connection to the Control Server. 4. Control Client opens a TCP connection to the Control Server.
The connection can now be used to exchange control framework The connection can now be used to exchange control framework
messages. Control Client-->Control Server (Control Framework messages. Control Client-->Control Server (Control Framework
Message): SYNC. Message): SYNC.
CFW 8djae7khauj SYNC CFW 8djae7khauj SYNC
Dialog-ID: fndskuhHKsd783hjdla Dialog-ID: fndskuhHKsd783hjdla
K-alive: 100 K-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
5. Control Server-->Control Client (Control Framework Message): 5. Control Server-->Control Client (Control Framework Message):
200. 200.
CFW 8djae7khauj 200 CFW 8djae7khauj 200
Keep-Alive: 100 Keep-Alive: 100
Packages: msc-ivr-basic/1.0 Packages: msc-ivr-basic/1.0
Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0
skipping to change at page 36, line 42 skipping to change at page 36, line 42
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
Call-ID: 893jhoeihjr8392@example.com Call-ID: 893jhoeihjr8392@example.com
11. Security Considerations 11. Security Considerations
Channel Framework needs to provide confidentiality and integrity for The Channel Framework provides confidentiality and integrity for the
the messages it transfers. It also needs to provide assurances that messages it transfers. It also provides assurances that the
the connected host is the host that it meant to connect to and that connected host is the host that it meant to connect to and that the
the connection has not been hijacked. connection has not been hijacked.
Channel Framework is designed to comply with the security-related The Channel Framework in design complies with the security-related
requirements documented in the control protocol requirements requirements documented in the control protocol requirements
document[RFC5167] (more specifically REQ-MCP-11, REQ-MCP-12 document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12
REQ-MCP-13, and REQ-MCP-14). Specific security measures employed by REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by
the Channel Framework are summarized in the following subsections. the Channel Framework are summarized in the following subsections.
11.1. Session Establishment 11.1. Session Establishment
Channel Framework sessions are established as media sessions Channel Framework sessions are established as media sessions
described by SDP within the context of a SIP dialog. In order to described by SDP within the context of a SIP dialog. In order to
ensure secure rendezvous between Control Framework clients and ensure secure rendezvous between Control Framework clients and
servers, the Media Channel Control Framework should make full use of servers, the Media Channel Control Framework should make full use of
mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP
attribute results in important session information being carried attribute results in important session information being carried
across the SIP network. For this reason SIP clients using this across the SIP network. For this reason SIP clients using this
specification should use appropriate security mechanisms, such as specification MUST use appropriate security mechanisms, such as
TLS[RFC4346] and SMIME[RFC3851], when deployed in open networks. TLS[RFC4346] and SMIME[RFC3851], when deployed in open networks.
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, such as private and financial data, is carried over
Clients and servers must be properly authenticated/authorized and the the Control Framework channel. Clients and servers must be properly
control channel must permit the use of confidentiality, replay authenticated/authorized and the control channel must permit the use
protection and integrity for the data. To ensure control channel of confidentiality, replay protection and integrity for the data. To
protection, Control Framework clients and servers MUST support TLS ensure control channel protection, Control Framework clients and
and SHOULD utilize it by default unless alternative control channel servers MUST support TLS and SHOULD use it by default unless
protection is used or a protected environment is guaranteed. alternative control channel protection is used or a protected
environment is guaranteed by the deployer of the network.
Alternative control channel protection MAY be used if desired Alternative control channel protection MAY be used if desired
(e.g.IPSEC). (e.g.IPSEC).
TLS is used to authenticate devices and to provide integrity, replay TLS is used to authenticate devices and to provide integrity, replay
protection and confidentiality for the header fields being protection and confidentiality for the header fields being
transported on the control channel. Channel Framework elements MUST transported on the control channel. Channel Framework elements MUST
implement TLS and MUST also implement the TLS ClientExtendedHello implement TLS and MUST also implement the TLS ClientExtendedHello
extended hello information for server name indication as described in extended hello information for server name indication as described in
[RFC4366]. A TLS cipher-suite of [RFC4366]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported (other TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other
cipher-suites MAY also be supported). cipher-suites MAY also be supported.
11.3. Control Channel Policy Management 11.3. Control Channel Policy Management
This specification permits the establishment of a dedicated control This specification permits the establishment of a dedicated control
channel using SIP. It is also permitted for entities to create channel using SIP. It is also permitted for entities to create
multiple channels for the purpose of failover and redundancy. As a multiple channels for the purpose of failover and redundancy. As a
general solution, the ability for multiple entities to create general solution, the ability for multiple entities to create
connections and have access to resources could be the cause of connections and have access to resources could be the cause of
potential conflict in shared environments. It should be noted that potential conflict in shared environments. It should be noted that
this document does not specifically carry any specific mechanism to this document does not specifically carry any specific mechanism to
overcome such conflicts but will provide a summary of how it can be overcome such conflicts but will provide a summary of how it can be
achieved. achieved.
It can be determined that access to resources and use of control It can be determined that access to resources and use of control
channels relates to policy. It is implementation detail as to the channels relates to policy. It can be considered implementation and
level of policy that is adopted for use with specification. The deployment detail that dictates the level of policy that is adopted.
authorization and associated policy of a control channel can be The authorization and associated policy of a control channel can be
linked to the authentication mechanisms described in this section. linked to the authentication mechanisms described in this section.
For example, strictly authenticating a control channel either using For example, strictly authenticating a control channel either using
SIP digest or TLS authentication allows entities to protect resources SIP digest or TLS authentication allows entities to protect resources
and ensure the required level of granularity. Such policy can be and ensure the required level of granularity. Such policy can be
applied at the package level or even as low as a structure like a applied at the package level or even as low as a structure like a
conference instance (control channel X is not permitted to issue conference instance (control channel X is not permitted to issue
commands for control package y OR control channel A is not permitted commands for control package y OR control channel A is not permitted
to issue commands for conference instance B). Systems should ensure to issue commands for conference instance B). Systems should ensure
that if required, an appropriate policy framework is adopted to that if required, an appropriate policy framework is adopted to
satisfy the requirements for implemented packages. The most robust satisfy the requirements for implemented packages. The most robust
skipping to change at page 38, line 47 skipping to change at page 38, line 48
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), using the well-known IANA policy "RFC RFC Editor submission), using the IANA policy [RFC5226] "RFC
Required", RFC 5226 [RFC5226]. Required".
As this document specifies no package or template-package names, the As this document specifies no package or template-package names, the
initial IANA registration for control packages will be empty. The initial IANA registration for control packages will be empty. The
remainder of the text in this section gives an example of the type of remainder of the text in this section gives an example of the type of
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 43, line 43 skipping to change at page 43, line 43
Person & email address to contact for further information: Chris Person & email address to contact for further information: Chris
Boulton <cboulton@avaya.com> Boulton <cboulton@avaya.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: None. Other information: None.
13. Changes 13. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
13.1. Changes from 05 Version 13.1. Changes from 06 Version
o Added 202 Timeout entry to table.
o Fixed some general nits and language.
o Fixed ABNF to be 'control-content = *OCTET'.
o Added general qualifier to sections 6.3.3.1 and 6.3.3.2 so that
rules for either tearing down or reconnecting are applied.
13.2. Changes from 05 Version
o Reworded 'must' used in Introduction. o Reworded 'must' used in Introduction.
o Added urn namespace definition in IANA section. o Added urn namespace definition in IANA section.
o Added XML schema registration in IANA section. o Added XML schema registration in IANA section.
o Added MIME registration in IANA section. o Added MIME registration in IANA section.
13.2. Changes from 04 Version 13.3. Changes from 04 Version
o Fixed nits as reported by Brian Weis. o Fixed nits as reported by Brian Weis.
o Amended Security text as per secdir review. o Amended Security text as per secdir review.
o Removed optional 'label' part of dialog identifier as per interim o Removed optional 'label' part of dialog identifier as per interim
call. call.
o Added clarifying text at the beginning of section 4 to help o Added clarifying text at the beginning of section 4 to help
describe what the section is about. describe what the section is about.
o Added text at the beginning of section 8 clarifying that the o Added text at the beginning of section 8 clarifying that the
template is not the basis for packages BUT only needs to be template is not the basis for packages BUT only needs to be
included as part of a Control Package. included as part of a Control Package.
13.3. Changes from 03 Version 13.4. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
13.4. Changes from 02 Version 13.5. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
o Fixed broken IANA subsections ordering + naming. o Fixed broken IANA subsections ordering + naming.
13.5. Changes from 01 Version 13.6. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
13.6. Changes from 00 Version 13.7. 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.
 End of changes. 48 change blocks. 
99 lines changed or deleted 111 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/