Media Control Channel Framework
Extracted elements (29)
SIP is used for Control Channel establishment to ensure the URI for session establishment resolves to the same node as the node for session control. Using SIP routing and having the server initiate the TCP connection back guarantees this, whereas HTTP URIs may resolve to entirely different hosts than SIP URIs for the same logical server.
The framework was designed using SIP rather than Megaco because Megaco duplicates many SIP functions and forces application developers to translate between two separate mechanisms. The SIP-based model better matches the application programming model for media-rich applications in SIP networks.
Control Packages MUST NOT weaken MUST or SHOULD statements in the base framework document. A Control Package MAY strengthen SHOULD, RECOMMENDED, or MAY to MUST if justified by the specific usage. New methods, header fields, and status codes require Standards-Track RFCs.
A SIP UAC constructing an offer MUST include the 'cfw-id' SDP attribute. This identifier MUST be unique in the context of the UAC/UAS interaction, MUST NOT clash with 'cfw-id' values in other offer/answer exchanges, and MUST NOT change for the entire duration of the associated SIP INVITE dialog usage.
A SYNC request MUST include a 'Packages' header listing all Control Packages the client supports. The server MUST respond with a 200 containing a 'Packages' header with the common subset; if no common packages exist, the server MUST respond with 422 and a 'Supported' header listing its capabilities.
A UA in the active COMEDIA role that is a SIP UAS MUST wait for a SIP ACK (or PRACK for reliable provisional responses) before issuing the SYNC. A UAC MUST send the SYNC immediately upon Control Channel establishment and MUST wait at least 2*Transaction-Timeout (20 seconds) for a response.
A UAC wishing to establish a Control Channel MUST construct and transmit a new SIP INVITE request. The SDP payload MUST contain only a single Control Channel definition using MIME type application/cfw, and the Connection Data 'c=' line MUST use nettype 'IN' and addrtype 'IP4' or 'IP6'.
All REPORT messages for an extended CONTROL transaction MUST carry the same transaction ID as the original CONTROL, MUST include a 'Seq' header incrementing by 1 with each message, and MUST include a 'Timeout' header. A REPORT received with a non-sequential Seq MUST be responded to with 406 and the extended transaction MUST be terminated.
Any Framework message that contains an associated payload MUST include both 'Content-Type' and 'Content-Length' headers. If no payload is present, the 'Content-Length' header MUST have a value of '0'. A Control Client MUST also include a 'Control-Package' header identifying the target package in every CONTROL request.
Both active and passive COMEDIA entities MUST start a keep-alive timer equal to the negotiated 'Keep-Alive' value. The active entity MUST send K-ALIVE before the timer fires (RECOMMENDED at 80% of the timer interval). If the passive entity receives no K-ALIVE before its timer fires, it MUST tear down the SIP INVITE dialog and recover Control Channel resources.
Control Clients MUST create a unique transaction identifier for each request; this identifier MUST be unique in the context of the interaction between the Control Client and Control Server. Control Clients MUST wait a minimum of 2*Transaction-Timeout (20 seconds) for a response before considering the transaction failed.
If a Media Control Channel device receives a request or response containing a header field it does not understand, it MUST ignore the header field and process the message as if it were absent. If a device receives a request with an unknown method, it MUST return a 500 response.
If processing a CONTROL command will exceed the Transaction-Timeout (10 seconds), the server MUST respond with 202 and subsequently send REPORT messages. The 202 response MUST include a 'Timeout' header indicating the number of seconds the client must wait before considering the extended transaction failed.
In the initial SYNC, the active COMEDIA entity MUST include a 'Keep-Alive' header with a value SHOULD be in the range 95–120 seconds and MUST NOT exceed 600 seconds. The passive entity MUST copy the identical value into the 200 response. This negotiated timeout applies for the full Control Framework session and MUST NOT appear in subsequent SYNC messages.
The SDP 'm=' media line MUST use <media> value 'application', and <proto> MUST support both 'TCP' and 'TCP/TLS'. The <fmt> sub-field MUST contain the value 'cfw'. Implementations MUST support TLS as a transport-level security mechanism, though its use in specific deployments is optional.
The terminating REPORT message MUST include a 'Status' header with value 'terminate', MUST increment the 'Seq' by 1 from the previous REPORT, and MUST include a 'Timeout' header (its value is ignored). This signals the Control Client to clean up state for the original CONTROL transaction.
The UAS constructing an answer MUST include a 'cfw-id' SDP attribute that MUST be different from the 'cfw-id' received in the offer, to uniquely distinguish between multiple endpoints that generate SDP answers.
Table 1 defines header field applicability per method: 'Control-Package' is mandatory in CONTROL requests; 'Seq', 'Status', and 'Timeout' are mandatory in REPORT requests; 'Dialog-ID' and 'Packages' are mandatory in SYNC requests. 'Content-Length' and 'Content-Type' are optional in CONTROL and REPORT; 'Supported' and 'Keep-Alive' are optional in SYNC responses/requests respectively.
The framework defines four methods: CONTROL (client-to-server commands and event reporting), REPORT (server status updates for extended transactions), K-ALIVE (keep-alive probes), and SYNC (initial correlation, keep-alive negotiation, and package negotiation). Implementations MUST support sending and receiving all four.
IANA is requested to create a new 'Control Packages' registry. Registrations require a Control Package name token, a reference to the specification, and completion of the registration template defined in Section 13.1.1. New entries require IETF Review.
IANA is requested to create registries for Control Framework Method Names (initial entries: CONTROL, REPORT, SYNC, K-ALIVE), Control Framework Status Codes (initial entries: 200, 202, 400, 403, 405, 406, 420, 421, 422, 423, 481, 500), and Control Framework Header Fields. New entries require Standards-Track RFCs.
IANA is requested to register the 'cfw-id' SDP attribute as a media-level value attribute per RFC 4566, and to register a URN sub-namespace 'urn:ietf:params:xml:ns:control:framework-attributes' for the XML schema defined in Appendix A.1.
IANA is requested to register two MIME media types: 'application/cfw' (for Control Framework SDP negotiation) and 'application/framework-attributes+xml' (for the XML schema in Appendix A). The default port for Control Framework connections is registered as a well-known port in Section 13.5.
A TLS server conformant to this specification MUST request a client certificate to enable mutual authentication, following RFC 5922 Section 7.4. When a TLS client connects, server authentication follows RFC 5922 Section 7.3 using the server's X.509 certificate.
Control Framework clients and servers MUST support TLS and SHOULD use it by default. They MUST implement the TLS ClientExtendedHello server name indication extension. The cipher suite TLS_RSA_WITH_AES_128_CBC_SHA MUST be supported. TLS provides authentication, integrity, replay protection, and confidentiality for Control Channel traffic.
SIP clients using this specification MUST use appropriate security mechanisms such as TLS and S/MIME when deployed in open networks, because the 'cfw-id' SDP attribute carries important session correlation information across the SIP network that is vulnerable to interception or spoofing.
After a Control Channel TCP connection is established, the UA in the active COMEDIA role MUST send a SYNC request containing the 'Dialog-ID' header before any other signaling. States are: (1) connected-uncorrelated → send SYNC with local cfw-id; (2) await 200 response; (3) on 200: correlated/operational; on 481: dialog does not exist, tear down; on timeout: tear down and send SIP BYE.
Control Framework messages use the format: 'CFW <trans-id> <method|status-code> CRLF *headers CRLF [body]'. The 'pCFW' token is the literal ASCII string 'CFW'. The transaction identifier is an alpha-num-token of 4–32 characters. Headers are line-delimited and case-insensitive. The Content-Length header represents body size as a decimal octet count.
The 'cfw-id' SDP attribute is a media-level value attribute with syntax: 'a=cfw-id:' 1*(SP cfw-id-name) CRLF, where cfw-id-name is a token composed of printable ASCII characters excluding whitespace, '(', ')', '<', '>', '@', ',', ';', ':', '\', '"', '/', '[', ']', '?', '=', '{', '}'.