tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6230

Proposed STD
Pages: 49
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MEDIACTRL

Media Control Channel Framework

Part 1 of 3, p. 1 to 14
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        C. Boulton
Request for Comments: 6230                               NS-Technologies
Category: Standards Track                                   T. Melanchuk
ISSN: 2070-1721                                               Rainwillow
                                                            S. McGlashan
                                                         Hewlett-Packard
                                                                May 2011


                    Media Control Channel Framework

Abstract

   This document describes a framework and protocol for application
   deployment where the application programming logic and media
   processing are distributed.  This implies that application
   programming logic can seamlessly gain access to appropriate resources
   that are not co-located on the same physical network entity.  The
   framework uses the Session Initiation Protocol (SIP) to establish an
   application-level control mechanism between application servers and
   associated external servers such as media servers.

   The motivation for the creation of this framework is to provide an
   interface suitable to meet the requirements of a centralized
   conference system, where the conference system can be distributed, as
   defined by the XCON working group in the IETF.  It is not, however,
   limited to this scope.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6230.

Page 2 
Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Control Channel Setup  . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Control Client SIP UAC Behavior  . . . . . . . . . . . . . 10
     4.2.  Control Server SIP UAS Behavior  . . . . . . . . . . . . . 13
   5.  Establishing Media Streams - Control Client SIP UAC
       Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Control Framework Interactions . . . . . . . . . . . . . . . . 15
     6.1.  General Behavior for Constructing Requests . . . . . . . . 17
     6.2.  General Behavior for Constructing Responses  . . . . . . . 17
     6.3.  Transaction Processing . . . . . . . . . . . . . . . . . . 18
       6.3.1.  CONTROL Transactions . . . . . . . . . . . . . . . . . 18
       6.3.2.  REPORT Transactions  . . . . . . . . . . . . . . . . . 19
       6.3.3.  K-ALIVE Transactions . . . . . . . . . . . . . . . . . 21
       6.3.4.  SYNC Transactions  . . . . . . . . . . . . . . . . . . 22
   7.  Response Code Descriptions . . . . . . . . . . . . . . . . . . 24
     7.1.  200 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.2.  202 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.3.  400 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.4.  403 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.5.  405 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.6.  406 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.7.  420 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.8.  421 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.9.  422 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.10. 423 Response Code  . . . . . . . . . . . . . . . . . . . . 25
     7.11. 481 Response Code  . . . . . . . . . . . . . . . . . . . . 26
     7.12. 500 Response Code  . . . . . . . . . . . . . . . . . . . . 26
   8.  Control Packages . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Control Package Name . . . . . . . . . . . . . . . . . . . 26

Top      ToC       Page 3 
     8.2.  Framework Message Usage  . . . . . . . . . . . . . . . . . 26
     8.3.  Common XML Support . . . . . . . . . . . . . . . . . . . . 27
     8.4.  CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 27
     8.5.  REPORT Message Bodies  . . . . . . . . . . . . . . . . . . 27
     8.6.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 28
     9.1.  Control Framework Formal Syntax  . . . . . . . . . . . . . 28
     9.2.  Control Framework Dialog Identifier SDP Attribute  . . . . 31
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   11. Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 35
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
     12.1. Session Establishment  . . . . . . . . . . . . . . . . . . 36
     12.2. Transport-Level Protection . . . . . . . . . . . . . . . . 36
     12.3. Control Channel Policy Management  . . . . . . . . . . . . 37
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
     13.1. Control Packages Registration Information  . . . . . . . . 38
       13.1.1. Control Package Registration Template  . . . . . . . . 39
     13.2. Control Framework Method Names . . . . . . . . . . . . . . 39
     13.3. Control Framework Status Codes . . . . . . . . . . . . . . 39
     13.4. Control Framework Header Fields  . . . . . . . . . . . . . 40
     13.5. Control Framework Port . . . . . . . . . . . . . . . . . . 40
     13.6. Media Type Registrations . . . . . . . . . . . . . . . . . 40
       13.6.1. Registration of MIME Media Type application/cfw  . . . 41
       13.6.2. Registration of MIME Media Type
               application/framework-attributes+xml . . . . . . . . . 42
     13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . . 42
     13.8. URN Sub-Namespace for
           urn:ietf:params:xml:ns:control:framework-attributes  . . . 43
     13.9. XML Schema Registration  . . . . . . . . . . . . . . . . . 43
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 44
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     16.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Appendix A.  Common Package Components . . . . . . . . . . . . . . 47
     A.1.  Common Dialog/Multiparty Reference Schema  . . . . . . . . 47

Top      ToC       Page 4 
1.  Introduction

   Real-time media applications are often developed using an
   architecture where the application logic and media processing
   activities are distributed.  Commonly, the application logic runs on
   "application servers", but the processing runs on external servers,
   such as "media servers".  This document focuses on the framework and
   protocol between the application server and external processing
   server.  The motivation for this framework comes from a set of
   requirements for Media Server Control, which can be found in "Media
   Server Control Protocol Requirements" [RFC5167].  While the Framework
   is not specific to media server control, it is the primary driver and
   use case for this work.  It is intended that the framework contained
   in this document be able to be used for a variety of device control
   scenarios (for example, conference control).

   This document does not define a particular SIP extension for the
   direct control of external components.  Rather, other documents,
   known as "Control Packages", extend the Control Framework described
   by this document.  Section 8 provides a comprehensive set of
   guidelines for creating such Control Packages.

   Current IETF device control protocols, such as Megaco [RFC5125],
   while excellent for controlling media gateways that bridge separate
   networks, are troublesome for supporting media-rich applications in
   SIP networks.  This is because Megaco duplicates many of the
   functions inherent in SIP.  Rather than using a single protocol for
   session establishment and application media processing, application
   developers need to translate between two separate mechanisms.
   Moreover, the model provided by the framework presented here, using
   SIP, better matches the application programming model than does
   Megaco.

   SIP [RFC3261] provides the ideal rendezvous mechanism for
   establishing and maintaining control connections to external server
   components.  The control connections can then be used to exchange
   explicit command/response interactions that allow for media control
   and associated command response results.

2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.

Top      ToC       Page 5 
   The following additional terms are defined for use in this document:

   User Agent Client (UAC):  As specified in [RFC3261].

   User Agent Server (UAS):  As specified in [RFC3261].

   B2BUA:  A B2BUA is a Back-to-Back SIP User Agent.

   Control Server:  A Control Server is an entity that performs a
      service, such as media processing, on behalf of a Control Client.
      For example, a media server offers mixing, announcement, tone
      detection and generation, and play and record services.  The
      Control Server has a direct Real-Time Transport Protocol (RTP)
      [RFC3550] relationship with the source or sink of the media flow.
      In this document, we often refer to the Control Server simply as
      "the Server".

   Control Client:  A Control Client is an entity that requests
      processing from a Control Server.  Note that the Control Client
      might not have any processing capabilities whatsoever.  For
      example, the Control Client may be an application server (B2BUA)
      or other endpoint requesting manipulation of a third party's media
      stream that terminates on a media server acting in the role of a
      Control Server.  In this document, we often refer to the Control
      Client simply as "the Client".

   Control Channel:  A Control Channel is a reliable connection between
      a Client and Server that is used to exchange Framework messages.
      The term "Connection" is used synonymously within this document.

   Framework Message:  A Framework message is a message on a Control
      Channel that has a type corresponding to one of the Methods
      defined in this document.  A Framework message is often referred
      to by its method, such as a "CONTROL message".

   Method:  A Method is the type of a Framework message.  Four Methods
      are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE.

   Control Command:  A Control Command is an application-level request
      from a Client to a Server.  Control Commands are carried in the
      body of CONTROL messages.  Control Commands are defined in
      separate specifications known as "Control Packages".

   Framework Transaction:  A Framework Transaction is defined as a
      sequence composed of a Control Framework message originated by
      either a Control Client or Control Server and responded to with a
      Control Framework response code message.  Note that the Control
      Framework has no "provisional" responses.  A Control Framework

Top      ToC       Page 6 
      transaction is referenced throughout the document as a
      'Transaction-Timeout'.

   Transaction-Timeout:  The maximum allowed time between a Control
      Client or Server issuing a Framework message and it arriving at
      the destination.  The value for 'Transaction-Timeout' is 10
      seconds.

3.  Overview

   This document details mechanisms for establishing, using, and
   terminating a reliable transport connection channel using SIP and the
   Session Description Protocol offer/answer [RFC3264] exchange.  The
   established connection is then used for controlling an external
   server.  The following text provides a non-normative overview of the
   mechanisms used.  Detailed, normative guidelines are provided later
   in the document.

   Control Channels are negotiated using standard SIP mechanisms that
   would be used in a similar manner to creating a SIP multimedia
   session.  Figure 1 illustrates a simplified view of the mechanism.
   It highlights a separation of the SIP signaling traffic and the
   associated Control Channel that is established as a result of the SIP
   interactions.

   Initial analysis into the Control Framework, as documented in
   [MSCL-THOUGHTS], established the following.  One might ask, "If all
   we are doing is establishing a TCP connection to control the media
   server, why do we need SIP?"  This is a reasonable question.  The key
   is that we use SIP for media session establishment.  If we are using
   SIP for media session establishment, then we need to ensure the URI
   used for session establishment resolves to the same node as the node
   for session control.  Using the SIP routing mechanism, and having the
   server initiate the TCP connection back, ensures this works.  For
   example, the URI sip:myserver.example.com may resolve to sip:
   server21.farm12.northeast.example.net, whereas the URI
   http://myserver.example.com may resolve to
   http://server41.httpfarm.central.example.net.  That is, the host part
   is not necessarily unambiguous.

   The use of SIP to negotiate the Control Channel provides many
   inherent capabilities, which include:

   o  Service location - Use SIP Proxies and Back-to-Back User Agents
      for locating Control Servers.

   o  Security mechanisms - Leverage established security mechanisms
      such as Transport Layer Security (TLS) and Client Authentication.

Top      ToC       Page 7 
   o  Connection maintenance - The ability to re-negotiate a connection,
      ensure it is active, and so forth.

   o  Application agnostic - Generic protocol allows for easy extension.

   As mentioned in the previous list, one of the main benefits of using
   SIP as the session control protocol is the "Service Location"
   facilities provided.  This applies both at a routing level, where
   [RFC3263] provides the physical location of devices, and at the
   service level, using Caller Preferences [RFC3840] and Callee
   Capabilities [RFC3841].  The ability to select a Control Server based
   on service-level capabilities is extremely powerful when considering
   a distributed, clustered architecture containing varying services
   (for example, voice, video, IM).  More detail on locating Control
   Server resources using these techniques is outlined in Section 4.1 of
   this document.

           +--------------SIP Traffic--------------+
          |                                       |
          v                                       v
       +-----+                                 +--+--+
       | SIP |                                 | SIP |
       |Stack|                                 |Stack|
   +---+-----+---+                         +---+-----+---+
   |   Control   |                         |   Control   |
   |   Client    |<----Control Channel---->|   Server    |
   +-------------+                         +-------------+

                       Figure 1: Basic Architecture

   The example from Figure 1 conveys a 1:1 connection between the
   Control Client and the Control Server.  It is possible, if required,
   for the client to request multiple Control Channels using separate
   SIP INVITE dialogs between the Control Client and the Control Server
   entities.  Any of the connections created between the two entities
   can then be used for Server control interactions.  The control
   connections are orthogonal to any given media session.  Specific
   media session information is incorporated in control interaction
   commands, which themselves are defined in external packages, using
   the XML schema defined in Appendix A.  The ability to have multiple
   Control Channels allows for stronger redundancy and the ability to
   manage high volumes of traffic in busy systems.

   Consider the following simple example for session establishment
   between a Client and a Server.  (Note: Some lines in the examples are
   removed for clarity and brevity.)  Note that the roles discussed are
   logical and can change during a session, if the Control Package
   allows.

Top      ToC       Page 8 
   The Client constructs and sends a standard SIP INVITE request, as
   defined in [RFC3261], to the external Server.  The Session
   Description Protocol (SDP) payload includes the required information
   for Control Channel negotiation and is the primary mechanism for
   conveying support for this specification.  The application/cfw MIME
   type is defined in this document to convey the appropriate SDP format
   for compliance to this specification.  The Connection-Oriented Media
   (COMEDIA) [RFC4145] specification for setting up and maintaining
   reliable connections is used as part of the negotiation mechanism
   (more detail available in later sections).  The Client also includes
   the 'cfw-id' SDP attribute, as defined in this specification, which
   is a unique identifier used to correlate the underlying Media Control
   Channel with the offer/answer exchange.

   Client Sends to External Server:

   INVITE sip:External-Server@example.com SIP/2.0
   To: <sip:External-Server@example.com>
   From: <sip:Client@example.com>;tag=64823746
   Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d
   Call-ID: 7823987HJHG6
   Max-Forwards: 70
   CSeq: 1 INVITE
   Contact: <sip:Client@clientmachine.example.com>
   Content-Type: application/sdp
   Content-Length: [..]

   v=0
   o=originator 2890844526 2890842808 IN IP4 controller.example.com
   s=-
   c=IN IP4 controller.example.com
   m=application 49153 TCP cfw
   a=setup:active
   a=connection:new
   a=cfw-id:H839quwhjdhegvdga

   On receiving the INVITE request, an external Server supporting this
   mechanism generates a 200 OK response containing appropriate SDP and
   formatted using the application/cfw MIME type specified in this
   document.  The Server inserts its own unique 'cfw-id' SDP attribute,
   which differs from the one received in the INVITE (offer).

   External Server Sends to Client:

SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4

Top      ToC       Page 9 
Call-ID: 7823987HJHG6
CSeq: 1 INVITE
Contact: <sip:External-Server@servermachine.example.com>
Content-Type: application/sdp
Content-Length: [..]

v=0
o=responder 2890844526 2890842808 IN IP4 server.example.com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:U8dh7UHDushsdu32uha

   The Control Client receives the SIP 200 OK response and extracts the
   relevant information (also sending a SIP ACK).  It creates an
   outgoing (as specified by the SDP 'setup' attribute of 'active') TCP
   connection to the Control Server.  The connection address (taken from
   'c=') and port (taken from 'm=') are used to identify the remote port
   in the new connection.

   Once established, the newly created connection can be used to
   exchange requests and responses as defined in this document.  If
   required, after the Control Channel has been set up, media sessions
   can be established using standard SIP Third Party Call Control (3PCC)
   [RFC3725].

   Figure 2 provides a simplified example where the framework is used to
   control a User Agent's RTP session.

                         +--------Control SIP Dialog(1)---------+
                         |                                      |
                         v                                      v
                      +-----+                                +--+--+
     +------(2)------>| SIP |---------------(2)------------->| SIP |
     |                |Stack|                                |Stack|
     |            +---+-----+---+                        +---+-----+---+
     |            |             |                        |             |
     |            |   Control   |<--Control Channel(1)-->|             |
     |            |   Client    |                        |   Control   |
     |            +-------------+                        |   Server    |
  +--+--+                                                |             |
  |User |                                                |             |
  |Agent|<=====================RTP(2)===================>|             |
  +-----+                                                +-------------+

                    Figure 2: Participant Architecture

Top      ToC       Page 10 
   The link (1) represents the SIP INVITE dialog usage and dedicated
   Control Channel previously described in this overview section.  The
   link (2) from Figure 2 represents the User Agent SIP INVITE dialog
   usage interactions and associated media flow.  A User Agent creates a
   SIP INVITE dialog usage with the Control Client entity.  The Control
   Client entity then creates a SIP INVITE dialog usage to the Control
   Server, using B2BUA type functionality.  Using the interaction
   illustrated by (2), the Control Client negotiates media capabilities
   with the Control Server, on behalf of the User Agent, using SIP 3PCC.
   [RFC3725].

4.  Control Channel Setup

   This section describes the setup, using SIP, of the dedicated Control
   Channel.  Once the Control Channel has been established, commands can
   be exchanged (as discussed in Section 6).

4.1.  Control Client SIP UAC Behavior

   When a UAC wishes to establish a Control Channel, it MUST construct
   and transmit a new SIP INVITE request for Control Channel setup.  The
   UAC MUST construct the INVITE request as defined in [RFC3261].

   If a reliable response is received (as defined in [RFC3261] and
   [RFC3262]), the mechanisms defined in this document are applicable to
   the newly created SIP INVITE dialog usage.

   The UAC SHOULD include a valid session description (an 'offer' as
   defined in [RFC3264]) in an INVITE request using the Session
   Description Protocol defined in [RFC4566] but MAY choose an offer-
   less INVITE as per [RFC3261].  The SDP SHOULD be formatted in
   accordance with the steps below and using the MIME type application/
   cfw, which is registered in Section 13.  The following information
   defines the composition of specific elements of the SDP payload the
   offerer MUST adhere to when used in a SIP-based offer/answer exchange
   using SDP and the application/cfw MIME type.  The SDP being
   constructed MUST contain only a single occurrence of a Control
   Channel definition outlined in this specification but can contain
   other media lines if required.

   The Connection Data line in the SDP payload is constructed as
   specified in [RFC4566]:

   c=<nettype> <addrtype> <connection-address>

   The first sub-field, <nettype>, MUST equal the value "IN".  The
   second sub-field, <addrtype>, MUST equal either "IP4" or "IP6".  The
   third sub-field for Connection Data is <connection-address>.  This

Top      ToC       Page 11 
   supplies a representation of the SDP originator's address, for
   example, DNS/IP representation.  The address is the address used for
   connections.

   Example:

   c=IN IP4 controller.example.com

   The SDP MUST contain a corresponding Media Description entry:

   m=<media> <port> <proto> <fmt>

   The first "sub-field", <media>, MUST equal the value "application".
   The second sub-field, <port>, MUST represent a port on which the
   constructing client can receive an incoming connection if required.
   The port is used in combination with the address specified in the
   Connection Data line defined previously to supply connection details.
   If the entity constructing the SDP can't receive incoming
   connections, it must still enter a valid port entry.  The use of the
   port value '0' has the same meaning as defined in a SIP offer/answer
   exchange [RFC3264].  The Control Framework has a default port defined
   in Section 13.5.  This value is default, although a client is free to
   choose explicit port numbers.  However, SDP SHOULD use the default
   port number, unless local policy prohibits its use.  Using the
   default port number allows network administrators to manage firewall
   policy for Control Framework interactions.  The third sub-field,
   <proto>, compliant to this specification, MUST support the values
   "TCP" and "TCP/TLS".  Implementations MUST support TLS as a
   transport-level security mechanism for the Control Channel, although
   use of TLS in specific deployments is optional.  Control Framework
   implementations MUST support TCP as a transport protocol.  When an
   entity identifies a transport value but is not willing to establish
   the session, it MUST respond using the appropriate SIP mechanism.
   The <fmt> sub-field MUST contain the value "cfw".

   The SDP MUST also contain a number of SDP media attributes (a=) that
   are specifically defined in the COMEDIA [RFC4145] specification.  The
   attributes provide connection negotiation and maintenance parameters.
   It is RECOMMENDED that a Controlling UAC initiate a connection to an
   external Server but that an external Server MAY negotiate and
   initiate a connection using COMEDIA, if network topology prohibits
   initiating connections in a certain direction.  An example of the
   COMEDIA attributes is:

                           a=setup:active
                           a=connection:new

Top      ToC       Page 12 
   This example demonstrates a new connection that will be initiated
   from the owner of the SDP payload.  The connection details are
   contained in the SDP answer received from the UAS.  A full example of
   an SDP payload compliant to this specification can be viewed in
   Section 3.  Once the SDP has been constructed along with the
   remainder of the SIP INVITE request (as defined in [RFC3261]), it can
   be sent to the appropriate location.  The SIP INVITE dialog usage and
   appropriate control connection is then established.

   A SIP UAC constructing an offer MUST include the 'cfw-id' SDP
   attribute as defined in Section 9.2.  The 'cfw-id' attribute
   indicates an identifier that can be used within the Control Channel
   to correlate the Control Channel with this SIP INVITE dialog usage.
   The 'cfw-id' attribute MUST be unique in the context of the
   interaction between the UAC and UAS and MUST NOT clash with instances
   of the 'cfw-id' used in other SIP offer/answer exchanges.  The value
   chosen for the 'cfw-id' attribute MUST be used for the entire
   duration of the associated SIP INVITE dialog usage and not be changed
   during updates to the offer/answer exchange.  This applies
   specifically to the 'connection' attribute as defined in [RFC4145].
   If a SIP UAC wants to change some other parts of the SDP but reuse
   the already established connection, it uses 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 the connection, 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 MUST NOT change.  One is simply negotiating the underlying
   TCP connection between endpoints but always using the same Control
   Framework session, which is 1:1 for the lifetime of the SIP INVITE
   dialog usage.

   A non-2xx-class final SIP response (3xx, 4xx, 5xx, and 6xx) received
   for the INVITE request indicates that no SIP INVITE dialog usage has
   been created and is treated as specified by SIP [RFC3261].
   Specifically, support of this specification is negotiated through the
   presence of the media type defined in this specification.  The
   receipt of a SIP error response such as "488" indicates that the
   offer contained in a request is not acceptable.  The inclusion of the
   media line associated with this specification in such a rejected
   offer indicates to the client generating the offer that this could be
   due to the receiving client not supporting this specification.  The
   client generating the offer MUST act as it would normally on
   receiving this response, as per [RFC3261].  Media streams can also be
   rejected by setting the port to "0" in the "m=" line of the session
   description, as defined in [RFC3264].  A client using this
   specification MUST be prepared to receive an answer where the "m="
   line it inserted for using the Control Framework has been set to "0".

Top      ToC       Page 13 
   In this situation, the client will act as it would for any other
   media type with a port set to "0".

4.2.  Control Server SIP UAS Behavior

   On receiving a SIP INVITE request, an external Server (SIP UAS)
   inspects the message for indications of support for the mechanisms
   defined in this specification.  This is achieved through inspection
   of the session description of the offer message and identifying
   support for the application/cfw MIME type in the SDP.  If the SIP UAS
   wishes to construct a reliable response that conveys support for the
   extension, it MUST follow the mechanisms defined in [RFC3261].  If
   support is conveyed in a reliable SIP provisional response, the
   mechanisms in [RFC3262] MUST also be used.  It should be noted that
   the SDP offer is not restricted to the initial INVITE request and MAY
   appear in any series of messages that are compliant to [RFC3261],
   [RFC3262], [RFC3311], and [RFC3264].

   When constructing an answer, the SDP payload MUST be constructed
   using the semantic (connection, media, and attribute) defined in
   Section 4.1 using valid local settings and also with full compliance
   to the COMEDIA [RFC4145] specification.  For example, the SDP
   attributes included in the answer constructed for the example offer
   provided in Section 4.1 would look as follows:

                           a=setup:passive
                           a=connection:new

   A client constructing an answer MUST include the 'cfw-id' SDP
   attribute as defined in Section 9.2.  This attribute MUST be unique
   in the context of the interaction between the UAC and UAS and MUST
   NOT clash with instances of the 'cfw-id' used in other SIP offer/
   answer exchanges.  The 'cfw-id' MUST be different from the 'cfw-id'
   value received in the offer as it is used to uniquely identify and
   distinguish between multiple endpoints that generate SDP answers.
   The value chosen for the 'cfw-id' attribute MUST be used for the
   entire duration of the associated SIP INVITE dialog usage and not be
   changed during updates to the offer/answer exchange.

   Once the SDP answer has been constructed, it is sent using standard
   SIP mechanisms.  Depending on the contents of the SDP payloads that
   were negotiated using the offer/answer exchange, a reliable
   connection will be established between the Controlling UAC and
   External Server UAS entities.  The newly established connection is
   now available to exchange Control Command primitives.  The state of
   the SIP INVITE dialog usage and the associated Control Channel are
   now implicitly linked.  If either party wishes to terminate a Control
   Channel, it simply issues a SIP termination request (for example, a

Top      ToC       Page 14 
   SIP BYE request or appropriate response in an early SIP INVITE dialog
   usage).  The Control Channel therefore lives for the duration of the
   SIP INVITE dialog usage.

   A UAS receiving a SIP OPTIONS request MUST respond appropriately as
   defined in [RFC3261].  The UAS MUST include the media types supported
   in the SIP 200 OK response in a SIP 'Accept' header to indicate the
   valid media types.

5.  Establishing Media Streams - Control Client SIP UAC Behavior

   It is intended that the Control Framework will be used within a
   variety of architectures for a wide range of functions.  One of the
   primary functions will be the use of the Control Channel to apply
   multiple specific Control Package commands to media sessions
   established by SIP INVITE dialogs (media dialogs) with a given remote
   server.  For example, the Control Server might send a command to
   generate audio media (such as an announcement) on an RTP stream
   between a User Agent and a media server.

   SIP INVITE dialogs used to establish media sessions (see Figure 2) on
   behalf of User Agents MAY contain more than one Media Description (as
   defined by "m=" in the SDP).  The Control Client MUST include a media
   label attribute, as defined in [RFC4574], for each "m=" definition
   received that is to be directed to an entity using the Control
   Framework.  This allows the Control Client to later explicitly direct
   commands on the Control Channel at a specific media line (m=).

   This framework identifies the referencing of such associated media
   dialogs as extremely important.  A connection reference attribute has
   been specified that can optionally be imported into any Control
   Package.  It is intended that this will reduce the repetitive
   specifying of dialog reference language.  The schema can be found in
   Appendix A.1.

   Similarly, the ability to identify and apply commands to a group of
   associated media dialogs (multiparty) is also identified as a common
   structure that could be defined and reused, for example, playing a
   prompt to all participants in a Conference.  The schema for such
   operations can also be found in Appendix A.1.

   Support for both the common attributes described here is specified as
   part of each Control Package definition, as detailed in Section 8.


Next RFC Part