draft-ietf-mediactrl-sip-control-framework-03.txt   draft-ietf-mediactrl-sip-control-framework-04.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft Avaya
Expires: January 15, 2009 T. Melanchuk Expires: February 21, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
July 14, 2008 August 20, 2008
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-03 draft-ietf-mediactrl-sip-control-framework-04
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 January 15, 2009. This Internet-Draft will expire on February 21, 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 2, line 27 skipping to change at page 2, line 27
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 13
5. Establishing Media Streams - Control Client SIP UAC 5. Establishing Media Streams - Control Client SIP UAC
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Control Framework Interactions . . . . . . . . . . . . . . . . 15 6. Control Framework Interactions . . . . . . . . . . . . . . . . 15
6.1. General Behaviour for Constructing Requests . . . . . . . 16 6.1. General Behaviour for Constructing Requests . . . . . . . 16
6.2. General Behaviour for Constructing Responses . . . . . . . 17 6.2. General Behaviour for Constructing Responses . . . . . . . 17
6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18 6.3. Transaction Processing . . . . . . . . . . . . . . . . . . 18
6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 18
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 18 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 20 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 20
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 21 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22
7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 24
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 24 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 25
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 25 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 25 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 26 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 26
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 26 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 26
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 26 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 27 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 27
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 30 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 30
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 36 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 36
11.2. Transport Level Protection . . . . . . . . . . . . . . . . 36 11.2. Transport Level Protection . . . . . . . . . . . . . . . . 36
11.3. Control Channel Policy Management . . . . . . . . . . . . 36 11.3. Control Channel Policy Management . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
12.1. Control Packages Registration Information . . . . . . . . 37 12.1. Control Packages Registration Information . . . . . . . . 38
12.1.1. Control Package Registration Template . . . . . . . . 38 12.1.1. Control Package Registration Template . . . . . . . . 38
12.2. Control Framework Method Names . . . . . . . . . . . . . . 38 12.2. Control Framework Method Names . . . . . . . . . . . . . . 38
12.3. Control Framework Status Codes . . . . . . . . . . . . . . 38 12.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
12.4. Control Framework Header Fields . . . . . . . . . . . . . 39 12.4. Control Framework Header Fields . . . . . . . . . . . . . 39
12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 39 12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 39 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 40
13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 40 13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 41
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
14.1. Changes from 02 Version . . . . . . . . . . . . . . . . . 40 14.1. Changes from 03 Version . . . . . . . . . . . . . . . . . 41
14.2. Changes from 01 Version . . . . . . . . . . . . . . . . . 41 14.2. Changes from 02 Version . . . . . . . . . . . . . . . . . 41
14.3. Changes from 00 Version . . . . . . . . . . . . . . . . . 41 14.3. Changes from 01 Version . . . . . . . . . . . . . . . . . 41
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 14.4. Changes from 00 Version . . . . . . . . . . . . . . . . . 42
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 42 17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 43
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 42 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 43
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
18.1. Normative References . . . . . . . . . . . . . . . . . . . 44 18.1. Normative References . . . . . . . . . . . . . . . . . . . 45
18.2. Informative References . . . . . . . . . . . . . . . . . . 45 18.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
Real-time media applications are often developed using an Real-time media applications are often developed using an
architecture where the application logic and processing activities architecture where the application logic and processing activities
are distributed. Commonly, the application logic runs on are distributed. Commonly, the application logic runs on
"application servers" but the processing runs on external servers, "application servers" but the processing runs on external servers,
such as "media servers". This document focuses on the framework and such as "media servers". This document focuses on the framework and
protocol between the application server and external processing protocol between the application server and external processing
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
skipping to change at page 12, line 39 skipping to change at page 12, line 39
A client constructing an offer MUST include the 'cfw-id' SDP A client constructing an offer MUST include the 'cfw-id' SDP
attribute as defined in Section 9.2. The 'cfw-id' attribute attribute as defined in Section 9.2. The 'cfw-id' attribute
indicates an identifier that can be used 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. during updates to the offer/answer exchange. This applies to
specifically to the 'connection' attribute as defined in [RFC4145].
If a client entity wants to change some other parts of the SDP but
reuse the already established connection it should use the value of
'existing' in the 'connection' attribute (for example, a=connection:
existing). If it has noted that a connection has failed and wants to
re-establish, it uses the value of 'new' in the 'connection'
attribute (for example, a=connection:new). Throughout this the
connection identifier specified in the 'cfw-id' SDP parameter does
not change. You are simply negotiated the underlying TCP between
endpoints but always using the same Control Framework 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
skipping to change at page 15, line 39 skipping to change at page 15, line 49
active role (active UA) to initiate the connection MUST active role (active UA) to initiate the connection MUST
immediately send a Control Framework SYNC request. The SYNC immediately send a Control Framework SYNC request. The SYNC
request MUST be constructed as defined in Section 9.1 and MUST request MUST be constructed as defined in Section 9.1 and MUST
contain the message header, 'Dialog-ID', which contains the SIP contain the message header, 'Dialog-ID', which contains the SIP
dialog information. dialog information.
o The 'Dialog-ID' message header value is the value contained in the o The 'Dialog-ID' message header value is the value contained in the
'cfw-id' SDP media level attribute. This allows for a correlation 'cfw-id' SDP media level attribute. This allows for a correlation
between the control channel and its associated SIP dialog. between the control channel and its associated SIP dialog.
o On creating the SYNC request the active UA MUST follow the o On creating the SYNC request the active UA MUST follow the
procedures outlined in Section 6.3.3 . This provides details of procedures outlined in Section 6.3.3 . This provides details of
connection keep-alive messages. connection keep alive messages.
o On creating the SYNC request the active UA MUST also follow the o On creating the SYNC request the active UA MUST also follow the
procedures outlined in Section 6.3.4.2. This provides details of procedures outlined in Section 6.3.4.2. This provides details of
the negotiation mechanism used to determine the Protocol Data the negotiation mechanism used to determine the Protocol Data
Units (PDUs) that can be exchanged on the established control Units (PDUs) that can be exchanged on the established control
channel connection. channel connection.
o The active UA MUST then send the SYNC request. It MUST then wait o The active UA MUST then send the SYNC request. It MUST then wait
for a period of at least 'Transaction-Timeout' to receive a for a period of at least 'Transaction-Timeout' to receive a
response. It MAY choose a longer time to wait but it should not response. It MAY choose a longer time to wait but it should not
be shorter than 'Transaction-Timeout'. be shorter than 'Transaction-Timeout'.
o If no response is received for the SYNC control message, a timeout o If no response is received for the SYNC control message, a timeout
occurs and the control channel is terminated along with the occurs and the control channel is terminated along with the
associated SIP dialog (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
skipping to change at page 18, line 45 skipping to change at page 19, line 6
to be sent in either direction between two participants in a session, to be sent in either direction between two participants in a session,
carrying the appropriate payload for an event. The message is carrying the appropriate payload for an event. The message is
constructed in the same way as any standard Control Framework constructed in the same way as any standard Control Framework
message, as discussed previously in Section 6.1 and defined in message, as discussed previously in Section 6.1 and defined in
Section 9. A CONTROL message MAY contain a message body. The Section 9. A CONTROL message MAY contain a message body. The
explicit control command(s) of the message payload contained in a explicit control command(s) of the message payload contained in a
CONTROL message are specified in separate Control Package CONTROL message are specified in separate Control Package
specifications. These specifications MUST conform to the format specifications. These specifications MUST conform to the format
defined in Section 8.4. A CONTROL message containing a payload MUST defined in Section 8.4. A CONTROL message containing a payload MUST
include a 'Content-Type' header indicating the payload type defined include a 'Content-Type' header indicating the payload type defined
by the control package. by the control package. A CONTROL message that does not contain a
payload should be dealt with in the individual package. This could
in fact be a valid message exchange within a specific package and if
not an appropriate package level error message should be generated.
6.3.2. REPORT Transactions 6.3.2. REPORT Transactions
A 'REPORT' message is used by a Control Server when processing of a A 'REPORT' message is used by a Control Server when processing of a
CONTROL Command extends beyond a 'Transaction-Timeout'. In this case CONTROL Command extends beyond a 'Transaction-Timeout'. In this case
a 202 response is returned. Status updates and the final results of a 202 response is returned. Status updates and the final results of
the command are then returned in subsequent REPORT messages. the command are then returned in subsequent REPORT messages.
All REPORT messages MUST contain the same transaction ID in the All REPORT messages MUST contain the same transaction ID in the
request start line that was present in the original CONTROL request start line that was present in the original CONTROL
skipping to change at page 20, line 38 skipping to change at page 20, line 50
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.
6.3.3. K-ALIVE Transactions 6.3.3. K-ALIVE Transactions
The protocol defined in this document may be used in various network The protocol defined in this document may be used in various network
architectures. This will include a wide range of deployments where architectures. This will include a wide range of deployments where
the clients could be co-located in a secured, private domain, or the clients could be co-located in a secured, private domain, or
spread across disparate domains that require traversal of devices spread across disparate domains that require traversal of devices
such as Network Address Translators (NAT) and Firewalls. A 'keep- such as Network Address Translators (NAT) and Firewalls. A keep
alive' mechanism enables the control channel to be kept active during alive mechanism enables the control channel to be kept active during
times of inactivity (for example, most Firewalls have a timeout times of inactivity (for example, most Firewalls have a timeout
period after which connections are closed). This mechanism also period after which connections are closed). This mechanism also
provides the ability for application level failure detection. It provides the ability for application level failure detection. It
should be noted that the following procedures apply explicitly to the should be noted that the following procedures apply explicitly to the
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 the keep alive mechanism defined in this section, even when in a co-
co-located architecture, will reduce the ability to detect located architecture, will reduce the ability to detect application
application level errors - especially during long periods of in- level errors - especially during long periods of in-activity.
activity. Extensions to this specification MAY specify alternate Extensions to this specification MAY specify alternate Control
Control Channel keep-alive mechanisms. 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
'k-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' K-ALIVE Control Framework message, before the local keep alive timer
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 generate a 200 OK control framework response and reset the local keep
'keep-alive' timer. No other Control Framework response is valid. alive timer. No other Control Framework response is valid. If no
If no K-ALIVE message is received before the local 'keep-alive' timer K-ALIVE message is received before the local keep alive timer fires,
fires, the 'passive' entity SHOULD tear down the SIP dialog and the 'passive' entity SHOULD tear down the SIP dialog and recover the
recover the associated control channel resources. The 'active' associated control channel resources. The 'active' entity MAY try to
entity MAY try to and recover the connection by renegotiating using and recover the connection by renegotiating using COMEDIA.
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' mechansim and the timeout period for the control-channel keep alive mechansim 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 vontrol-channel. Control Packages that can be used on the vontrol-channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction 6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the control- The initial SYNC request allows the timeout period for the control-
channel 'keep-alive' mechanism to be negotiated. The following rules channel keep alive mechanism to be negotiated. The following rules
SHOULD be followed for the initial SYNC request: SHOULD be followed for the initial SYNC request:
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'active', the 'k-alive' header MUST be included attribute equal to 'active', the 'Keep-Alive' header MUST be
in the SYNC message generated by the offerer. The value of the included in the SYNC message generated by the offerer. The value
'K-Alive' header SHOULD be in the range of 95 and 120 seconds of the 'Keep-Alive' header SHOULD be in the range of 95 and 120
(this is consistent with SIP Outbound[I-D.ietf-sip-outbound]). seconds (this is consistent with SIP
The client that generated the SDP "Answer" ('passive' client) MUST Outbound[I-D.ietf-sip-outbound]). The client that generated the
copy the 'K-alive' header into the 200 response to the SYNC SDP "Answer" ('passive' client) MUST copy the 'Keep-Alive' header
message with the same value. into the 200 response to the SYNC message with the same value.
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'passive', the 'K-alive' header parameter MUST attribute equal to 'passive', the 'Keep-Alive' header parameter
be included in the SYNC message generated by the answerer. The MUST be included in the SYNC message generated by the answerer.
value of the 'K-alive' header SHOULD be in the range of 95 and 120 The value of the 'Keep-Alive' header SHOULD be in the range of 95
seconds. The client that generated the SDP "Offer" ('passive' and 120 seconds. The client that generated the SDP "Offer"
client) MUST copy the 'K-alive' header into the 200 response to ('passive' client) MUST copy the 'Keep-Alive' header into the 200
the SYNC message with the same value. response to the SYNC message with the same value.
o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' o If the Client initiating the SDP "Offer" has a COMEDIA 'setup'
attribute equal to 'actpass', the 'K-Alive' header parameter MUST attribute equal to 'actpass', the 'Keep-Alive' header parameter
be included in the SYNC message of the entity who is the 'Active' MUST be included in the SYNC message of the entity who is the
participant in the SDP session. If the client generating the 'Active' participant in the SDP session. If the client generating
subsequent SDP 'Answer' places a value of 'active' in the COMEDIA the subsequent SDP 'Answer' places a value of 'active' in the
SDP 'setup' attribute, it will generate the SYNC request and COMEDIA SDP 'setup' attribute, it will generate the SYNC request
include the 'Keep-Alive' header. The value SHOULD be in the range and include the 'Keep-Alive' header. The value SHOULD be in the
95 to 120 seconds. If the client generating the subsequent SDP range 95 to 120 seconds. If the client generating the subsequent
'Answer' places a value of 'passive' in the COMDEDIA 'setup' SDP 'Answer' places a value of 'passive' in the COMDEDIA 'setup'
attribute, the original 'Offerer' will generate the SYNC request attribute, the original 'Offerer' will generate the SYNC request
and include the 'Keep-Alive' header. The value SHOULD be in the and include the 'Keep-Alive' header. The value SHOULD be in the
range 95 to 120 seconds. range 95 to 120 seconds.
o If the initial negotiated offer/answer results in a COMEDIA o If the initial negotiated offer/answer results in a COMEDIA
'setup' attribute equal to 'holdconn', the initial SYNC mechanism 'setup' attribute equal to 'holdconn', the initial SYNC mechanism
will occur when the offer/answer exchange is updated and active/ will occur when the offer/answer exchange is updated and active/
passive roles are delegated using COMEDIA. passive roles are delegated using COMEDIA.
The previous steps ensures that the entity initiating the control The previous steps ensures that the entity initiating the control
channel connection is always the one specifying the keep-alive channel connection is always the one specifying the keep alive
timeout period. It will always be the initiator of the connection timeout period. It will always be the initiator of the connection
who generates the 'K-ALIVE' Control Framework level messages. who generates the 'K-ALIVE' Control Framework level messages.
Once negotiated, the keep-alive timeout applies for the remainder of Once negotiated, the keep alive timeout applies for the remainder of
the Control Framework session. Any subsequent SYNC messages the Control Framework session. Any subsequent SYNC messages
generated in the control channel do not impact the negotiated keep- generated in the control channel do not impact the negotiated keep
alive property of the session. The "Keep-Alive" header MUST NOT be alive property of the session. The "Keep-Alive" header MUST NOT be
included in subsequent SYNC messages and if it is received it MUST be included in subsequent SYNC messages and if it is received it MUST be
ignored. ignored.
6.3.4.2. Package Negotiation 6.3.4.2. Package Negotiation
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
skipping to change at page 27, line 38 skipping to change at page 28, line 6
9. Formal Syntax 9. Formal Syntax
9.1. Control Framework Formal Syntax 9.1. Control Framework Formal Syntax
The Control Framework interactions use the UTF-8 transformation The Control Framework interactions use the UTF-8 transformation
format as defined in [RFC3629]. The syntax in this section uses the format as defined in [RFC3629]. The syntax in this section uses the
Augmented Backus-Naur Form (ABNF) as defined in [RFC2234]. Augmented Backus-Naur Form (ABNF) as defined in [RFC2234].
control-req-or-resp = control-request / control-response control-req-or-resp = control-request / control-response
control-request = control-req-start *( headers ) CRLF [control-content] control-request = control-req-start *headers CRLF [control-content]
control-response = control-resp-start *( headers ) CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content]
control-req-start = pCFW SP transact-id SP method CRLF control-req-start = pCFW SP transact-id SP method CRLF
control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF control-resp-start = pCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pCFW = %x43.46.57; CFW in caps pCFW = %x43.46.57; CFW in caps
transact-id = alpha-num-token transact-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNC = %x53.59.4E.43; SYNC in caps mSYNC = %x53.59.4E.43; SYNC in caps
mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this and other documents status-code = 3*DIGIT ; any code defined in this and other documents
headers = header-name CRLF headers = header-name CRLF
header-name = (Content-Length header-name = (Content-Length
/Content-Type /Content-Type
/Control-Package /Control-Package
/Status /Status
/Seq /Seq
/Timeout /Timeout
/Dialog-id /Dialog-id
skipping to change at page 28, line 29 skipping to change at page 28, line 44
/Keep-alive /Keep-alive
/ext-header) CRLF /ext-header) CRLF
Content-Length = "Content-Length:" SP 1*DIGIT Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("update" / "terminate" ) Status = "Status:" SP ("update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-ID:" SP dialog-id-string Dialog-id = "Dialog-ID:" SP dialog-id-string
Packages = "Packages:" SP package-name *(COMMA package-name) Packages = "Packages:" SP package-name *(COMMA package-name)
Supported = "Supported:" SP supported *(COMMA supported) Supported = "Supported:" SP supported-alphanum *(COMMA supported-alphanum)
Keep-alive = "Keep-Alive:" SP kalive-seconds Keep-alive = "Keep-Alive:" SP kalive-seconds
dialog-id-string = alpha-num-token "~" alpha-num-token ["~" alpha-num-token] dialog-id-string = alpha-num-token
package-name = alpha-num-token package-name = alpha-num-token
supported = 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 = data CRLF
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
skipping to change at page 29, line 22 skipping to change at page 29, line 38
ALPHANUM = ALPHA / DIGIT ALPHANUM = ALPHA / DIGIT
data = *OCTET 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)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UPALPHA = %x41-5A
UTF8-NONASCII = %xC0-DF UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
The following table details a summary of the headers that can be The following table details a summary of the headers that can be
contained in Control Framework interactions. The "where" columns contained in Control Framework interactions. The "where" columns
details where headers can be used: details where headers can be used:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
skipping to change at page 39, line 28 skipping to change at page 39, line 46
RFC Editor submission). Its initial population is defined as RFC Editor submission). Its initial population is defined as
follows: follows:
Control-Package - [RFCXXXX] Control-Package - [RFCXXXX]
Status - [RFCXXXX] Status - [RFCXXXX]
Seq - [RFCXXXX] Seq - [RFCXXXX]
Timeout - [RFCXXXX] Timeout - [RFCXXXX]
Dialog-id - [RFCXXXX] Dialog-id - [RFCXXXX]
Packages - [RFCXXXX] Packages - [RFCXXXX]
Supported - [RFCXXXX] Supported - [RFCXXXX]
Keep-alive - [RFCXXXX] Keep-Alive - [RFCXXXX]
Content-Type - [RFCXXXX] Content-Type - [RFCXXXX]
Content-Length - [RFCXXXX] Content-Length - [RFCXXXX]
The following information MUST be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new Channel Framework header field: order to register a new Channel Framework header field:
o The header field name. o The header field name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
12.5. Control Framework Port 12.5. Control Framework Port
The Control Framework uses TCP port XXXX, from the "registered" port The Control Framework uses TCP port XXXX, from the "registered" port
range. Usage of this value is described in Section 4.1. range. Usage of this value is described in Section 4.1.
skipping to change at page 40, line 42 skipping to change at page 41, line 26
an identifier that can be used to correlate the control an identifier that can be used to correlate the control
channel with the SIP dialog used to negotiate it, when channel with the SIP dialog used to negotiate it, when
the attribute value is used within the control channel. the attribute value is used within the control channel.
Allowed attribute values: A token. Allowed attribute values: A token.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 02 Version 14.1. Changes from 03 Version
o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at
the package level.
o Scrubbed ABNF + XML.
14.2. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
14.2. Changes from 01 Version 14.3. 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.
skipping to change at page 41, line 24 skipping to change at page 42, line 20
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
o Added transaction timeout of 5 seconds - as per meeting. o Added transaction timeout of 5 seconds - as per meeting.
o Added Upper Limit for transaction timeout on REPORT to 15 seconds. o Added Upper Limit for transaction timeout on REPORT to 15 seconds.
o Added Content-Type to table and missing examples etc. o Added Content-Type to table and missing examples etc.
o Simplified Security Section as per meeting feedback. o Simplified Security Section as per meeting feedback.
o Added proposed 'holdconn' text. o Added proposed 'holdconn' text.
o Added Default port text - as per meeting. o Added Default port text - as per meeting.
o Added Audit text. o Added Audit text.
14.3. Changes from 00 Version 14.4. Changes from 00 Version
o Aligned tokens to be 'CFW' (removed ESCS). o Aligned tokens to be 'CFW' (removed ESCS).
o Content-Length not mandatory for messages with no payload. o Content-Length not mandatory for messages with no payload.
o Corrected changes to call flows from legacy versions. o Corrected changes to call flows from legacy versions.
o Use of term 'Active UA' in section 7 + others. o Use of term 'Active UA' in section 7 + others.
o Added 'notify' to status header of ABNF. o Added 'notify' to status header of ABNF.
o Changed 481 to be transaction specific. o Changed 481 to be transaction specific.
o Added '423' duplicate transaction ID response. o Added '423' duplicate transaction ID response.
o Added '405' method not allowed. o Added '405' method not allowed.
o Added IANA section. o Added IANA section.
skipping to change at page 44, line 11 skipping to change at page 45, line 11
specific and should be selected with relevant context and uniqueness. specific and should be selected with relevant context and uniqueness.
The full schema follows: The full schema follows:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes" xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<!--xsd:include schemaLocation="common-schema.xsd"/-->
<xsd:attributeGroup name="framework-attributes"> <xsd:attributeGroup name="framework-attributes">
<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="connectionid" type="xsd:string"/> <xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/> <xsd:attribute name="conferenceid" type="xsd:string"/>
 End of changes. 53 change blocks. 
103 lines changed or deleted 133 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/