draft-ietf-mediactrl-sip-control-framework-05.txt   draft-ietf-mediactrl-sip-control-framework-06.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft Avaya Internet-Draft Avaya
Expires: April 24, 2009 T. Melanchuk Expires: May 4, 2009 T. Melanchuk
Rain Willow Communications Rain Willow Communications
S. McGlashan S. McGlashan
Hewlett-Packard Hewlett-Packard
October 21, 2008 October 31, 2008
Media Control Channel Framework Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-05 draft-ietf-mediactrl-sip-control-framework-06
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 April 24, 2009. This Internet-Draft will expire on May 4, 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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 10
4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 10
4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 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 . . . . . . . 17 6.1. General Behaviour for Constructing Requests . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 19 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 19
6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 19
6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . 25 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 25
7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . 26 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 26
8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 26 8.1. Control Package Name . . . . . . . . . . . . . . . . . . 26
8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 26
8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 27 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 27
8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 27
8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 27
8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 28
9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 31
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 37
11.2. Transport Level Protection . . . . . . . . . . . . . . . . 37 11.2. Transport Level Protection . . . . . . . . . . . . . . . 37
11.3. Control Channel Policy Management . . . . . . . . . . . . 37 11.3. Control Channel Policy Management . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Control Packages Registration Information . . . . . . . . 38 12.1. Control Packages Registration Information . . . . . . . . 38
12.1.1. Control Package Registration Template . . . . . . . . 39 12.1.1. Control Package Registration Template . . . . . . . . 39
12.2. Control Framework Method Names . . . . . . . . . . . . . . 39 12.2. Control Framework Method Names . . . . . . . . . . . . . 39
12.3. Control Framework Status Codes . . . . . . . . . . . . . . 40 12.3. Control Framework Status Codes . . . . . . . . . . . . . 40
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
13. SDP Transport Protocol . . . . . . . . . . . . . . . . . . . . 41 12.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 41
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12.8. URN Sub-Namespace for
14.1. Changes from 04 Version . . . . . . . . . . . . . . . . . 42 urn:ietf:params:xml:ns:control:framework-attributes . . . 42
14.2. Changes from 03 Version . . . . . . . . . . . . . . . . . 42 12.9. XML Schema Registration . . . . . . . . . . . . . . . . . 42
14.3. Changes from 02 Version . . . . . . . . . . . . . . . . . 42 12.10. MIME Media Type Registration for
14.4. Changes from 01 Version . . . . . . . . . . . . . . . . . 42 'application/framework-attributes+xml' . . . . . . . . . 43
14.5. Changes from 00 Version . . . . . . . . . . . . . . . . . 43 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.1. Changes from 05 Version . . . . . . . . . . . . . . . . . 43
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 13.2. Changes from 04 Version . . . . . . . . . . . . . . . . . 44
17. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.3. Changes from 03 Version . . . . . . . . . . . . . . . . . 44
17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 44 13.4. Changes from 02 Version . . . . . . . . . . . . . . . . . 44
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.5. Changes from 01 Version . . . . . . . . . . . . . . . . . 44
18.1. Normative References . . . . . . . . . . . . . . . . . . . 45 13.6. Changes from 00 Version . . . . . . . . . . . . . . . . . 45
18.2. Informative References . . . . . . . . . . . . . . . . . . 47 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 49 16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.1. Normative References . . . . . . . . . . . . . . . . . . 47
17.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
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
server. The motivation for this framework comes from a set of server. The motivation for this framework comes from a set of
requirements for Media Server Control, which can be found in the requirements for Media Server Control, which can be found in the
'Media Server Control Protocol Requirements' document[RFC5167]. 'Media Server Control Protocol Requirements' document[RFC5167].
While the Framework is not media server control specific, it is the While the Framework is not media server control specific, it is the
primary driver and use case for this work. It is intended that the primary driver and use case for this work. It is intended that the
framework contained in this document can be used for a variety of framework contained in this document can be used for a variety of
device control scenarios (for example, conference control). device control scenarios (for example, conference control).
This document does not define a SIP protocol driven extension that This document does not define a SIP protocol driven extension that
can be used directly for the control of external components. The can be used directly for the control of external components. The
framework mechanism must be extended by other documents that are framework mechanism is extended by other documents that are known as
known as "Control Packages". A comprehensive set of guidelines for "Control Packages". A comprehensive set of guidelines for creating
creating "Control Packages" is described in Section 8. "Control Packages" is described in Section 8.
Current IETF device control protocols, such as megaco [RFC3525], Current IETF device control protocols, such as megaco [RFC3525],
while excellent for controlling media gateways that bridge separate while excellent for controlling media gateways that bridge separate
networks, are troublesome for supporting media-rich applications in networks, are troublesome for supporting media-rich applications in
SIP networks, because they duplicate many of the functions inherent SIP networks, because they duplicate many of the functions inherent
in SIP. Rather than relying on single protocol session in SIP. Rather than relying on single protocol session
establishment, application developers need to translate between two establishment, application developers need to translate between two
separate mechanisms. separate mechanisms.
SIP [RFC3261] provides the ideal rendezvous mechanism for SIP [RFC3261] provides the ideal rendezvous mechanism for
skipping to change at page 7, line 43 skipping to change at page 7, line 43
The example from Figure 1 conveys a 1:1 connection between the The example from Figure 1 conveys a 1:1 connection between the
Control Client and the Control Server. It is possible, if required, Control Client and the Control Server. It is possible, if required,
for multiple control channels using separate SIP dialogs to be for multiple control channels using separate SIP dialogs to be
established between the Control Client and the Control Server established between the Control Client and the Control Server
entities. Any of the connections created between the two entities entities. Any of the connections created between the two entities
can then be used for Server control interactions. The control can then be used for Server control interactions. The control
connections are agnostic to any media sessions. Specific media connections are agnostic to any media sessions. Specific media
session information can be incorporated in control interaction session information can be incorporated in control interaction
commands (which themselves are defined in external packages) using commands (which themselves are defined in external packages) using
the XML schema defined in Section 17. The ability to have multiple the XML schema defined in Section 16. The ability to have multiple
control channels allows for stronger redundancy and the ability to control channels allows for stronger redundancy and the ability to
manage high volumes of traffic in busy systems. manage high volumes of traffic in busy systems.
Consider the following simple example for session establishment Consider the following simple example for session establishment
between a Client and a Server (Note: Some lines in the examples are between a Client and a Server (Note: Some lines in the examples are
removed for clarity and brevity). Note that the roles discussed are removed for clarity and brevity). Note that the roles discussed are
logical and can change during a session, if the Control Package logical and can change during a session, if the Control Package
allows. allows.
The Client constructs and sends a standard SIP INVITE request, as The Client constructs and sends a standard SIP INVITE request, as
skipping to change at page 15, line 16 skipping to change at page 15, line 16
explicitly direct commands on the control channel at a specific media explicitly direct commands on the control channel at a specific media
line(m=). A Control Client constructing the SDP MAY choose not to line(m=). A Control Client constructing the SDP MAY choose not to
include the media label SDP attribute if it does not require direct include the media label SDP attribute if it does not require direct
control on a per media stream basis. control on a per media stream basis.
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 17.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 17.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
establish the control channel, but there needs to be a mechanism establish the control channel, but there needs to be a mechanism
skipping to change at page 27, line 11 skipping to change at page 27, line 11
limitations restricting the directionality of messages passed down a limitations restricting the directionality of messages passed down a
control channel. This section of a Control package document should control channel. This section of a Control package document should
explicitly detail the control messages that can be used as well as explicitly detail the control messages that can be used as well as
provide an indication of directionality between entities. This will provide an indication of directionality between entities. This will
include which role type is allowed to initiate a request type. include which role type is allowed to initiate a request type.
8.3. Common XML Support 8.3. Common XML Support
This optional section is only included in a Control Package if the This optional section is only included in a Control Package if the
attributes for media dialog or Conference reference are required, as attributes for media dialog or Conference reference are required, as
defined and discussed in Section 17.1 in Appendix A. The Control defined and discussed in Section 16.1 in Appendix A. The Control
Package will make strong statements (using language from RFC 2119 Package will make strong statements (using language from RFC 2119
[RFC2119]) if the XML schema defined in Section 17.1 in Appendix A is [RFC2119]) if the XML schema defined in Section 16.1 in Appendix A is
to be supported. If only part of the schema is required (for example to be supported. If only part of the schema is required (for example
just 'connectionid' or just conferenceid), the Control Package will just 'connectionid' or just conferenceid), the Control Package will
make equally strong (using language from RFC 2119 [RFC2119]) make equally strong (using language from RFC 2119 [RFC2119])
statements. statements.
8.4. CONTROL Message Bodies 8.4. CONTROL Message Bodies
This mandatory section of a Control Package defines the control body This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in that can be contained within a CONTROL command request, as defined in
Section 6 (or that no control package body is required). This Section 6 (or that no control package body is required). This
skipping to change at page 38, line 48 skipping to change at page 38, line 48
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 well-known IANA policy "RFC
Required", [RFC5226]. Required", RFC 5226 [RFC5226].
As this document specifies no package or template-package names, the As this document specifies no package or template-package names, the
initial IANA registration for control packages will be empty. The initial IANA registration for control packages will be empty. The
remainder of the text in this section gives an example of the type of remainder of the text in this section gives an example of the type of
information to be maintained by the IANA; it also demonstrates all information to be maintained by the IANA; it also demonstrates all
three possible permutations of package type, contact, and reference. three possible permutations of package type, contact, and reference.
The table below lists the control packages defined in the "Media The table below lists the control packages defined in the "Media
Control Channel Framework". Control Channel Framework".
skipping to change at page 41, line 33 skipping to change at page 41, line 33
o SCTP/TLS/CFW: Indicates the Channel Framework when TLS over SCTP o SCTP/TLS/CFW: Indicates the Channel Framework when TLS over SCTP
is used as an underlying transport for the control channel. is used as an underlying transport for the control channel.
Specifications defining new protocol values must define the rules for Specifications defining new protocol values must define the rules for
the associated media format namespace. The 'TCP/CFW', 'TCP/TLS/CFW', the associated media format namespace. The 'TCP/CFW', 'TCP/TLS/CFW',
'SCTP/CFW' and 'SCTP/TLS/CFW' protocol values allow only one value in 'SCTP/CFW' and 'SCTP/TLS/CFW' protocol values allow only one value in
the format field (fmt), which is a single occurrence of "*". Actual the format field (fmt), which is a single occurrence of "*". Actual
format determination is made using the control package extension format determination is made using the control package extension
specific payloads. specific payloads.
13. SDP Transport Protocol 12.7. 'cfw-id' SDP Attribute
Contact name: Chris Boulton cboulton@avaya.com. Contact name: Chris Boulton cboulton@avaya.com.
Attribute name: "cfw-id". Attribute name: "cfw-id".
Type of attribute Media level. Type of attribute Media level.
Subject to charset: Not. Subject to charset: Not.
Purpose of attribute: The 'cfw-id' attribute indicates Purpose of attribute: The 'cfw-id' attribute indicates
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 12.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:control:framework-attributes", per the
guidelines in RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (cboulton@avaya.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
12.9. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Chris Boulton (cboulton@avaya.com).
Schema: The XML for this schema can be found as the entirety of
Section 16 of this document.
12.10. MIME Media Type Registration for 'application/
framework-attributes+xml'
This section registers the "application/framework-attributes+xml"
MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/framework-attributes+xml
MIME media type name: application
MIME subtype name: framework-attributes+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2.
Security considerations: No known security considerations outside
of those provided by core Media Control Channel Framework.
Interoperability considerations: This content type provides common
constructs for related Media Control Channel packages.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]
Applications which use this media type: Implementations of appropriate
Media Control Channel packages.
Additional Information: Magic Number(s): (none)
File extension(s): .xml
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Chris
Boulton <cboulton@avaya.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: None.
13. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 04 Version 13.1. Changes from 05 Version
o Reworded 'must' used in Introduction.
o Added urn namespace definition in IANA section.
o Added XML schema registration in IANA section.
o Added MIME registration in IANA section.
13.2. Changes from 04 Version
o Fixed nits as reported by Brian Weis. o Fixed nits as reported by Brian Weis.
o Amended Security text as per secdir review. o Amended Security text as per secdir review.
o Removed optional 'label' part of dialog identifier as per interim o Removed optional 'label' part of dialog identifier as per interim
call. call.
o Added clarifying text at the beginning of section 4 to help o Added clarifying text at the beginning of section 4 to help
describe what the section is about. describe what the section is about.
o Added text at the beginning of section 8 clarifying that the o Added text at the beginning of section 8 clarifying that the
template is not the basis for packages BUT only needs to be template is not the basis for packages BUT only needs to be
included as part of a Control Package. included as part of a Control Package.
14.2. Changes from 03 Version 13.3. Changes from 03 Version
o Removed comment from XML schema in appendix. o Removed comment from XML schema in appendix.
o Changed dialog-id-string in section 9.1 to be dialog-id-string = o Changed dialog-id-string in section 9.1 to be dialog-id-string =
alpha-num-token. alpha-num-token.
o Changed status-code in section 9.1 to status-code = 3*DIGIT o Changed status-code in section 9.1 to status-code = 3*DIGIT
o Aligned use of Keep-Alive header terms in document. o Aligned use of Keep-Alive header terms in document.
o Added text to clarify connection and session relationship - as per o Added text to clarify connection and session relationship - as per
thread with Roni on use of 'new' and 'existing'. thread with Roni on use of 'new' and 'existing'.
o Use of K-Alive control message now aligned. o Use of K-Alive control message now aligned.
o Clarified that a CONTROL with no payload should be dealt with at o Clarified that a CONTROL with no payload should be dealt with at
the package level. the package level.
o Scrubbed ABNF + XML. o Scrubbed ABNF + XML.
14.3. Changes from 02 Version 13.4. Changes from 02 Version
o RAI review version. See comments. o RAI review version. See comments.
o Fixed broken IANA subsections ordering + naming.
14.4. Changes from 01 Version 13.5. Changes from 01 Version
o Restructured text for readability. o Restructured text for readability.
o Changed SYNCH method name to SYNC. o Changed SYNCH method name to SYNC.
o Removed 'pending' state to be replaced by 'update' with no o Removed 'pending' state to be replaced by 'update' with no
payload. payload.
o Replaced construction of dialog-id with new SDP parameter and o Replaced construction of dialog-id with new SDP parameter and
revised text. revised text.
o Removed problem with K-Alive mechanism. K-Alive timers are now o Removed problem with K-Alive mechanism. K-Alive timers are now
separate from any other Control messages as the delay in separate from any other Control messages as the delay in
processing allows for un-sync on both sides. processing allows for un-sync on both sides.
skipping to change at page 43, line 4 skipping to change at page 44, line 50
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.
14.5. Changes from 00 Version 13.6. 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 43, line 34 skipping to change at page 45, line 33
template). template).
o Removed noisy initial REPORT message - *Lorenzo please check o Removed noisy initial REPORT message - *Lorenzo please check
text*. text*.
o Fixed ABNF - PLEASE CHECK. o Fixed ABNF - PLEASE CHECK.
o Removed separate event mechanism and now all tied to CONTROL o Removed separate event mechanism and now all tied to CONTROL
transaction (extended). transaction (extended).
o General scrub of text. o General scrub of text.
o Organised 'Editors Notes' for discussion on the mailing list. o Organised 'Editors Notes' for discussion on the mailing list.
o Fixed ABNF in relation to extra CRLF on Content-Type. o Fixed ABNF in relation to extra CRLF on Content-Type.
15. Contributors 14. Contributors
Asher Shiratzky from Radvision provided valuable support and Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document. contributions to the early versions of this document.
16. Acknowledgments 15. Acknowledgments
The authors would like to thank Ian Evans and Michael Bardzinski of The authors would like to thank Ian Evans and Michael Bardzinski of
Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and Avaya, Adnan Saleem of Radisys, and Dave Morgan for useful review and
input to this work. Eric Burger contributed to the early phases of input to this work. Eric Burger contributed to the early phases of
this work. this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work. has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this draft and Ben Campbell carried out the RAI expert review on this draft and
provided a great deal of invaluable input. Brian Weis carried out a provided a great deal of invaluable input. Brian Weis carried out a
thorough security review. Text from Eric Burger was used in the thorough security review. Text from Eric Burger was used in the
introduction in the explanation for using SIP. introduction in the explanation for using SIP.
17. Appendix A 16. Appendix A
During the creation of the Control Framework it has become clear that During the creation of the Control Framework it has become clear that
there are number of components that are common across multiple there are number of components that are common across multiple
packages. It has become apparent that it would be useful to collect packages. It has become apparent that it would be useful to collect
such re-usable components in a central location. In the short term such re-usable components in a central location. In the short term
this appendix provides the place holder for the utilities and it is this appendix provides the place holder for the utilities and it is
the intention that this section will eventually form the basis of an the intention that this section will eventually form the basis of an
initial 'Utilities Document' that can be used by Control Packages. initial 'Utilities Document' that can be used by Control Packages.
17.1. Common Dialog/Multiparty Reference Schema 16.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing The following schema provides some common attributes for allowing
Control Packages to apply specific commands to a particular SIP media Control Packages to apply specific commands to a particular SIP media
dialog (also referred to as Connection) or conference. If used dialog (also referred to as Connection) or conference. If used
within a Control Package the Connection and multiparty attributes within a Control Package the Connection and multiparty attributes
will be imported and used appropriately to specifically identify will be imported and used appropriately to specifically identify
either a SIP dialog or a conference instance. If used within a either a SIP dialog or a conference instance. If used within a
package, the value contained in the 'connectionid' attribute MUST be package, the value contained in the 'connectionid' attribute MUST be
constructed by concatenating the 'Local' and 'Remote' SIP dialog constructed by concatenating the 'Local' and 'Remote' SIP dialog
identifier tags as defined in [RFC3261]. They MUST then be separated identifier tags as defined in [RFC3261]. They MUST then be separated
skipping to change at page 45, line 32 skipping to change at page 47, line 31
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation> <xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/> <xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/> <xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup> </xsd:attributeGroup>
</xsd:schema> </xsd:schema>
18. References 17. References
18.1. Normative References 17.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
skipping to change at page 46, line 27 skipping to change at page 48, line 25
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002. RFC 3268, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
skipping to change at page 47, line 13 skipping to change at page 49, line 15
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
18.2. Informative References 17.2. Informative References
[I-D.burger-mscl-thoughts] [I-D.burger-mscl-thoughts]
Burger, E., "Media Server Control Language and Protocol Burger, E., "Media Server Control Language and Protocol
Thoughts", draft-burger-mscl-thoughts-01 (work in Thoughts", draft-burger-mscl-thoughts-01 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008. draft-ietf-sip-outbound-16 (work in progress),
October 2008.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003. "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
 End of changes. 37 change blocks. 
56 lines changed or deleted 151 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/