RFC 6230
Media Control Channel Framework
Media Control Channel Framework 🎀
okay bestie, this is RFC 6230 💖 It's a Standards Track doc from the IETF (ISSN 2070-1721) and it was published in May 2011. The authors are C. Boulton (NS-Technologies), T. Melanchuk (Rainwillow), and S. McGlashan (Hewlett-Packard). The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🧚
Abstract ✨
okay so this doc describes a framework and protocol for apps where the app's logic and the media processing live in different places 🦋 That means the app logic can seamlessly get access to resources that aren't on the same physical network entity. It's giving distributed systems energy 💅 The framework uses SIP (the Session Initiation Protocol) to set up an application-level control mechanism between application servers and outside servers like media servers.
The reason this framework exists is to give a centralized conference system an interface that meets its requirements. The conference system can be distributed, as defined by the XCON working group in the IETF. But it's not limited to that scope, so it can do more 🌈
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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741.
For info on the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6230 🫶
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) as they stand on the publication date of this document. Please read these carefully, because they describe your rights and restrictions for this doc 🙈 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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
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 . . . . . . . . 471. Introduction ✨
okay so real-time media apps are usually built with an architecture where the application logic and the media processing are split up 🦋 Normally the app logic runs on "application servers", while the processing runs on external servers, like "media servers". This doc focuses on the framework and protocol between the application server and that external processing server. The motivation comes from a set of requirements for Media Server Control, which you can find in "Media Server Control Protocol Requirements" [RFC5167]. The Framework isn't specific to media server control, even though that's its main driver and use case. It's meant to work for a bunch of device control scenarios too, like conference control 💜
This document doesn't define a specific SIP extension for directly controlling external components. Instead, other documents, called "Control Packages", extend the Control Framework described here. Section 8 has a full set of guidelines for making those Control Packages 🌸
Current IETF device control protocols, like Megaco [RFC5125], are excellent at controlling media gateways that bridge separate networks 👑 But they're kinda troublesome for media-rich apps in SIP networks, ngl. That's because Megaco duplicates a lot of what SIP already does. So instead of one protocol for session establishment and application media processing, app developers end up translating between two separate mechanisms, which is so much extra work 😭 The model in this framework, which uses SIP, also matches the application programming model way better than Megaco does.
SIP [RFC3261] is the ideal rendezvous mechanism for setting up and maintaining control connections to external server components 🧚 Those control connections can then carry explicit command/response interactions, which let you do media control and get the associated command response results. It's giving clean, iconic architecture 🔥
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. 💅
Okay, so these are the extra terms this doc defines for us to use. Let's get into it 🧚
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 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:
- Service location: Use SIP Proxies and Back-to-Back User Agents for locating Control Servers. 📍
- Security mechanisms: Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication. 🔐
- Connection maintenance: The ability to re-negotiate a connection, ensure it is active, and so forth. 🔄
- 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. This is the part where the architecture really clicks, bestie. ✨
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
Figure 1: Basic ArchitectureThe 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. 🎀
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:H839quwhjdhegvdgaOn 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
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:newa=cfw-id:U8dh7UHDushsdu32uhaThe Control Client gets the SIP 200 OK, pulls out the important bits, and sends a SIP ACK back, obviously 💅. Then it opens an outgoing TCP connection to the Control Server, as set by the SDP setup attribute of active 🦋. The address (from c=) and the port (from m=) tell it which remote endpoint to connect to on the new connection.
Once that connection is up, it can swap requests and responses the way this document describes 🎀. And if you need media after the Control Channel is set up, you can use standard SIP Third Party Call Control (3PCC) [RFC3725] ✨.
Figure 2 is a simplified example of the framework controlling 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
Okay so link (1) is the SIP INVITE dialog usage and the dedicated Control Channel we just went over in the overview 🧚. Link (2) from Figure 2 is the User Agent's SIP INVITE dialog usage plus the media flow that goes with it 💜. A User Agent sets up a SIP INVITE dialog usage with the Control Client. Then the Control Client sets up its own SIP INVITE dialog usage to the Control Server, using B2BUA type functionality 🍓. With the interaction shown at (2), the Control Client negotiates media capabilities with the Control Server on behalf of the User Agent, using SIP 3PCC [RFC3725]. It's giving teamwork 🫶.
4. Control Channel Setup ✨
This section is all about setting up the dedicated Control Channel using SIP. Once that's been established, commands can be exchanged (as discussed in Section 6) 💖.
4.1. Control Client SIP UAC Behavior 💅
When a UAC wants to set up a Control Channel, it MUST construct and send a brand new SIP INVITE request for the Control Channel setup 🌈. The UAC MUST construct the INVITE request as defined in [RFC3261] 🎀.
If a reliable response comes back (as defined in [RFC3261] and [RFC3262]), the mechanisms in this document apply 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]. It MAY choose an offer-less INVITE as per [RFC3261], though 🙈. The SDP SHOULD be formatted following the steps below and use the MIME type application/cfw, which is registered in Section 13 🌸. The information below describes how to build the specific parts of the SDP payload that the offerer MUST follow when using SIP-based offer/answer with SDP and the application/cfw MIME type 💜. The SDP being built MUST contain only a single occurrence of a Control Channel definition from this specification, but it can have other media lines if needed 🦋.
The Connection Data line in the SDP payload gets built 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>. It gives a representation of the SDP originator's address, like a DNS or IP representation. This is the address used for connections 🧚.
Example:
c=IN IP4 controller.example.comThe SDP MUST contain a matching 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 where the client building the SDP can receive an incoming connection if needed 🔥. That port works together with the address in the Connection Data line to give the connection details 💖. If the entity building the SDP can't receive incoming connections, it must still put in a valid port entry 🙈. Using the port value '0' has the same meaning it does in a SIP offer/answer exchange [RFC3264] ✨. The Control Framework has a default port defined in Section 13.5. That value is the default, but a client is free to pick explicit port numbers. Even so, SDP SHOULD use the default port number, unless local policy prohibits it 🌈. Using the default port lets network admins manage firewall policy for Control Framework interactions 🛡️.
The third sub-field, <proto>, has to comply with this specification, and 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 sees a transport value but isn't willing to set up 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. These attributes handle connection negotiation and maintenance parameters 🦋. It is RECOMMENDED that a Controlling UAC initiate a connection to an external Server, but an external Server MAY negotiate and initiate a connection using COMEDIA if network topology stops connections from starting in a certain direction 🧚. An example of the COMEDIA attributes looks like this:
a=setup:active
a=connection:newThis example shows a new connection that will be initiated by the owner of the SDP payload 💜. The connection details are in the SDP answer that comes back from the UAS 🍓. A full example of an SDP payload that follows this specification is in Section 3 ✨. Once the SDP is built along with the rest of the SIP INVITE request (as defined in [RFC3261]), it can be sent to the right location 🌈. Then the SIP INVITE dialog usage and the matching control connection are set up 🫶.
A SIP UAC building an offer MUST include the 'cfw-id' SDP attribute, as defined in Section 9.2 💖. The 'cfw-id' attribute is an identifier used inside the Control Channel to match the Control Channel with this SIP INVITE dialog usage 🔑. The 'cfw-id' attribute MUST be unique within the interaction between the UAC and UAS, and it MUST NOT clash with 'cfw-id' values used in other SIP offer/answer exchanges 🙅♀️. The value picked for the 'cfw-id' attribute MUST be used for the entire life of the associated SIP INVITE dialog usage, and it must not be changed during offer/answer updates. This applies especially to the 'connection' attribute defined in [RFC4145] 🎀. If a SIP UAC wants to change other parts of the SDP but reuse the connection it already has, it uses the value 'existing' in the 'connection' attribute, for example:
a=connection:existingIf it has noticed that a connection failed and wants to set it up again, it uses the value 'new' in the 'connection' attribute, for example:
a=connection:newThrough all of this, the connection identifier in the 'cfw-id' SDP parameter MUST NOT change 💅. You're just negotiating the underlying TCP connection between the endpoints, while 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) to the INVITE request means no SIP INVITE dialog usage was created, and it gets handled as SIP [RFC3261] specifies 🍓. Support for this specification is negotiated through whether the media type from this specification shows up 🧚. A SIP error response like "488" means the offer in the request isn't acceptable 💀. If the media line for this specification is in a rejected offer, that tells the client that made the offer that the problem might be that the receiving client doesn't support this specification 🙈. The client that made the offer MUST act as it normally would when it gets this response, 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 ready to receive an answer where the "m=" line it inserted for the Control Framework has been set to "0" 👑.
In this situation, the client acts the same way it would for any other media type with a port set to "0" 💜.
4.2. Control Server SIP UAS Behavior ✨
okay so when a SIP UAS gets an INVITE, it's basically a detective 🕵️♀️ and it checks the message for signs that the sender supports these mechanisms. It does this by looking at the session description in the offer and seeing if application/cfw shows up as a MIME type in the SDP. If the UAS wants to send back a reliable response that says "yes, I support this extension," it MUST follow the mechanisms in [RFC3261]. If that support gets shared in a reliable SIP provisional response, the mechanisms in [RFC3262] MUST also be used. Also, the SDP offer isn't stuck in the first INVITE. It MAY show up in any series of messages that follow [RFC3261], [RFC3262], [RFC3311], and [RFC3264]. Bestie, that's giving flexibility 💖
When the UAS builds an answer, the SDP payload MUST be made using the connection, media, and attribute semantics from Section 4.1, using valid local settings, and it MUST fully comply with the COMEDIA [RFC4145] spec too. 🎀 For example, the SDP attributes in an answer to the offer from Section 4.1 would look like this:
a=setup:passive
a=connection:newA client building an answer MUST include the cfw-id SDP attribute, as defined in Section 9.2. ✨ This value MUST be unique within the interaction between the UAC and UAS, and it MUST NOT clash with any cfw-id used in other SIP offer/answer exchanges. The cfw-id MUST be different from the cfw-id value that came in the offer, because it's how endpoints that generate SDP answers get told apart from each other. 🦋 Once you pick that value, it MUST stay the same for the entire life of the associated SIP INVITE dialog usage, and you can't change it during offer/answer updates. Not me changing my ID mid-friendship 💅
After the SDP answer is built, it gets sent with standard SIP mechanisms. Depending on what the SDP payloads say after the offer/answer exchange, a reliable connection gets set up between the Controlling UAC and the External Server UAS. 🌸 That new connection is now ready to swap Control Command primitives. The state of the SIP INVITE dialog usage and the Control Channel are now implicitly linked, so they're basically besties 🫶 If either party wants to end a Control Channel, they just send a SIP termination request, like a SIP BYE request or an appropriate response in an early SIP INVITE dialog usage. So the Control Channel lives for exactly as long as the SIP INVITE dialog usage does. Iconic 😭
A UAS that gets a SIP OPTIONS request MUST respond appropriately, as defined in [RFC3261]. The UAS MUST also include the supported media types in a SIP 'Accept' header in the SIP 200 OK response, so everyone knows which media types are valid. 🌈
5. Establishing Media Streams - Control Client SIP UAC Behavior ✨
so the Control Framework is meant to be used in all kinds of architectures for all kinds of jobs 💅 One of the big ones is using the Control Channel to run multiple specific Control Package commands on media sessions that were set up by SIP INVITE dialogs (media dialogs) with a remote server. 🎧 For example, the Control Server might tell a media server to play audio, like an announcement, on an RTP stream between a User Agent and that media server.
SIP INVITE dialogs that set up media sessions (see Figure 2) for User Agents MAY have more than one Media Description (defined by "m=" in the SDP). 🦋 The Control Client MUST include a media label attribute, as defined in [RFC4574], for each "m=" definition it gets that's meant for an entity using the Control Framework. That way, the Control Client can later point commands on the Control Channel at one specific media line (m=). Main character energy 👑
This framework says that referencing these associated media dialogs is extremely important. ✨ There's a connection reference attribute that can optionally be brought into any Control Package, so you don't have to keep repeating dialog reference language over and over. 💖 The schema lives in Appendix A.1.
Same vibe for applying commands to a group of associated media dialogs (multiparty). That's also identified as a common structure that can be defined and reused, like playing a prompt to all participants in a Conference. 🎀 The schema for those operations is also in Appendix A.1.
Support for both of these common attributes is specified as part of each Control Package definition, as detailed in Section 8. 🌸
6. Control Framework Interactions 🧚
okay this part is about how the Control Channel gets set up in either direction because of a SIP INVITE transaction. 🦋 The COMEDIA spec is what makes that possible. SIP has a flexible negotiation mechanism for setting up the Control Channel, but the Control Channel also needs a way to correlate itself with the SIP INVITE dialog usage that set it up. Here's the tricky part: a Control Client that gets an incoming connection (whether it's acting as a UAC or a UAS) has no way to tell which SIP INVITE dialog usage it belongs to, since it could just be listening for every incoming connection on one specific port. 😭 So the steps below, which implementations MUST support, let a connecting UA (the UA with the active role in COMEDIA) figure out which SIP INVITE dialog usage triggered the connection. Unless there's some other dialog association mechanism in use, the UAs MUST do these steps before any other signaling on the newly created Control Channel. Bestie, order matters 🙈
- Once the connection is established, the UA in the active role (active UA) that started the connection MUST send a Control Framework SYNC request. The SYNC request MUST be built as defined in Section 9.1 and MUST contain the
Dialog-IDmessage header. 💅 - The
Dialog-IDmessage header is filled in with the value of the localcfw-idmedia-level attribute that the same client put in the SDP offer/answer exchange to set up the Control Channel. 🎀 This is what links the Control Channel to its SIP INVITE dialog usage. Iykyk 🔗 - When the active UA is creating the SYNC request, it MUST follow the procedures in Section 6.3.3. This section has the details on connection keep-alive messages. ✨
- When creating the SYNC request, the active UA MUST also follow the procedures in Section 6.3.4.2. This one explains how the Protocol Data Units (PDUs) that can be exchanged on the established Control Channel connection get negotiated. 🌈
- The UA in the active role for creating the connection MUST then send the SYNC request. If that UA is a SIP UAS and it built its SDP response in a 2xx-class SIP response, it MUST wait for an incoming SIP ACK message before sending the SYNC. If that UA is a SIP UAS and it built its SDP response in a reliable 1XX class SIP response, it MUST wait for an incoming SIP PRACK message before sending the SYNC. 🫶
If the UA in the active role for creating the connection is a SIP UAC, it MUST send the SYNC message right away once the Control Channel is established. Then it MUST wait for at least 2*'Transaction-Timeout' to get a response. It MAY wait longer, but it MUST NOT wait less than 'Transaction-Timeout'. In general, a Control Framework transaction MUST complete within 20 (2*'Transaction-Timeout') seconds, and this is referred to throughout the document as 'Transaction-Timeout'. ⏰
- If no response comes back for the SYNC message, a timeout happens and the Control Channel is terminated along with the associated SIP INVITE dialog usage. The active UA MUST send a BYE request to terminate the SIP INVITE dialog usage. 💀
- If the active UA gets a 481 response from the passive UA, that means the SYNC request was received, but the SIP INVITE dialog usage named in the SYNC message doesn't exist. The active client MUST terminate the Control Channel, and the active UA MUST send a SIP BYE request to terminate the SIP INVITE dialog usage. 🙈
- Every other error response to the SYNC request gets handled the way this specification describes, and each one also ends the Control Channel and the associated SIP INVITE dialog usage. The active UA MUST send a BYE request to terminate the SIP INVITE dialog usage. 🍓
- Getting a 200 response to a SYNC message means the SIP INVITE dialog usage and the control connection have been successfully correlated. 🎉 The Control Channel can now be used for further interactions. Slay 👑
SYNC messages can be sent at any point while the Control Channel is open from either side, once the initial exchange is done. If the Keep-Alive and Dialog-ID headers are present, their contents MUST NOT change. New values for the Keep-Alive and Dialog-ID headers don't matter, since they're negotiated for the lifetime of the Media Control Channel Framework session. 💜
Once a Control Channel has been successfully set up, as defined in Sections 4.1 and 4.2, and the connection has been correlated, as described in the paragraphs above, both entities are ready to swap Control Framework messages. 🦋 The following subsections spell out the general behavior for building Control Framework requests and responses. Section 6.3 covers the core Control Framework methods and how their transactions get processed. ✨
6.1. General Behavior for Constructing Requests ✨
okay bestie, so an entity acting as a Control Client that builds and sends requests on a Control Channel MUST adhere to the syntax defined in Section 9 🎀 Either entity can be the Control Client depending on the package requirements, so don't lock yourself into one role. 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 to insert in the request. 💖
The transaction identifier then goes in the first line of a Control Framework message, next to the method type, as defined in the ABNF in Section 9. That first line starts with the "CFW" token, which is how you easily pull out the transaction identifier 🦋 The transaction identifier MUST be unique in the context of the interaction between the Control Client and Control Server. This uniqueness is what stops clashes when multiple client entities are creating transactions to run on a single receiving server. Literally so important 😭
All required, mandatory, and optional Control Framework headers then get inserted into the request with appropriate values (check the individual header info for the explicit details 💅). A Control-Package header MUST also be inserted, with the value naming the Control Package this specific request applies to. Multiple packages can be negotiated per Control Channel using the SYNC message discussed in Section 6.3.4.2 🌈
Any Framework message with an associated payload MUST also include the Content-Type and Content-Length message headers. Content-Type tells you the MIME type of the payload, as specified by the individual Control Framework packages, and Content-Length is the size of the message body as a whole decimal number of octets 🍓 If there's no payload attached to the message, the Content-Length header MUST have a value of '0'. Simple but iconic ✨
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 up 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 defined in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' message headers, and a Client that receives them in a response MUST ignore them. Not me being the one who puts them there 🙈
A Control Server MUST include a status code in the first line of the response. If there's 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 gets a 2xx-class response, the Control Command transaction is complete 🎉
If the Control Server gets a request, like CONTROL, that it understands, but 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. After that 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 runs into 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. Generating a non-2xx-class response code to a Control Framework request (like CONTROL or REPORT) indicates that the transaction failed, and all associated transaction state and resources MUST be terminated. 💀 The response code may explicitly say why the transaction failed, which might lead to 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. Non-negotiable, bestie 🔥
The following sub-sections specify each Control Framework method and its associated transaction processing.
6.3.1. CONTROL Transactions 🎀
A CONTROL message is how the Control Client passes control-related information to a Control Server. It's also the event-reporting mechanism in the Control Framework. Reporting events is just another use of the CONTROL message, which can be sent in either direction between two participants in a session, carrying the right payload for an event 🦋 The message is built the same way as any standard Control Framework 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) in the message payload of a CONTROL message are specified in separate Control Package specifications. Those separate 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 doesn't contain a payload. This could actually 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 goes 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 is what links extended transactions back to 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 processing the command finishes within that time, a 200 response code MUST be sent. If the command doesn't finish 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 moment to decide on issuing a 202 response code, and should ensure it has plenty of time for the response to reach the Control Client. If it doesn't have time, transactions will be terminated (timed out) at the Control Client before completion. Yikes 😭
A Control Server issuing a 202 response MUST ensure the message contains a 'Timeout' message header. This header MUST have a value in seconds, which is how long the recipient of the 202 message MUST wait before assuming there's 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 contains a value in seconds, which is how long the recipient of the REPORT message MUST wait before assuming there's 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 is close to expiring and no intended REPORT messages have been generated, the entity acting as a Control Framework UAS for the interaction MUST generate a REPORT message, as defined in this paragraph, with a 'Status' header of 'update' and no associated payload. That message acts as a timeout refresh and in no way affects 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 'Timeout' message header. It is also RECOMMENDED that a Control Server refresh the timeout period of the CONTROL transaction at an interval that isn't 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 about the extended CONTROL transaction MUST also include and increment the 'Seq' header value by 1. A REPORT message received that hasn't 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 to update the extended transaction also acts as a timeout refresh, as described earlier in this section. That resets the transaction timeout period at the initiator of the original CONTROL request to the interval in the 'Timeout' message header 🦋
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 '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 'Timeout' header is there for consistency, and its value is ignored. Once that's sent, a Control Framework UAC can clean up any pending state associated with the original CONTROL transaction 🎀✨
6.3.3. K-ALIVE Transactions 💖
Okay so this protocol can show up in SO many different network setups 🌈 The clients could all be chilling together in one secured, private domain, or they could be spread across totally different domains with things like Network Address Translators (NATs) and firewalls in the way 🧱 A keep-alive mechanism keeps the Control Channel awake during quiet times 😴 because lots of firewalls close connections after a timeout period ⏰ It also gives you application-level failure detection, which is literally so useful 🔥 Also, these procedures only apply to the Control Channel being created 💅 For the SIP keep-alive stuff, go check 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.
😭 Heads up: skipping the keep-alive mechanism defined in this section, even 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 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 let clients and servers learn which Control Packages each one 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 is how the timeout period for the Control Channel keep-alive mechanism gets negotiated. The following rules MUST be followed for the initial SYNC request:
- If the Client initiating the SDP offer has a COMEDIA
setupattribute equal toactive, theKeep-Aliveheader MUST be included in the SYNC message generated by the offerer. The value of theKeep-Aliveheader SHOULD be in the range of 95 to 120 seconds (this is consistent with SIP Outbound [RFC5626]). The value of theKeep-Aliveheader MUST NOT exceed 600 seconds. The client that generated the SDP "Answer" (the passive client) MUST copy theKeep-Aliveheader into the200response to the SYNC message with the same value. - If the Client initiating the SDP offer has a COMEDIA
setupattribute equal topassive, theKeep-Aliveheader parameter MUST be included in the SYNC message generated by the answerer. The value of theKeep-Aliveheader SHOULD be in the range of 95 to 120 seconds. The client that generated the SDP offer (the passive client) MUST copy theKeep-Aliveheader into the200response to the SYNC message with the same value. - If the Client initiating the SDP offer has a COMEDIA
setupattribute equal toactpass, theKeep-Aliveheader 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 ofactivein the COMEDIA SDPsetupattribute, it will generate the SYNC request and include theKeep-Aliveheader. The value SHOULD be in the range 95 to 120 seconds. If the client generating the subsequent SDP answer places a value ofpassivein the COMEDIAsetupattribute, the original UA making the SDP will generate the SYNC request and include theKeep-Aliveheader. The value SHOULD be in the range 95 to 120 seconds. - If the initial negotiated offer/answer results in a COMEDIA
setupattribute equal toholdconn, 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 make sure 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 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 gives a hint to the client that generated the SYNC request about additional packages the server supports 👀
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. That 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. 📝
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.
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 ✨
okay so Control Packages are the add-ons that extend what this document lets you do 💅 bestie, they have to play nice, so they MUST NOT weaken any "MUST" or "SHOULD" statements already in this document 🫶 the one exception is that a Control Package MAY strengthen "SHOULD", "RECOMMENDED", and "MAY" to "MUST", but only if the specific way it's used in the framework justifies it 🔥
authors of Control Packages also need to cover the issues in the sub-sections below, on top of the usual stuff you'd put in a Standards-Track RFC or SIP extension doc 📝 these sections are a template, and they MUST be used and included wherever they fit in every Control Package spec 🎀 to be clear, they're just the bare minimum for the essential package-level info, not the whole story, so a spec can be laid out however it wants as long as it has at least what's listed here ✨
8.1. Control Package Name
this section MUST be in every extension to this document 💖 it gives the Control Package its token name, and it MUST include whatever shows up in the IANA registration of that token 📋 if you want the rules for registering those tokens, check out Section 13 🌸
8.2. Framework Message Usage
the Control Framework comes with a bunch of message primitives you can use to send commands and info around 💬 there are no limits on which way messages can flow down a Control Channel, so the direction is totally open 🦋 this section of a Control Package document MUST spell out exactly which Framework messages (Methods) can be used, and it MUST also show which way each one goes between the entities 🧚 that includes which role type is allowed to start a given request type 👑
8.3. Common XML Support
this section is optional, and it only shows up in a Control Package if it needs the attributes for media dialog or conference reference, as defined and discussed in Appendix A.1 💅 if the package wants to support the XML schema from Appendix A.1, it has to make strong statements about that, using language from RFC 2119 [RFC2119] 🫶 and if it only needs part of the schema (like just 'connectionid' or 'conferenceid'), it still has to make equally strong statements, again using RFC 2119 [RFC2119] language ✨
8.4. CONTROL Message Bodies
this one's mandatory 🔥 it covers the control body that can ride along inside a CONTROL command request (the one from Section 6), or it says that no Control Package body is needed at all 💜 this section MUST point to where the detailed syntax and semantics live for the right MIME [RFC2045] body type that applies to a CONTROL command request and, optionally, the matching 200 response 🎀 if the Control Package doesn't have a body, just saying so satisfies the "MUST" strength of this section 🌈
8.5. REPORT Message Bodies
also mandatory 💅 this covers the REPORT body that can be inside a REPORT command request (from Section 6), or it says that no report package body is needed 🌸 this section MUST point to where the detailed syntax and semantics for the right MIME [RFC2045] body type live 🦋 fun fact, the Control Framework spec lets payloads show up in 200 responses to CONTROL messages too (as defined in this document) 👑 it should be noted that an entity ready to receive a payload type in a REPORT message MUST also be ready to receive that same payload in a 200 response to a CONTROL message 🫶 and if there's no Control Package body, saying so satisfies the "MUST" strength of this section 💖
8.6. Audit
auditing stuff like capabilities and resources (the package-level meta-info) is super useful 🔍 this data usually doesn't change how Control Framework interactions work, but it lets you learn useful context 🧚 Control Packages are encouraged to use Control Framework interactions to share relevant package audit info ✨
this section SHOULD include the following info:
- If an auditing capability is available in this package.
- How auditing information is triggered (for example, using a Control Framework CONTROL message) and delivered (for example, in a Control Framework 200 response).
- 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 show a range of message flows for the common stuff people will do with the package and this framework document 🎀 main character examples only, bestie 🌈
9. Formal Syntax
9.1. Control Framework Formal Syntax
the Control Framework interactions use the UTF-8 transformation format from [RFC3629] 🌸 the syntax in this section is written in Augmented Backus-Naur Form (ABNF) from [RFC5234], including the types 'DIGIT', 'CRLF', and 'ALPHA' 💜 unless a specific header field says otherwise, 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
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)
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 3629here's the summary table of the headers you can find in Control Framework interactions 📊 peep the notation key right under it 👀
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 Interactionsthe notation for Table 1 goes like this 🎀
- 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).
9.2. Control Framework Dialog Identifier SDP Attribute
this spec defines a brand new media-level value attribute called 'cfw-id' 🦋 its formatting in SDP is described by the ABNF below [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-7Ethe token-char and token elements are defined in [RFC4566], but they're repeated here so implementers have what they need for this SDP feature 🫶✨
10. Examples ✨
okay so this section is literally a little movie 🎬 of how a Control Channel gets set up and how the Control Framework messages flow. the SIP signaling is marked with the token 'SIP' so you can spot it, and everything else is a Control Framework interaction defined in this document 💅
the vibe: the Control Client sets up a Control Channel, does a SYNC with the Control Server, and sends a CONTROL request that can't finish inside the 'Transaction-Timeout' 😭. so the Control Server replies with a 202 response code to extend the transaction, then keeps sending REPORTs until the job is done. once that's wrapped up, the SIP INVITE dialog gets terminated 🦋
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(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. Now that connection can be used to swap 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 is complete, 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
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
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: 011. Extensibility 🔧
okay so the Media Control Channel Framework was built to be only minimally extensible, not gonna lie 😅 new methods, header fields, and status codes can be defined in Standards-Track RFCs. but here's the tea: the framework doesn't have a version number or any negotiation mechanism to require or discover new features. 💀 if an extension shows up later that needs negotiation, its spec will have to explain how that negotiation happens in the encapsulating signaling protocol. and if a non-interoperable update or extension ever lands, it gets treated as a brand new protocol, and it MUST describe how its use will be signaled 🌸
in order to let extension header fields exist without breaking interoperability, there's a rule: if a Media Control Channel device gets a request or response with a header field it doesn't understand, it MUST ignore that header field and process the request or response as if the header field wasn't there at all 🫶 and if a Media Control Channel device gets a request with an unknown method, it MUST return a 500 response. no vibes, just rules 💅
12. Security Considerations 🔐
this section is SERIOUS, bestie 😭 the Channel Framework provides confidentiality and integrity for the messages it transfers. it also gives you assurances that the connected host is the host you meant to connect to, and that the connection hasn't been hijacked, as the rest of this section explains.
in design, the Channel Framework complies with the security-related requirements documented in "Media Server Control Protocol Requirements" [RFC5167], specifically REQ-MCP-11, REQ-MCP-12, REQ-MCP-13, and REQ-MCP-14. the specific security measures the Channel Framework uses are summarized in the sub-sections below 🧚
12.1. Session Establishment
okay so Channel Framework sessions are set up as media sessions described by SDP inside a SIP INVITE dialog. to make sure the rendezvous between Control Framework clients and servers is secure, the Media Channel Control Framework should make full use of the mechanisms SIP provides. the 'cfw-id' SDP attribute carries important session information across the SIP network, which is why this matters so much 👀 for this reason, SIP clients using this specification MUST use appropriate security mechanisms, such as TLS [RFC5246] and SMIME [RFC5751], when deployed in open networks. no exceptions in the wild, periodt 💖
12.2. Transport-Level Protection
real talk: when only TCP connections are used, the Channel Framework security is weak 😩 even though the Channel Framework needs to be able to protect this exchange, nothing guarantees that the protection will actually get used every time. and if protection isn't used, anyone can see the data exchanges. 🙈
sensitive stuff like private and financial data gets carried over the Control Framework channel. clients and servers must be properly authenticated/authorized, and the Control Channel must permit confidentiality, replay protection, and integrity protection for the data. to keep the Control Channel protected, Control Framework clients and servers MUST support TLS and SHOULD use it by default, unless alternative Control Channel protection is in use or the administrator of the network guarantees a protected environment. alternative Control Channel protection MAY be used if you want it (e.g., IPsec [RFC5246]) 🔒
TLS authenticates devices and provides integrity, replay protection, and confidentiality for the header fields carried on the Control Channel. Channel Framework elements MUST implement TLS, and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [RFC5246]. the TLS cipher-suite TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261] MUST be supported. other cipher-suites MAY also be supported 🧁
when a TLS client connects to a server, it gets handed the server's X.509 certificate. authentication goes as described in Section 7.3 ("Client Behavior") of RFC 5922 [RFC5922] ✨
a TLS server that conforms to this specification MUST ask for a client certificate. if the client has one, it gets presented to the server for mutual authentication, and authentication goes as described in Section 7.4 ("Server Behavior") of RFC 5922 [RFC5922] 🥹
12.3. Control Channel Policy Management 🔐
okay bestie, so this spec lets you set up a dedicated Control Channel using SIP 📞✨, and it's also allowed to make multiple channels for failover and redundancy 🦋 (backup queens, we love to see it). BUT, the tea is that if lots of entities can make connections and get access to resources, that can cause conflicts in shared environments 😬. This document does not carry any specific mechanism to overcome those conflicts, but it will give you a summary of how to handle them 💅.
Okay, so access to resources and the use of Control Channels are totally tied to policy 📜. Deciding how strict that policy is counts as an implementation and deployment detail 🛠️. The authorization and policy for a Control Channel can be linked to the authentication mechanisms described in this section 🔑. For example, strictly authenticating a Control Channel using TLS authentication lets entities protect resources and keep the level of granularity they need 💜. Policy can be applied at the package level, or even as low as a structure like a conference instance (Control Channel X is not permitted to issue commands for Control Package y OR Control Channel A is not permitted to issue commands for conference instance B) 🎀. Systems should ensure that, if required, an appropriate policy framework is adopted to satisfy the requirements for implemented packages 👑.
The most robust form of policy comes from a strong authentication mechanism, such as mutual TLS authentication on the Control Channel 🔥. This specification provides a Control Channel response code (403) to tell the issuer of a command that it is not permitted 🙅♀️. The 403 response MUST be issued to Control Framework requests that are not permitted under the implemented policy. If a 403 response is received, a Control Framework client MAY choose to re-submit the request with differing requirements or to abandon the request 🌸.
Real talk: the 403 response does not provide any additional information on the policy failure, because this specification is pretty generic 🙈. Individual Control Packages can supply additional information if required 🧚. The mechanism for providing that extra information is not mandated in this specification. It should be noted that additional policy requirements beyond those covered in this section might be defined and applied in individual packages that specify a finer granularity for access to resources, etc. ✨
13. IANA Considerations 📋
IANA has created a new registry for SIP Control Framework parameters 🌈. The "Media Control Channel Framework Parameters" registry is a container for sub-registries. This section further introduces sub-registries for control packages, method names, status codes, header field names, and port and transport protocol 💖.
Additionally, Section 13.6 registers a new MIME type for use with SDP 🧁.
For all registries and sub-registries created by this document, the policy applied when creating a new registration is also applied when changing an existing registration 🔒.
13.1. Control Packages Registration Information
Okay, so this spec sets up the Control Packages sub-registry under Media Control Channel Framework Packages 📦. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream), using the IANA policy [RFC5226] "RFC Required" 🎀.
Since this document doesn't specify any package or template-package names, the initial IANA registration for Control Packages will be empty 🫧. The rest of this section gives an example of the type of information IANA will maintain 💅.
The table below lists the Control Packages defined in the "Media Control Channel Framework" 🦋.
Package Name Reference
------------ ---------
example1 [RFCXXXX]13.1.1. Control Package Registration Template
Here's the template, bestie 📝.
Package Name:
(Package names must conform to the syntax described in
Section 8.1.)
Published Specification(s):
(Control Packages require an RFC.)
Person & email address to contact for further information:13.2. Control Framework Method Names
This specification sets up the Method Names sub-registry under Media Control Channel Framework Parameters and starts it off as follows 🚀. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream).
CONTROL - [RFC6230]
REPORT - [RFC6230]
SYNC - [RFC6230]
K-ALIVE - [RFC6230]The following information MUST be provided in an RFC in order to register a new Control Framework method 📜✨:
- The method name.
- The RFC number in which the method is registered.
13.3. Control Framework Status Codes
This specification sets up the Status Code sub-registry under Media Control Channel Framework Parameters 🚦. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined in Section 9. It takes the following format:
Code Description ReferenceThe following information MUST be provided in an RFC in order to register a new Control Framework status code 💜:
- The status code number.
- The RFC number in which the method is registered.
- A brief description of the status code.
13.4. Control Framework Header Fields
This specification sets up the Header Field sub-registry under Media Control Channel Framework Parameters 🎀. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream). Its initial population is defined as follows:
Control-Package - [RFC6230]
Status - [RFC6230]
Seq - [RFC6230]
Timeout - [RFC6230]
Dialog-ID - [RFC6230]
Packages - [RFC6230]
Supported - [RFC6230]
Keep-Alive - [RFC6230]
Content-Type - [RFC6230]
Content-Length - [RFC6230]The following information MUST be provided in an RFC in order to register a new Channel Framework header field 🫶:
- The header field name.
- The RFC number in which the method is registered.
13.5. Control Framework Port
The Control Framework uses TCP port 7563, from the "registered" port range 🔌. Usage of this value is described in Section 4.1.
13.6. Media Type Registrations
This section describes the media types and names associated with payload formats used by the Control Framework 🌸. The registration uses the templates defined in [RFC4288]. It follows [RFC4855].
13.6.1. Registration of MIME Media Type application/cfw
Here's the first MIME type, the application/cfw one 💖.
Type name: application
Subtype name: cfw
Required parameters: None
Optional parameters: None
Encoding considerations: Binary and see Section 4 of RFC 6230
Security considerations: See Section 12 of RFC 6230
Interoperability considerations:
Endpoints compliant to this specification must
use this MIME type. Receivers who cannot support
this specification will reject using appropriate
protocol mechanism.
Published specification: RFC 6230
Applications that use this media type:
Applications compliant with Media Control Channels.
Additional Information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Intended usage: COMMON
Restrictions on usage:
Should be used only in conjunction with this specification,
RFC 6230.
Author: Chris Boulton
Change controller:
IETF MEDIACTRL working group, delegated from the IESG.13.6.2. Registration of MIME Media Type application/framework-attributes+xml
And the second one, for the framework attributes 🧚.
Type name: application
Subtype name: framework-attributes+xml
Required parameters: (none)
Optional parameters: Same as charset parameter of application/xml as
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
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 6230
Applications that use this media type: Implementations of
appropriate Media Control Channel packages.
Additional information:
Magic number(s): (none)
File extension(s): (none)
Macintosh file type code(s): (none)
Person & email address to contact for further information:
Chris Boulton <chris@ns-technologies.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: None.13.7. 'cfw-id' SDP Attribute
Here's the cfw-id SDP attribute, which is the one that links things up 🔗💜.
Contact name: Chris Boulton <chris@ns-technologies.com>
Attribute name: "cfw-id".
Type of attribute Media level.
Subject to charset: Not.
Purpose of attribute: The 'cfw-id' attribute indicates an
identifier that can be used to correlate the Control Channel with
the SIP INVITE dialog used to negotiate it, when the attribute
value is used within the Control Channel.
Allowed attribute values: A token.13.8. URN Sub-Namespace for urn:ietf:params:xml:ns:control:framework-attributes
IANA has registered 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 <chris@ns-technologies.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>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt">
RFC 6230</a>.</p>
</body>
</html>
END13.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 <chris@ns-technologies.com>.
Schema: The XML for this schema can be found in Appendix A.1 of this
document.14. Contributors 🫶
Asher Shiratzky from Radvision provided valuable support and contributions to the early versions of this document 💖✨.
15. Acknowledgments 🫶
bestie, the authors gave SO many shoutouts here 💖 Thank you to Ian Evans of Avaya, Michael Bardzinski and John Dally of NS-Technologies, Adnan Saleem of Radisys, and Dave Morgan for the useful review and input on this work. Eric Burger helped out in the early phases too 🌸
Expert review came from Spencer Dawkins, Krishna Prasad Kalluri, Lorenzo Miniero, and Roni Even ✨ Hadriel Kaplan gave expert guidance on the dialog association mechanism, and Lorenzo Miniero has constantly given excellent feedback based on his own work 🔥
Ben Campbell carried out the RAI expert review on this document and gave a great deal of invaluable input 👑 Brian Weis did a thorough security review 🔐 Jonathan Lennox did a thorough SDP review that suggested some excellent modifications 💅 And the introduction borrowed text from Eric Burger in its explanation of why SIP is used 🦋
16. References 📚
16.1. Normative References
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
- [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
- [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
- [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
- [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
16.2. Informative References
- [MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006.
- [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
- [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
- [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
- [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
- [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
Appendix A. Common Package Components 🧩
while the Control Framework was being built, it became super clear that a bunch of components are shared across multiple packages 🦋 It's so useful to collect those reusable pieces in one central spot! For now, this appendix is just the placeholder for those utilities, and the plan is for this section to eventually become the base of an initial 'Utilities Document' that Control Packages can use 🌈
A.1. Common Dialog/Multiparty Reference Schema
okay so this schema gives Control Packages some common attributes so they can aim specific commands at a particular SIP media dialog (also called a "Connection") or a conference 🎀 If it's used inside a Control Package, the Connection and multiparty attributes get imported and used properly to pin down either a SIP dialog or a conference instance. When it's used inside a package, the value in the 'connectionid' attribute MUST be built by joining the 'Local' and 'Remote' SIP dialog identifier tags, as defined in [RFC3261] 💜 Those MUST then be separated with the ':' character, so the format looks like this:
'Local Dialog tag' + ':' + 'Remote Dialog tag'For example, if an entity has a SIP Local dialog identifier of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 'connectionid' attribute for a Control Framework command would be:
7HDY839:HJKSkyHSIt should be noted that Control Framework requests started alongside a SIP dialog will give a different 'connectionid' value depending on which direction the request goes, since the Local and Remote tags are locally identifiable 🙈
Just like the Connection attribute we defined earlier, it's really handy to apply specific Control Framework commands to a bunch of related dialogs, like in a multiparty call 🍓 That usually means several media dialogs that are logically tied together by one single identifier. The schema below lets Control Framework commands explicitly reference that kind of grouping through a 'conferenceid' XML container. If a Control Package uses it, any control XML referenced by the attribute applies to all the related media dialogs. Unlike the dialog attribute, the 'conferenceid' attribute does NOT need to be built from the overlying SIP dialog. Its value is system specific and should be selected with relevant context and uniqueness ✨
It should be noted that the values in both the 'connectionid' and 'conferenceid' identifiers MUST be compared in a case-sensitive manner ⚠️ Don't skip this one, bestie. Case matters! 💀
The full schema follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>Authors' Addresses 💌
Chris Boulton NS-Technologies
EMail: chris@ns-technologies.com
Tim Melanchuk Rainwillow
EMail: timm@rainwillow.com
Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden
EMail: smcg.stds01@mcglashan.org
And that's the whole doc, bestie! 🌈👑 Iconic work from every single author 🥹
📦 where this page comes from
- ietf: rfc6230 2011-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms