Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6230

Media Control Channel Framework

Pages: 49
Proposed Standard
Errata
Part 2 of 3 – Pages 15 to 36
First   Prev   Next

Top   ToC   RFC6230 - Page 15   prevText

6. Control Framework Interactions

In this document, the use of the COMEDIA specification allows for a Control Channel to be set up in either direction as a result of a SIP INVITE transaction. SIP provides a flexible negotiation mechanism to establish the Control Channel, but there needs to be a mechanism within the Control Channel to correlate it with the SIP INVITE dialog usage implemented for its establishment. A Control Client receiving an incoming connection (whether it be acting in the role of UAC or UAS) has no way of identifying the associated SIP INVITE dialog usage as it could be simply listening for all incoming connections on a specific port. The following steps, which implementations MUST support, allow a connecting UA (that is, the UA with the active role in COMEDIA) to identify the associated SIP INVITE dialog usage that triggered the connection. Unless there is an alternative dialog association mechanism used, the UAs MUST carry out these steps before any other signaling on the newly created Control Channel. o Once the connection has been established, the UA acting in the active role (active UA) to initiate the connection MUST send a Control Framework SYNC request. The SYNC request MUST be constructed as defined in Section 9.1 and MUST contain the 'Dialog-ID' message header. o The 'Dialog-ID' message header is populated with the value of the local 'cfw-id' media-level attribute that was inserted by the same client in the SDP offer/answer exchange to establish the Control Channel. This allows for a correlation between the Control Channel and its associated SIP INVITE dialog usage. o On creating the SYNC request, the active UA MUST follow the procedures outlined in Section 6.3.3. This provides details of connection keep-alive messages. 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 the negotiation mechanism used to determine the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection. o The UA in the active role for the connection creation MUST then send the SYNC request. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a 2xx-class SIP response, it MUST wait for an incoming SIP ACK message before issuing the SYNC. If the UA in the active role for the connection creation is a SIP UAS and has generated its SDP response in a reliable 1XX class SIP response, it MUST wait for an incoming SIP PRACK message before issuing the SYNC.
Top   ToC   RFC6230 - Page 16
      If the UA in the active role for the connection creation is a SIP
      UAC, it MUST send the SYNC message immediately on establishment of
      the Control Channel.  It MUST then wait for a period of at least
      2*'Transaction-Timeout' to receive a response.  It MAY choose a
      longer time to wait, but it MUST NOT be shorter than 'Transaction-
      Timeout'.  In general, a Control Framework transaction MUST
      complete within 20 (2*'Transaction-Timeout') seconds and is
      referenced throughout the document as 'Transaction-Timeout'.

   o  If no response is received for the SYNC message, a timeout occurs
      and the Control Channel is terminated along with the associated
      SIP INVITE dialog usage.  The active UA MUST issue a BYE request
      to terminate the SIP INVITE dialog usage.

   o  If the active UA receives a 481 response from the passive UA, this
      means the SYNC request was received, but the associated SIP INVITE
      dialog usage specified in the SYNC message does not exist.  The
      active client MUST terminate the Control Channel.  The active UA
      MUST issue a SIP BYE request to terminate the SIP INVITE dialog
      usage.

   o  All other error responses received for the SYNC request are
      treated as detailed in this specification and also result in the
      termination of the Control Channel and the associated SIP INVITE
      dialog usage.  The active UA MUST issue a BYE request to terminate
      the SIP INVITE dialog usage.

   o  The receipt of a 200 response to a SYNC message implies that the
      SIP INVITE dialog usage and control connection have been
      successfully correlated.  The Control Channel can now be used for
      further interactions.

   SYNC messages can be sent at any point while the Control Channel is
   open from either side, once the initial exchange is complete.  If
   present, the contents of the 'Keep-Alive' and 'Dialog-ID' headers
   MUST NOT change.  New values of the 'Keep-Alive' and 'Dialog-ID'
   headers have no relevance as they are negotiated for the lifetime of
   the Media Control Channel Framework session.

   Once a successful Control Channel has been established, as defined in
   Sections 4.1 and 4.2, and the connection has been correlated, as
   described in previous paragraphs, the two entities are now in a
   position to exchange Control Framework messages.  The following sub-
   sections specify the general behavior for constructing Control
   Framework requests and responses.  Section 6.3 specifies the core
   Control Framework methods and their transaction processing.
Top   ToC   RFC6230 - Page 17

6.1. General Behavior for Constructing Requests

An entity acting as a Control Client that constructs and sends requests on a Control Channel MUST adhere to the syntax defined in Section 9. Note that either entity can act as a Control Client depending on individual package requirements. Control Commands MUST also adhere to the syntax defined by the Control Packages negotiated in Sections 4.1 and 4.2 of this document. A Control Client MUST create a unique transaction and associated identifier for insertion in the request. The transaction identifier is then included in the first line of a Control Framework message along with the method type, as defined in the ABNF in Section 9. The first line starts with the "CFW" token for the purpose of easily extracting the transaction identifier. The transaction identifier MUST be unique in the context of the interaction between the Control Client and Control Server. This unique property helps avoid clashes when multiple client entities could be creating transactions to be carried out on a single receiving server. All required, mandatory, and optional Control Framework headers are then inserted into the request with appropriate values (see relevant individual header information for explicit detail). A 'Control-Package' header MUST also be inserted with the value indicating the Control Package to which this specific request applies. Multiple packages can be negotiated per Control Channel using the SYNC message discussed in Section 6.3.4.2. Any Framework message that contains an associated payload MUST also include the 'Content-Type' and 'Content-Length' message headers, which indicate the MIME type of the payload specified by the individual Control Framework packages and the size of the message body represented as a whole decimal number of octets, respectively. If no associated payload is to be added to the message, the 'Content- Length' header MUST have a value of '0'. A Server receiving a Framework message request MUST respond with an appropriate response (as defined in Section 6.2). Control Clients MUST wait for a minimum of 2*'Transaction-Timeout' for a response before considering the transaction a failure and tidying state appropriately depending on the extension package being used.

6.2. General Behavior for Constructing Responses

An entity acting as a Control Server, on receiving a request, MUST generate a response within the 'Transaction-Timeout', as measured from the Control Client. The response MUST conform to the ABNF defined in Section 9. The first line of the response MUST contain the transaction identifier used in the first line of the request, as
Top   ToC   RFC6230 - Page 18
   defined in Section 6.1.  Responses MUST NOT include the 'Status' or
   'Timeout' message headers, and these MUST be ignored if received by a
   Client in a response.

   A Control Server MUST include a status code in the first line of the
   response.  If there is no error, the Server responds with a 200
   Control Framework status code, as defined in Section 7.1.  The 200
   response MAY include message bodies.  If the response contains a
   payload, the message MUST include the 'Content-Length' and 'Content-
   Type' headers.  When the Control Client receives a 2xx-class
   response, the Control Command transaction is complete.

   If the Control Server receives a request, like CONTROL, that the
   Server understands, but the Server knows processing the command will
   exceed the 'Transaction-Timeout', then the Server MUST respond with a
   202 status code in the first line of the response.  Following the
   initial response, the server will send one or more REPORT messages as
   described in Section 6.3.2.  A Control Package MUST explicitly define
   the circumstances under which the server sends 200 and 202 messages.

   If a Control Server encounters problems with a Control Framework
   request (like REPORT or CONTROL), an appropriate error code MUST be
   used in the response, as listed in Section 7.  The generation of a
   non-2xx-class response code to a Control Framework request (like
   CONTROL or REPORT) will indicate failure of the transaction, and all
   associated transaction state and resources MUST be terminated.  The
   response code may provide an explicit indication of why the
   transaction failed, which might result in a re-submission of the
   request depending on the extension package being used.

6.3. Transaction Processing

The Control Framework defines four types of requests (methods): CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support sending and receiving these four methods. The following sub-sections specify each Control Framework method and its associated transaction processing.

6.3.1. CONTROL Transactions

A CONTROL message is used by the Control Client to pass control- related information to a Control Server. It is also used as the event-reporting mechanism in the Control Framework. Reporting events is simply another usage of the CONTROL message, which is permitted to be sent in either direction between two participants in a session, carrying the appropriate payload for an event. The message is constructed in the same way as any standard Control Framework
Top   ToC   RFC6230 - Page 19
   message, as discussed in Section 6.1 and defined in Section 9.  A
   CONTROL message MAY contain a message body.  The explicit Control
   Command(s) of the message payload contained in a CONTROL message are
   specified in separate Control Package specifications.  Separate
   Control Package specifications MUST conform to the format defined in
   Section 8.4.  A CONTROL message containing a payload MUST include a
   'Content-Type' header.  The payload MUST be one of the payload types
   defined by the Control Package.  Individual packages MAY allow a
   CONTROL message that does not contain a payload.  This could in fact
   be a valid message exchange within a specific package; if it's not,
   an appropriate package-level error message MUST be generated.

6.3.2. REPORT Transactions

A 'REPORT' message is used by a Control Server when processing of a CONTROL command extends beyond the 'Transaction-Timeout', as measured from the Client. In this case, the Server returns a 202 response. The Server returns status updates and the final results of the command in subsequent REPORT messages. All REPORT messages MUST contain the same transaction ID in the request start line that was present in the original CONTROL transaction. This correlates extended transactions with the original CONTROL transaction. A REPORT message containing a payload MUST include the 'Content-Type' and 'Content-Length' headers indicating the payload MIME type [RFC2045] defined by the Control Package and the length of the payload, respectively.
6.3.2.1. Reporting the Status of Extended Transactions
On receiving a CONTROL message, a Control Server MUST respond within 'Transaction-Timeout' with a status code for the request, as specified in Section 6.2. If the processing of the command completes within that time, a 200 response code MUST be sent. If the command does not complete within that time, the response code 202 MUST be sent indicating that the requested command is still being processed and the CONTROL transaction is being extended. The REPORT method is then used to update and terminate the status of the extended transaction. The Control Server should not wait until the last possible opportunity to make the decision of issuing a 202 response code and should ensure that it has plenty of time for the response to arrive at the Control Client. If it does not have time, transactions will be terminated (timed out) at the Control Client before completion.
Top   ToC   RFC6230 - Page 20
   A Control Server issuing a 202 response MUST ensure the message
   contains a 'Timeout' message header.  This header MUST have a value
   in seconds that is the amount of time the recipient of the 202
   message MUST wait before assuming that there has been a problem and
   terminating the extended transaction and associated state.

   The initial REPORT message MUST contain a 'Seq' (Sequence) message
   header with a value equal to '1'.  Note: the 'Seq' numbers at both
   Control Client and Control Server for Framework messages are
   independent.

   All REPORT messages for an extended CONTROL transaction MUST contain
   a 'Timeout' message header.  This header will contain a value in
   seconds that is the amount of time the recipient of the REPORT
   message MUST wait before assuming that there has been a problem and
   terminating the extended transaction and associated state.  On
   receiving a REPORT message with a 'Status' header of 'update', the
   Control Client MUST reset the timer for the associated extended
   CONTROL transaction to the indicated timeout period.  If the timeout
   period approaches and no intended REPORT messages have been
   generated, the entity acting as a Control Framework UAS for the
   interaction MUST generate a REPORT message containing, as defined in
   this paragraph, a 'Status' header of 'update' with no associated
   payload.  Such a message acts as a timeout refresh and in no way
   impacts the extended transaction because no message body or semantics
   are permitted.  It is RECOMMENDED that a minimum value of 10 and a
   maximum value of 15 seconds be used for the value of the 'Timeout'
   message header.  It is also RECOMMENDED that a Control Server refresh
   the timeout period of the CONTROL transaction at an interval that is
   not too close to the expiry time.  A value of 80% of the timeout
   period could be used.  For example, if the timeout period is 10
   seconds, the Server would refresh the transaction after 8 seconds.

   Subsequent REPORT messages that provide additional information
   relating to the extended CONTROL transaction MUST also include and
   increment by 1 the 'Seq' header value.  A REPORT message received
   that has not been incremented by 1 MUST be responded to with a 406
   response and the extended transaction MUST be considered terminated.
   On receiving a 406 response, the extended transaction MUST be
   terminated.  REPORT messages MUST also include a 'Status' header with
   a value of 'update'.  These REPORT messages sent to update the
   extended CONTROL transaction status MAY contain a message body, as
   defined by individual Control Packages and specified in Section 8.5.
   A REPORT message sent updating the extended transaction also acts as
   a timeout refresh, as described earlier in this section.  This will
   result in a transaction timeout period at the initiator of the
   original CONTROL request being reset to the interval contained in the
   'Timeout' message header.
Top   ToC   RFC6230 - Page 21
   When all processing for an extended CONTROL transaction has taken
   place, the entity acting as a Control Server MUST send a terminating
   REPORT message.  The terminating REPORT message MUST increment the
   value in the 'Seq' message header by the value of '1' from the
   previous REPORT message.  It MUST also include a 'Status' header with
   a value of 'terminate' and MAY contain a message body.  It MUST also
   contain a 'Timeout' message header with a valid value.  The inclusion
   of the 'Timeout' header is for consistency, and its value is ignored.
   A Control Framework UAC can then clean up any pending state
   associated with the original CONTROL transaction.

6.3.3. K-ALIVE Transactions

The protocol defined in this document may be used in various network architectures. This includes a wide range of deployments where the clients could be co-located in a secured, private domain, or spread across disparate domains that require traversal of devices such as Network Address Translators (NATs) and firewalls. A keep-alive mechanism enables the Control Channel to be kept active during times of inactivity. This is because many firewalls have a timeout period after which connections are closed. This mechanism also provides the ability for application-level failure detection. It should be noted that the following procedures apply only to the Control Channel being created. For details relating to the SIP keep-alive mechanism, implementers should seek guidance from SIP Outbound [RFC5626]. The following keep-alive procedures MUST be implemented. Specific 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 the keep-alive mechanism defined in this section, even when in a co- located architecture, will reduce the ability to detect application- level errors, especially during long periods of inactivity. Once the SIP INVITE dialog usage has been established and the underlying Control Channel has been set up, including the initial correlation handshake using SYNC as discussed in Section 6, both entities acting in the active and passive roles, as defined in COMEDIA [RFC4145], MUST start a keep-alive timer equal to the value negotiated during the Control Channel SYNC request/response exchange. This is the value from the 'Keep-Alive' header in seconds.
6.3.3.1. Behavior for an Entity in an Active Role
When in an active role, a K-ALIVE message MUST be generated before the local keep-alive timer fires. An active entity is free to send the K-ALIVE message whenever it chooses. It is RECOMMENDED for the entity to issue a K-ALIVE message after 80% of the local keep-alive timer. On receiving a 200 OK Control Framework message for the
Top   ToC   RFC6230 - Page 22
   K-ALIVE request, the active entity MUST reset the local keep-alive
   timer.  If no 200 OK response is received to the K-ALIVE message, or
   a transport-level problem is detected by some other means, before the
   local keep-alive timer fires, the active entity MAY use COMEDIA re-
   negotiation procedures to recover the connection.  Otherwise, the
   active entity MUST tear down the SIP INVITE dialog and recover the
   associated Control Channel resources.

6.3.3.2. Behavior for an Entity in a Passive Role
When acting as a passive entity, a K-ALIVE message must be received before the local keep-alive timer fires. When a K-ALIVE request is received, the passive entity MUST generate a 200 OK Control Framework response and reset the local keep-alive timer. No other Control Framework response is valid. If no K-ALIVE message is received (or a transport level problem is detected by some other means) before the local keep-alive timer fires, the passive entity MUST tear down the SIP INVITE dialog and recover the associated Control Channel resources.

6.3.4. SYNC Transactions

The initial SYNC request on a Control Channel is used to negotiate the timeout period for the Control Channel keep-alive mechanism and to allow clients and servers to learn the Control Packages that each supports. Subsequent SYNC requests MAY be used to change the set of Control Packages that can be used on the Control Channel.
6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction
The initial SYNC request allows the timeout period for the Control Channel keep-alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request: o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to active, the 'Keep-Alive' header MUST be included in the SYNC message generated by the offerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to 120 seconds (this is consistent with SIP Outbound [RFC5626]). The value of the 'Keep-Alive' header MUST NOT exceed 600 seconds. The client that generated the SDP "Answer" (the passive client) MUST copy the 'Keep-Alive' header into the 200 response to the SYNC message with the same value. o If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to passive, the 'Keep-Alive' header parameter MUST be included in the SYNC message generated by the answerer. The value of the 'Keep-Alive' header SHOULD be in the range of 95 to
Top   ToC   RFC6230 - Page 23
      120 seconds.  The client that generated the SDP offer (the passive
      client) MUST copy the 'Keep-Alive' header into the 200 response to
      the SYNC message with the same value.

   o  If the Client initiating the SDP offer has a COMEDIA 'setup'
      attribute equal to 'actpass', the 'Keep-Alive' header parameter
      MUST be included in the SYNC message of the entity who is the
      active participant in the SDP session.  If the client generating
      the subsequent SDP answer places a value of 'active' in the
      COMEDIA SDP 'setup' attribute, it will generate the SYNC request
      and include the 'Keep-Alive' header.  The value SHOULD be in the
      range 95 to 120 seconds.  If the client generating the subsequent
      SDP answer places a value of 'passive' in the COMEDIA 'setup'
      attribute, the original UA making the SDP will generate the SYNC
      request and include the 'Keep-Alive' header.  The value SHOULD be
      in the range 95 to 120 seconds.

   o  If the initial negotiated offer/answer results in a COMEDIA
      'setup' attribute equal to 'holdconn', the initial SYNC mechanism
      will occur when the offer/answer exchange is updated and the
      active/passive roles are resolved using COMEDIA.

   The previous steps ensure that the entity initiating the Control
   Channel connection is always the one specifying the keep-alive
   timeout period.  It will always be the initiator of the connection
   who generates the K-ALIVE messages.

   Once negotiated, the keep-alive timeout applies for the remainder of
   the Control Framework session.  Any subsequent SYNC messages
   generated in the Control Channel do not impact the negotiated keep-
   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 ignored.

6.3.4.2. Package Negotiation
As part of the SYNC message exchange, a client generating the request MUST include a 'Packages' header, as defined in Section 9. The 'Packages' header contains a list of all Control Framework packages that can be supported within this control session, from the perspective of the client creating the SYNC message. All Channel Framework package names MUST be tokens that adhere to the rules set out in Section 8. The 'Packages' header of the initial SYNC message MUST contain at least one value. A server receiving the initial SYNC request MUST examine the contents of the 'Packages' header. If the server supports at least one of the packages listed in the request, it MUST respond with a 200 response
Top   ToC   RFC6230 - Page 24
   code.  The response MUST contain a 'Packages' header that lists the
   supported packages that are in common with those from the 'Packages'
   header of the request (either all or a subset).  This list forms a
   common set of Control Packages that are supported by both parties.
   Any Control Packages supported by the server that are not listed in
   the 'Packages' header of the SYNC request MAY be placed in the
   'Supported' header of the response.  This provides a hint to the
   client that generated the SYNC request about additional packages
   supported by the server.

   If no common packages are supported by the server receiving the SYNC
   message, it MUST respond with a 422 error response code.  The error
   response MUST contain a 'Supported' header indicating the packages
   that are supported.  The initiating client can then choose to either
   re-submit a new SYNC message based on the 422 response or consider
   the interaction a failure.  This would lead to termination of the
   associated SIP INVITE dialog by sending a SIP BYE request, as per
   [RFC3261].

   Once the initial SYNC transaction is completed, either client MAY
   choose to send a subsequent new SYNC message to re-negotiate the
   packages that are supported within the Control Channel.  A new SYNC
   message whose 'Packages' header has different values from the
   previous SYNC message can effectively add and delete the packages
   used in the Control Channel.  If a client receiving a subsequent SYNC
   message does not wish to change the set of packages, it MUST respond
   with a 421 Control Framework response code.  Subsequent SYNC messages
   MUST NOT change the value of the 'Dialog-ID' and 'Keep-Alive' Control
   Framework headers that appeared in the original SYNC negotiation.

   An entity MAY honor Control Framework commands relating to a Control
   Package it no longer supports after package re-negotiation.  When the
   entity does not wish to honor such commands, it MUST respond to the
   request with a 420 response.

7. Response Code Descriptions

The following response codes are defined for transaction responses to methods defined in Section 6.1. All response codes in this section MUST be supported and can be used in response to both CONTROL and REPORT messages except that a 202 MUST NOT be generated in response to a REPORT message. Note that these response codes apply to Framework Transactions only. Success or error indications for Control Commands MUST be treated as the result of a Control Command and returned in either a 200 response or REPORT message.
Top   ToC   RFC6230 - Page 25

7.1. 200 Response Code

The framework protocol transaction completed successfully.

7.2. 202 Response Code

The framework protocol transaction completed successfully and additional information will be provided at a later time through the REPORT mechanism defined in Section 6.3.2.

7.3. 400 Response Code

The request was syntactically incorrect.

7.4. 403 Response Code

The server understood the request, but is refusing to fulfill it. The client SHOULD NOT repeat the request.

7.5. 405 Response Code

Method not allowed. The primitive is not supported.

7.6. 406 Response Code

Message out of sequence.

7.7. 420 Response Code

Intended target of the request is for a Control Package that is not valid for the current session.

7.8. 421 Response Code

Recipient does not wish to re-negotiate Control Packages at this moment in time.

7.9. 422 Response Code

Recipient does not support any Control Packages listed in the SYNC message.

7.10. 423 Response Code

Recipient has an existing transaction with the same transaction ID.
Top   ToC   RFC6230 - Page 26

7.11. 481 Response Code

The transaction of the request does not exist. In response to a SYNC request, the 481 response code indicates that the corresponding SIP INVITE dialog usage does not exist.

7.12. 500 Response Code

The recipient does not understand the request.

8. Control Packages

Control Packages specify behavior that extends the capability defined in this document. Control Packages MUST NOT weaken statements of "MUST" and "SHOULD" strength in this document. A Control Package MAY strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST" if justified by the specific usage of the framework. In addition to the usual sections expected in Standards-Track RFCs and SIP extension documents, authors of Control Packages need to address each of the issues detailed in the following sub-sections. The following sections MUST be used as a template and included appropriately in all Control-Package specifications. To reiterate, the following sections do not solely form the basis of all Control- Package specifications but are included as a minimum to provide essential package-level information. A Control-Package specification can take any valid form it wishes as long as it includes at least the following information listed in this section.

8.1. Control Package Name

This section MUST be present in all extensions to this document and provides a token name for the Control Package. The section MUST include information that appears in the IANA registration of the token. Information on registering Control Package tokens is contained in Section 13.

8.2. Framework Message Usage

The Control Framework defines a number of message primitives that can be used to exchange commands and information. There are no limitations restricting the directionality of messages passed down a Control Channel. This section of a Control Package document MUST explicitly detail the types of Framework messages (Methods) that can be used as well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type.
Top   ToC   RFC6230 - Page 27

8.3. Common XML Support

This optional section is only included in a Control Package if the attributes for media dialog or conference reference are required, as defined and discussed in Appendix A.1. The Control Package will make strong statements (using language from RFC 2119 [RFC2119]) if the XML schema defined in Appendix A.1 is to be supported. If only part of the schema is required (for example, just 'connectionid' or 'conferenceid'), the Control Package will make equally strong statements (using language from RFC 2119 [RFC2119]).

8.4. CONTROL Message Bodies

This mandatory section of a Control Package defines the control body that can be contained within a CONTROL command request, as defined in Section 6, or that no Control Package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type that apply to a CONTROL command request and, optionally, the associated 200 response. For Control Packages that do not have a Control Package body, making such a statement satisfies the "MUST" strength of this section in the Control Package document.

8.5. REPORT Message Bodies

This mandatory section of a Control Package defines the REPORT body that can be contained within a REPORT command request, as defined in Section 6, or that no report package body is required. This section MUST indicate the location of detailed syntax definitions and semantics for the appropriate MIME [RFC2045] body type. It should be noted that the Control Framework specification does allow for payloads to exist in 200 responses to CONTROL messages (as defined in this document). An entity that is prepared to receive a payload type in a REPORT message MUST also be prepared to receive the same payload in a 200 response to a CONTROL message. For Control Packages that do not have a Control Package body, stating such satisfies the "MUST" strength of this section in the Control Package document.

8.6. Audit

Auditing of various Control Package properties such as capabilities and resources (package-level meta-information) is extremely useful. Such meta-data usually has no direct impact on Control Framework interactions but allows for contextual information to be learnt. Control Packages are encouraged to make use of Control Framework interactions to provide relevant package audit information.
Top   ToC   RFC6230 - Page 28
   This section SHOULD include the following information:

   o  If an auditing capability is available in this package.

   o  How auditing information is triggered (for example, using a
      Control Framework CONTROL message) and delivered (for example, in
      a Control Framework 200 response).

   o  The location of the audit query and response format for the
      payload (for example, it could be a separate XML schema OR part of
      a larger XML schema).

8.7. Examples

It is strongly RECOMMENDED that Control Packages provide a range of message flows that represent common flows using the package and this framework document.

9. Formal Syntax

9.1. Control Framework Formal Syntax

The Control Framework interactions use the UTF-8 transformation format as defined in [RFC3629]. The syntax in this section uses the Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including types 'DIGIT', 'CRLF', and 'ALPHA'. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are not case-sensitive. control-req-or-resp = control-request / control-response control-request = control-req-start *headers CRLF [control-content] control-response = control-resp-start *headers CRLF [control-content] control-req-start = pCFW SP trans-id SP method CRLF control-resp-start = pCFW SP trans-id SP status-code CRLF pCFW = %x43.46.57; CFW in caps trans-id = alpha-num-token method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method mCONTROL = %x43.4F.4E.54.52.4F.4C ; CONTROL in caps mREPORT = %x52.45.50.4F.52.54 ; REPORT in caps mSYNC = %x53.59.4E.43 ; SYNC in caps mK-ALIVE = %x4B.2D.41.4C.49.56.45 ; K-ALIVE in caps other-method = 1*UPALPHA status-code = 3*DIGIT ; any code defined in this and other documents
Top   ToC   RFC6230 - Page 29
  headers = header-name CRLF

  header-name = (Content-Length
   /Content-Type
   /Control-Package
   /Status
   /Seq
   /Timeout
   /Dialog-ID
   /Packages
   /Supported
   /Keep-alive
   /ext-header)

  Content-Length = "Content-Length:" SP 1*DIGIT
  Control-Package = "Control-Package:" SP 1*alpha-num-token
  Status = "Status:" SP ("update" / "terminate" )
  Timeout = "Timeout:" SP 1*DIGIT
  Seq = "Seq:" SP 1*DIGIT
  Dialog-ID = "Dialog-ID:" SP dialog-id-string
  Packages = "Packages:" SP package-name *(COMMA package-name)
  Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum)
  Keep-alive = "Keep-Alive:" SP kalive-seconds

  dialog-id-string = alpha-num-token
  package-name = alpha-num-token
  supprtd-alphanum = alpha-num-token
  kalive-seconds = 1*DIGIT

  alpha-num-token = ALPHANUM  3*31alpha-num-tokent-char
  alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"

  control-content = *OCTET

  Content-Type = "Content-Type:" SP media-type
  media-type = type "/" subtype *(SP ";" gen-param )
  type = token    ; Section 4.2 of RFC 4288
  subtype = token ; Section 4.2 of RFC 4288

  gen-param = pname [ "=" pval ]
  pname = token
  pval  = token / quoted-string

  token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
             / %x30-39 / %x41-5A / %x5E-7E)
Top   ToC   RFC6230 - Page 30
  quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
  qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
              / UTF8-NONASCII
  qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
  BACKSLASH = "\"
  UPALPHA  = %x41-5A
  ALPHANUM = ALPHA / DIGIT

  ext-header = hname ":" SP hval CRLF

  hname = ALPHA *token
  hval = utf8text

  utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)

  UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 ; From RFC 3629

   The following table details a summary of the headers that can be
   contained in Control Framework interactions.

         Header field        Where    CONTROL REPORT SYNC  K-ALIVE
         ___________________________________________________________
         Content-Length                  o      o      -      -
         Control-Package       R         m      -      -      -
         Seq                             -      m      -      -
         Status                R         -      m      -      -
         Timeout               R         -      m      -      -
         Timeout              202        -      m      -      -
         Dialog-ID             R         -      -      m      -
         Packages                        -      -      m      -
         Supported             r         -      -      o      -
         Keep-Alive            R         -      -      o      -
         Content-Type                    o      o      -      -

       Table 1: Summary of Headers in Control Framework Interactions

   The notation used in Table 1 is as follows:

 R: header field may only appear in requests.
 r: header field may only appear in responses.
 2xx, 4xx, etc.: response codes with which the header field can be used.
 [blank]: header field may appear in either requests or responses.
 m: header field is mandatory.
 o: header field is optional.
 -: header field is not applicable (ignored if present).
Top   ToC   RFC6230 - Page 31

9.2. Control Framework Dialog Identifier SDP Attribute

This specification defines a new media-level value attribute: 'cfw-id'. Its formatting in SDP is described by the following ABNF [RFC5234]. cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF cfw-id-name = token token = 1*(token-char) token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E The token-char and token elements are defined in [RFC4566] but included here to provide support for the implementer of this SDP feature.

10. Examples

The following examples provide an abstracted flow of Control Channel establishment and Control Framework message exchange. The SIP signaling is prefixed with the token 'SIP'. All other messages are Control Framework interactions defined in this document. In this example, the Control Client establishes a Control Channel, SYNCs with the Control Server, and issues a CONTROL request that can't be completed within the 'Transaction-Timeout', so the Control Server returns a 202 response code to extend the transaction. The Control Server then follows with REPORTs until the requested action has been completed. The SIP INVITE dialog is then terminated.
Top   ToC   RFC6230 - Page 32
            Control Client                                Control Server
                   |                                             |
                   |       (1) SIP INVITE                        |
                   |  ---------------------------------------->  |
                   |                                             |
                   |       (2) SIP 200                           |
                   |  <---------------------------------------   |
                   |                                             |
                   |       (3) SIP ACK                           |
                   |  ---------------------------------------->  |
                   |                                             |
                   |==>=======================================>==|
                   |         Control Channel Established         |
                   |==>=======================================>==|
                   |                                             |
                   |       (4) SYNC                              |
                   |  ---------------------------------------->  |
                   |                                             |
                   |       (5) 200                               |
                   |  <---------------------------------------   |
                   |                                             |
                   |       (6) CONTROL                           |
                   |  ---------------------------------------->  |
                   |                                             |

   (1)   Control Client-->Control Server (SIP): INVITE
         sip:control-server@example.com

   INVITE sip:control-server@example.com SIP/2.0
   To: <sip:control-server@example.com>
   From: <sip:control-client@example.com>;tag=8937498
   Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123
   CSeq: 1 INVITE
   Max-Forwards: 70
   Call-ID: 893jhoeihjr8392@example.com
   Contact: <sip:control-client@pc1.example.com>
   Content-Type: application/sdp
   Content-Length: 206

   v=0
   o=originator 2890844526 2890842808 IN IP4 controller.example.com
   s=-
   c=IN IP4 control-client.example.com
   m=application 49153 TCP cfw
   a=setup:active
   a=connection:new
   a=cfw-id:fndskuhHKsd783hjdla
Top   ToC   RFC6230 - Page 33
   (2)   Control Server-->Control Client (SIP): 200 OK

SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc2.example.com>
Content-Type: application/sdp
Content-Length: 203

v=0
o=responder 2890844600 2890842900 IN IP4 controller.example.com
s=-
c=IN IP4 control-server.example.com
m=application 49153 TCP cfw
a=setup:passive
a=connection:new
a=cfw-id:7JeDi23i7eiysi32

   (3)   Control Client-->Control Server (SIP): ACK

   (4)   Control Client opens a TCP connection to the Control Server.
         The connection can now be used to exchange Control Framework
         messages.  Control Client-->Control Server (Control Framework
         message): SYNC.

   CFW 8djae7khauj SYNC
   Dialog-ID: fndskuhHKsd783hjdla
   Keep-Alive: 100
   Packages: msc-ivr-basic/1.0

   (5)   Control Server-->Control Client (Control Framework message):
         200.

   CFW 8djae7khauj 200
   Keep-Alive: 100
   Packages: msc-ivr-basic/1.0
   Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0

   (6)   Once the SYNC process has completed, the connection can now be
         used to exchange Control Framework messages.  Control
         Client-->Control Server (Control Framework message): CONTROL.

   CFW i387yeiqyiq CONTROL
   Control-Package: <package-name>
   Content-Type: example_content/example_content
Top   ToC   RFC6230 - Page 34
   Content-Length: 11

   <XML BLOB/>

   (7)   Control Server-->Control Client (Control Framework message):
         202.

   CFW i387yeiqyiq 202
   Timeout: 10

   (8)   Control Server-->Control Client (Control Framework message):
         REPORT.

   CFW i387yeiqyiq REPORT
   Seq: 1
   Status: update
   Timeout: 10

   (9)   Control Client-->Control Server (Control Framework message):
         200.

   CFW i387yeiqyiq 200
   Seq: 1

   (10)  Control Server-->Control Client (Control Framework message):
         REPORT.

   CFW i387yeiqyiq REPORT
   Seq: 2
   Status: update
   Timeout: 10
   Content-Type: example_content/example_content
   Content-Length: 11

   <XML BLOB/>

   (11)  Control Client-->Control Server (Control Framework message):
         200.

   CFW i387yeiqyiq 200
   Seq: 2

   (12)  Control Server-->Control Client (Control Framework message):
         REPORT.

   CFW i387yeiqyiq REPORT
   Seq: 3
   Status: terminate
Top   ToC   RFC6230 - Page 35
   Timeout: 10
   Content-Type: example_content/example_content
   Content-Length: 11

   <XML BLOB/>

   (13)  Control Client-->Control Server (Control Framework message):
         200.

   CFW i387yeiqyiq 200
   Seq: 3

   (14)  Control Client-->Control Server (SIP): BYE

   BYE sip:control-server@pc2.example.com SIP/2.0
   To: <sip:control-server@example.com>;tag=023983774
   From: <sip:client@example.com>;tag=8937498
   Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234
   CSeq: 2 BYE
   Max-Forwards: 70
   Call-ID: 893jhoeihjr8392@example.com
   Contact: <sip:control-client@pc1.example.com>
   Content-Length: 0

   (15)  Control Server-->Control Client (SIP): 200 OK

SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:client@example.com>;tag=8937498
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5
CSeq: 2 BYE
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-server@pc1.example.com>
Content-Length: 0

11. Extensibility

The Media Control Channel Framework was designed to be only minimally extensible. New methods, header fields, and status codes can be defined in Standards-Track RFCs. The Media Control Channel Framework does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and it MUST describe how its use will be signaled.
Top   ToC   RFC6230 - Page 36
   In order to allow extension header fields without breaking
   interoperability, if a Media Control Channel device receives a
   request or response containing a header field that it does not
   understand, it MUST ignore the header field and process the request
   or response as if the header field was not present.  If a Media
   Control Channel device receives a request with an unknown method, it
   MUST return a 500 response.



(page 36 continued on part 3)

Next Section