RFC 6917
Media Resource Brokering
Part 1 of 25 🎀
Media Resource Brokering 💖
okay bestie, let's start with the basics 🦋 this is RFC 6917, called "Media Resource Brokering", and it's an IETF Standards Track document, so it's the real deal, not a rough idea 😤 it came out in April 2013 with ISSN 2070-1721 ✨
the authors are C. Boulton (NS-Technologies), L. Miniero (Meetecho), and G. Munson (AT&T) 👑 the header doesn't list anything it obsoletes or updates, so this RFC isn't replacing or patching any older ones 🫶
Abstract 🔥
okay so the MediaCtrl working group in the IETF came up with an architecture for controlling media services 🎬 SIP is the signaling protocol doing the heavy lifting, and it already has a ton of built-in message routing magic 🪄 BUT ngl there's a gap: we also need smart, application-level picking of media services based on signaling properties that aren't static 🤔 it gets extra important when you've got 1:M and M:N combos of Application Servers and Media Servers (it's a whole thing 💀)
so this doc introduces the Media Resource Broker, or MRB 💜 it keeps track of which Media Servers are available and how much media the Application Servers need 🌸 it also covers possible ways to deploy an MRB and the right interfaces to Application Servers and Media Servers 🧚
Status of This Memo 📜
this is an Internet Standards Track document ✅
it's a product of the Internet Engineering Task Force (IETF) and 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 the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6917 🔗
Copyright Notice 💅
Copyright (c) 2013 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 date of publication 📜 please read these carefully, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of 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 ....................................................3
2. Conventions and Terminology .....................................6
3. Problem Discussion ..............................................6
4. Deployment Scenario Options .....................................7
4.1. Query MRB ..................................................8
4.1.1. Hybrid Query MRB ....................................9
4.2. In-Line MRB ...............................................11
5. MRB Interface Definitions ......................................12
5.1. Media Server Resource Publish Interface ...................12
5.1.1. Control Package Definition .........................13
5.1.2. Element Definitions ................................15
5.1.3. <mrbrequest> .......................................15
5.1.4. <mrbresponse> ......................................17
5.1.5. <mrbnotification> ..................................19
5.2. Media Service Resource Consumer Interface .................30
5.2.1. Query Mode/HTTP Consumer Interface Usage ...........31
5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage ....32
5.2.3. Consumer Interface Lease Mechanism .................35
5.2.4. <mrbconsumer> ......................................38
5.2.5. Media Service Resource Request .....................39
5.2.6. Media Service Resource Response ....................51
5.3. In-Line Unaware MRB Interface .............................54
6. MRB Acting as a B2BUA ..........................................54
7. Multimodal MRB Implementations .................................55
8. Relative Merits of Query Mode, IAMM, and IUMM ..................56
9. Examples .......................................................58
9.1. Publish Example ...........................................58
9.2. Consumer Examples .........................................64
9.2.1. Query Example ......................................64
9.2.2. IAMM Examples ......................................68
10. Media Service Resource Publisher Interface XML Schema .........83
11. Media Service Resource Consumer Interface XML Schema .........106
12. Security Considerations ......................................127
13. IANA Considerations ..........................................130
13.1. Media Control Channel Framework Package Registration ....130
13.2. application/mrb-publish+xml Media Type ..................130
13.3. application/mrb-consumer+xml Media Type .................131
13.4. URN Sub-Namespace Registration for mrb-publish ..........132
13.5. URN Sub-Namespace Registration for mrb-consumer .........132
13.6. XML Schema Registration for mrb-publish .................132
13.7. XML Schema Registration for mrb-consumer ................133
14. Acknowledgements .............................................133
15. References ...................................................133
15.1. Normative References ....................................133
15.2. Informative References ..................................1351. Introduction ✨
okay so IP-based multimedia infrastructures are maturing, and that means the deployments are getting way more complicated 😭 Lots of vendors are bringing lots of different capabilities, and they all still need to be interoperable using the architecture and protocols the MediaCtrl working group produces 🫶 A controlling entity should be able to get help picking a Media Server, so the most appropriate resource is chosen for each operation 🎀 This matters even more once you add a flexible range of deployment scenarios, like the ones in RFC 5167 [RFC5167] and RFC 5567 [RFC5567]. Those documents literally say "it should be possible to have a many-to-many relationship between Application Servers and Media Servers that use this protocol" 🙈 So these deployment architectures become possible when you think about media resources, which is basically what people call media resource brokering 🦋
The simplest deployment view is illustrated in Figure 1.
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-------MS Control------>| Server |
+-------------+ +-------------+Figure 1: Basic Architecture
This simply involves a single Application Server and Media Server. Expanding on this view, it is also possible for an Application Server to control multiple (greater than 1) Media Server instances at any one time. This deployment view is illustrated in Figure 2. Typically, these architectures go with application logic that needs high-demand media services 🔥 It is more than possible that each Media Server has a different media capability set 💅 Media Servers may offer different media services as specified in the MediaCtrl architecture document [RFC5567]. A Media Server may have similar media functionality but may have different capacity or media codec support.
+---+-----+---+
| Media |
+----->| Server |
| +-------------+
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+
|
| +---+-----+---+
+----->| Media |
| Server |
+-------------+Figure 2: Multiple Media Servers
Figure 3 is the mirror image of Figure 2 🪞 In this model, there are a number of (greater than 1) Application Servers, possibly running dissimilar applications, all controlling a single Media Server. Typically, these architectures go with application logic that needs low-demand media services 🌸
+---+-----+---+
| Application |
| Server |<-----+
+-------------+ |
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+
|
+---+-----+---+ |
| Application | |
| Server |<-----+
+-------------+Figure 3: Multiple Application Servers
The final deployment view is the most complex one (Figure 4) 🌈 In this model (M:N), there can be any number of Application Servers and any number of Media Servers. It's again possible here that Media Servers aren't homogeneous, so they might have different capability sets and capacities.
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-----+ +---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media |
| Server |<-----+ | Server |
+-------------+ +---+-----+---+Figure 4: Many-to-Many Architecture
The rest of this specification focuses on a new entity called a Media Resource Broker (MRB), which can be used in the deployment architectures we just covered 🧚 The MRB gives you the ability to get media resource information and allocate (broker) resources on behalf of client applications ✨
The high-level deployment options in this section rely on network architecture and policy to stop inappropriate use. Those policies are out of scope for this document.
This document looks at the specific problem areas that come with these deployment architectures 👑 The solutions proposed here should be equally adaptable to all of the deployment models above. The solution is also far more relevant to some of those models, and for others it can almost be seen as redundant 💀
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 RFC 2119 [RFC2119].
This document inherits terminology from RFC 5567 [RFC5567] and from "Media Control Channel Framework" [RFC6230]. On top of that, the following terms are defined for this document and for the MediaCtrl working group in the IETF 🫧
- Media Resource Broker (MRB): A logical entity that is responsible for both collecting appropriate published Media Server (MS) information and selecting appropriate Media Server resources on behalf of consuming entities.
- Query MRB: An instance of an MRB (see the previous definition) that gives an Application Server an interface to retrieve the address of an appropriate Media Server. The result returned to the Application Server can be influenced by information in the query request.
- In-line MRB: An instance of an MRB (see the previous definition) that receives requests directly on the signaling path. There is no separate query.
- CFW: Media Control Channel Framework, as specified in [RFC6230].
Within the context of In-line MRBs, a few more terms are defined 🎀
- In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1.
- In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
This document will often say when a specific identifier in a protocol message needs to be unique. Unless stated otherwise, that uniqueness is always scoped to the Media Servers controlled by the same MRB 🔒 How different MRB instances interact, for example how a logical MRB is partitioned, is out of scope for this document.
3. Problem Discussion 🧩
As we said in Section 1, the MediaCtrl working group wants a solution that can serve a huge variety of deployment architectures 🌍 These run from the simplest 1:1 relationship between Media Servers and Application Servers all the way to potentially linearly scaling 1:M, M:1, and M:N deployments 📈
Managing these deployments is already a lot 😭 It gets even messier once more complexity factors are added to the mix. As Media Servers evolve, we have to remember that when many of them exist in one deployment, they may come from different vendors and may not have the same capability set. An Application Server in the deployment should be able to pick a media service based on a common, appropriate capability set 💖 Available resources matter too. Picking the right media service is super useful on its own, but it gets even more powerful when you also factor in the resources available to handle a request ⚡
So the goal is to build a toolkit that lets MediaCtrl deployments make effective use of the media resources they have 🛠️ In the simplest deployments, where only one Media Server exists, an MRB function is probably not required. There's only one capability set, and resource availability can be handled with the right underlying signaling, such as a SIP response. This document doesn't prohibit using an MRB in those cases. It just provides the tools for different entities to interact where that makes sense 🦋 The functions in this document also aim to give a 'best effort' view of media resources at the time of the request, for initial Media Server routing decisions. Any dramatic change in media capabilities or capacity after a request has happened should be handled by the underlying protocol 😳
There may also be extra information the MRB would find useful for selecting a Media Server resource 📋 Examples include resource allocation rules across different applications, planned or unplanned downtime of Media Server resources, the planned addition of future Media Server resources, or Media Server resource capacity models. How the MRB gets that information is outside the scope of this document. The specific techniques an MRB uses to select an appropriate media resource are also outside the scope of this document 🙅♀️
4. Deployment Scenario Options 🌟
Research into media resource brokering concluded that a couple of high-level models give an appropriate level of flexibility 🥹 The general principles behind the "in-line" and "query" MRB concepts are covered in the rest of this section. While the interfaces are different, both use the common underlying mechanisms defined in this specification 🫶
4.1. Query MRB 💅
okay so the "Query" model for MRB interactions is giving ask me first energy 🦋. A client of media services (like an Application Server) can "ask" an MRB to find an appropriate Media Server, as shown in Figure 5 ✨.
+---+-----+---+
+------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | |
| | | |
|(2) +---+--+--+---+ | |
| | Media | | |
| +---->| Server | | |
| | +-------------+ | |
| | (1)| |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ |
| |
| +---+-----+---+ (1)|
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 5: Query MRBSo in this deployment, the Media Servers use the Media Server Resource Publish interface (see Section 5.1) to share capability sets and resource info 🎀. That's the (1) in Figure 5 💖. After that, the MRB has the job of collecting all the appropriate info about media services in the logical deployment cluster 🧚. The Application Server (or whatever media services client) can then query the MRB for a suitable resource, which is the (2) in Figure 5 🫶. That query carries specific info about the media service it needs, so the MRB can be way more accurate in its answer 😭. This interface is covered in "Media Service Resource Consumer Interface" (Section 5.2) 📚. The Application Server then sends control commands (like creating a conference) and media dialogs straight to the right Media Server, shown by (3) in Figure 5 🌈. Also, with Query mode, the MRB is not directly in the signaling path between the Application Server and the selected Media Server resource 👑.
4.1.1. Hybrid Query MRB 🧚
as i mentioned before, the plan is for a toolkit to be provided for MRB functionality inside a MediaCtrl architecture 🫶. In certain deployment scenarios, the MRB role might be co-hosted as a hybrid logical entity with an Application Server, as in Figure 6 🍓.
+------------<----------------<---------+----<-----+---+
| (1) | | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
V +---->| Server | | |
+------+------+ | +-------------+ | |
| MRB | | | |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ |
| |
| +---+-----+---+ |
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 6: Hybrid Query MRB - Application Server HostedThis diagram is the same as Figure 5, except the MRB now lives on the Application Server 🏠. The Media Server Publish interface is still used to gather resource info at the MRB, but since it's co-hosted on the Application Server, the Media Server Consumer interface has collapsed 💀. It might still exist within the Application Server/MRB interaction, but that's an implementation issue 🙈. This setup suits a single Application Server environment, but a Media Server Consumer interface could then be offered from the hybrid if needed 🌸.
The Media Server can also act as a hybrid for the deployment cluster, as illustrated in Figure 7 💜.
(1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+
| | |
| | +---+--+--+---+ |
| +---<---| Application | |
| | Server |<--+-MS Control-+--+
| +-------------+ |
| |
| +---+--+--+---+ |
+---<-------| Application | |
| Server |<--+-MS Control-+--+
+-------------+
Figure 7: Hybrid Query MRB - MS HostedIn this example, the MRB has collapsed and is co-hosted by the Media Server 🦋. The Media Server Consumer interface is still available to the Application Servers (1) to query Media Server resources 💅. The Media Server Publish interface has collapsed onto the Media Server 😭. It might still exist within the Media Server/MRB interaction, but that's an implementation issue again 🙈. This type of deployment suits a single Media Server environment, but a Media Server Publish interface could then be offered from the hybrid if required ✨. A typical use case for this topology is a single Media Server representing a pool of MSs in a cluster 🎀. In this case, the MRB would actually be handling a cluster of Media Servers, rather than just one 🔥.
4.2. In-Line MRB 🌈
The "In-line" MRB is architecturally different from the "Query" model we just talked about 🦋. The concept of a separate query just disappears 💀. The client of the MRB simply uses the media resource control and media dialog signaling to involve the MRB 🫶. This type of deployment is shown in Figure 8 👀.
+-------<----------+----<-------+---+
| | (1) | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
| +------>| Server | | |
| |(3) +-------------+ | |
| | (1)| |
+---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ |
| |
| (3) +---+-----+---+ (1)|
+------>| Media | |
| Server |--->---+
+---+-----+---+
Figure 8: In-Line MRBThe Media Servers still use the Media Server Publish interface to convey capabilities and resources to the MRB, as illustrated by (1) 💖. The Media Server Control Channels (and media dialogs as well, if required) are sent to the MRB (2), which then selects an appropriate Media Server (3) and remains in the signaling path between the Application Server and the Media Server resources 👑.
The In-line MRB can be split into two distinct logical roles, and each can be applied on a per-request basis 🧚. They are:
- In-line Unaware MRB Mode (IUMM): Lets an MRB act on behalf of clients that need media services but aren't aware of an MRB or its operation 🙈. Here the Application Server doesn't provide explicit info on the kind of Media Server resource it needs (as in Section 5.2), so the MRB is left to deduce it by potentially inspecting other info in the request from the Application Server. For example, that could be Session Description Protocol (SDP) content, the address of the requesting Application Server, or additional Request-URI parameters as per RFC 4240 [RFC4240] 🌸.
- In-line Aware MRB Mode (IAMM): Lets an MRB act on behalf of clients that need media services and are aware of an MRB and its operation 🎀. In particular, it lets the Application Server explicitly convey matching characteristics to those provided by Media Servers, just like the Query MRB mode does (as in Section 5.2) ✨.
In either of these roles, signaling as specified by the Media Control Channel Framework ([RFC6230]) would be involved 🍓. The MRB would deduce that the selected Media Server resources are no longer needed when the Application Server or Media Server terminates the corresponding SIP dialog 💅. The two modes are discussed in more detail in Section 5.3 🫶.
5. MRB Interface Definitions 🎀
The whole point of this spec is to give you a toolkit for a bunch of different deployment architectures where media resource brokering can take place 🌈. Two main interfaces are required to support the differing requirements 💜. They're described in the rest of this section, and they've been named the Media Server Resource Publish and Media Server Resource Consumer interfaces ✨.
It's out of scope for this document to define exactly how to construct an MRB using the interfaces described 🙈. It is, however, important that the two interfaces are complimentary so that development of appropriate MRB functionality is supported 🫶.
5.1. Media Server Resource Publish Interface 📡
Okay bestie, the Publish interface is the MRB's whole gossip line about Media Server resources ✨. It's responsible for giving an MRB the right resource info, both the general stuff and the specific stuff 💅. Since everyone needs to get along, this info has to travel over an industry standard mechanism so adoption and interoperability stay high 🫶. To make that happen, a Control Package for the Media Control Channel Framework is going to be specified 🎀. It sets up an establishment and monitoring mechanism so a Media Server can report appropriate statistics to an MRB 📊. The Publish interface is used in both the Query mode and the In-line mode of MRB operation 🦋.
As we already covered in Section 1, the MRB's view of Media Server resource availability is going to be approximate, aka partial and imperfect 🙈. The Publish interface does not give an exhaustive view of current resource consumption. The Media Server may sometimes give a best-effort computed view of the consumption parameters it conveys over Publish, like Digital Signal Processors (DSPs) with a fixed number of streams versus Graphics Processing Units (GPUs) with CPU availability 🧠. Media resource info may only be reported periodically over the Publish interface to an MRB ⏰.
Ngl, the MRB's main job is handing available resources to interested Application Servers, but it also lets you retrieve info about consumed resources 👀. That's relevant (monitoring, obvi), but it inevitably raises security considerations, so implementations should take this into account 🔐. See Section 12 for the full tea 💀.
The MRB Publish interface uses the Media Control Channel Framework ([RFC6230]) as the basis for interaction between a Media Server and an MRB. The framework has an extension mechanism for specific usages called Control Packages 🧩. Section 5.1.1 defines the Control Package that MUST be implemented by any Media Server that wants to interact with an MRB entity 👑.
5.1.1. Control Package Definition 📦
This section fulfills the requirement for information that has to be specified when defining a Control Framework package, as detailed in Section 8 of [RFC6230] 💅.
5.1.1.1. Control Package Name 🏷️
The Media Channel Control Framework requires a Control Package definition to specify and register a unique name and version ✨.
The name and version of this Control Package is "mrb-publish/1.0" 🎀.
5.1.1.2. Framework Message Usage 💌
The MRB Publish interface lets a Media Server convey its available capabilities and resources to an MRB entity 🫶.
This package defines XML elements in Section 5.1.2 and provides an XML schema in Section 10 📜.
The XML elements in this package are split into requests, responses, and event notifications. Requests are carried in CONTROL message bodies, and the <mrbrequest> element is defined as a package request. This request can be used for creating new subscriptions and for updating or removing existing subscriptions 🔄. Event notifications are also carried in CONTROL message bodies, and the <mrbnotification> element is defined for package event notifications 🔔. Responses are carried either in REPORT message or Control Framework 200 response bodies, and the <mrbresponse> element is defined as a package-level response 📨.
Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of [RFC6230]) are used when the request or event notification is invalid, like when a request has invalid XML (400) or is not understood (500) 🙅♀️. Package-level responses are carried in framework 200 response or REPORT message bodies. This package's response codes are defined in Section 5.1.4 🌸.
5.1.1.3. Common XML Support 🧩
The Media Control Channel Framework [RFC6230] requires a Control Package definition to specify whether the attributes for media dialog or conference references are required 📝.
The Publish interface defined in Section 10 does import and make use of the common XML schema defined in the Media Control Channel Framework 💖.
The Consumer interface defined in Section 11 does import and make use of the common XML schema defined in the Media Control Channel Framework 💜.
5.1.1.4. CONTROL Message Body 🎛️
A valid CONTROL message body MUST conform to the schema defined in Section 10 and described in Section 5.1.2. XML messages that appear in CONTROL messages MUST contain either an <mrbrequest> or <mrbnotification> element 🚨.
5.1.1.5. REPORT Message Body 📋
A valid REPORT message body MUST conform to the schema defined in Section 10 and described in Section 5.1.2. XML messages that appear in REPORT messages MUST contain an <mrbresponse> element 💅.
5.1.1.6. Audit 🕵️♀️
The 'mrb-publish/1.0' Media Control Channel Framework package does not require any additional auditing capability 🌈.
5.1.2. Element Definitions 🧁
This section defines the XML elements for the Publish interface Media Control Channel package defined in Section 5.1. The formal XML schema definition for the Publish interface can be found in Section 10 📚.
The root element is <mrbpublish>, and all other XML elements (requests, responses, notifications) live inside it 🏠. The MRB Publish interface request element is detailed in Section 5.1.3. The MRB Publish interface notification element is detailed in Section 5.1.5. The MRB Publish interface response element is detailed in Section 5.1.4 🎯.
The <mrbpublish> element has the following attributes:
version: a token specifying the mrb-publish package version. The value is fixed as'1.0'for this version of the package. The attribute MUST be present. 🔖
The <mrbpublish> element has the following child elements, and there MUST NOT be more than one such child element in any <mrbpublish> message 🙅♀️:
<mrbrequest>for sending an MRB request. See Section 5.1.3.<mrbresponse>for sending an MRB response. See Section 5.1.4.<mrbnotification>for sending an MRB notification. See Section 5.1.5.
5.1.3. <mrbrequest> 📬
This section defines the <mrbrequest> element, which is used to initiate requests from an MRB to a Media Server. The element describes information relevant for the interrogation of a Media Server 🔍.
The <mrbrequest> element has no defined attributes 🫧.
The <mrbrequest> element has the following child element:
<subscription>for initiating a subscription to a Media Server from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 💖
The <subscription> element is included in a request from an MRB to a Media Server to provide the details about how updates are configured (known as a subscription session) 🔔. This element can be used to request a new subscription, to update an existing one (e.g., to change the frequency of the updates), and to remove ongoing subscriptions as well (e.g., to stop an indefinite update) 🔄. The MRB will tell the Media Server how long it wishes to receive updates and how often updates should be sent ⏰. Updates related to the subscription are sent using the <mrbnotification> element 📨.
The <subscription> element has the following attributes:
id: indicates a unique token representing the subscription session between the MRB and the Media Server. The attribute MUST be present. 🆔seqnumber: indicates a sequence number to be used together with the subscription session ID to identify a specific subscription command. The first subscription MUST contain a non-zero numberseqnumber, and subsequent subscriptions MUST contain a higher number than the previousseqnumbervalue. If a subsequentseqnumberis not higher, a 405 response code is generated as per Section 5.1.4 🙈. The attribute MUST be present. 🔢action: provides the operation that should be carried out on the subscription 🎬:- The value of
'create'instructs the Media Server to attempt to set up a new subscription. 🌱 - The value of
'update'instructs the Media Server to attempt to update an existing subscription. ✏️ - The value of
'remove'instructs the Media Server to attempt to remove an existing subscription and consequently stop any ongoing related notification. 🗑️
- The value of
The attribute MUST be present.
The <subscription> element has zero or more of the following child elements:
<expires>: provides the amount of time in seconds that a subscription should be installed for notifications at the Media Server. Once that time has passed, the subscription expires, and the MRB has to subscribe again if it is still interested in receiving notifications from the Media Server ⌛. The element MAY be present.<minfrequency>: provides the minimum frequency in seconds that the MRB wishes to receive notifications from the Media Server. The element MAY be present. 🐢<maxfrequency>: provides the maximum frequency in seconds that the MRB wishes to receive notifications from the Media Server. The element MAY be present. 🐇
Please note that these three optional pieces of information from the MRB are only a suggestion. The Media Server MAY change the proposed values if it considers the suggestions unacceptable (e.g., if the MRB has requested a notification frequency that is too high) 🙃. In that case, the request would not fail, but the updated, acceptable values would be reported in the <mrbresponse> accordingly 💅✨.
5.1.4. <mrbresponse> 💌
okay so this is where the Media Server answers back 💅 every request gets a <mrbresponse> element, bestie.
It has two attributes:
- status: a numeric code saying how things went. This one MUST be present. 🔥
- reason: a string that explains the status. This one MAY be present. ✨
It also has one child element, <subscription>, which gives the details about a subscription that a Media Server requested (more on that in a sec) 🎀
Here are the status codes you can get back:
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 401 | Unable to create Subscription |
| | |
| 402 | Unable to update Subscription |
| | |
| 403 | Unable to remove Subscription |
| | |
| 404 | Subscription does not exist |
| | |
| 405 | Wrong sequence number |
| | |
| 406 | Subscription already exists |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 1: <mrbresponse> Status CodesSo when a new subscription request from an MRB (action='create') gets accepted, the Media Server MUST reply with an <mrbresponse> carrying status code 200 🥳 The same rule applies when an update (action='update') or a remove (action='remove') on an existing transaction can be fulfilled by the Media Server.
Sometimes a subscription request just doesn't work out 💀 when that happens, you use the codes from Table 1 instead. Here's the breakdown:
- If the Media Server can't handle a request because of a syntax error in the request itself (like incorrect XML, breaking the schema constraints, or invalid values in any attribute or element), the Media Server MUST reply with an
<mrbresponse>carrying status code 400 🙈 - If a syntactically correct request fails because it includes an attribute or element the Media Server doesn't understand, the Media Server MUST reply with an
<mrbresponse>carrying status code 420 🧚 - If a syntactically correct request fails because the MRB wants to create a new subscription but the unique
idit gave already exists, the Media Server MUST reply with an<mrbresponse>carrying status code 406 💜 - If a syntactically correct request fails because the MRB wants to update or remove a subscription that doesn't exist, the Media Server MUST reply with an
<mrbresponse>carrying status code 404 🍓 - If the Media Server can't accept a request for any other reason (like the MRB has no more resources left to fulfill it), the Media Server MUST reply with an
<mrbresponse>carrying status code 401, 402, or 403, depending on the action the MRB put in its request:action='create' --> 401;action='update' --> 402;action='remove' --> 403;
A response to a subscription request with status code 200 means the request worked 🌈 That response MAY also contain a <subscription> child that describes the subscription. That <subscription> child MAY contain expires, minfrequency, and maxfrequency values even if the request didn't include them. Bonus info, no cap 🫶
The Media Server can choose to change the suggested expires, minfrequency, and maxfrequency values the MRB sent in its <mrbrequest> if it thinks they're unacceptable (for example, if the requested frequency range is way too high) 👑 When it does, the response MUST contain a <subscription> element describing the subscription as the Media Server accepted it. The Media Server MUST also include in that <subscription> element every value it modified compared to the request, so the MRB knows exactly what changed 💅
5.1.5. <mrbnotification> 📣
The <mrbnotification> element is how a Media Server tells an MRB about its current status. It's sent as a request from the Media Server to the MRB 💖 The Media Server reports its status using the info defined in the <subscription> element, and every update goes out inside an <mrbnotification> element.
It has these attributes:
- id: a unique token for the session between the MRB and the Media Server. It's the same one that shows up in the
<subscription>element. This attribute MUST be present. 🔑 - seqnumber: a sequence number that goes together with the subscription session ID to pin down one specific notification update. The first notification update MUST contain a non-zero
seqnumber, and every later update MUST contain a higher number than the previousseqnumbervalue. If a laterseqnumberisn't higher, the receiving entity should treat it as an error. How it handles that is up to the implementation 🤷♀️ This attribute MUST be present. 🔥
Important tea ☕: theseqnumberin an<mrbnotification>is NOT the same thing as theseqnumberin a<subscription>. The<subscription>one is tied to subscriptions and goes up with every command the MRB issues. The<mrbnotification>one is tied to the asynchronous notifications the Media Server triggers based on the subscription, so it goes up with every notification message. That's how the MRB keeps track of them 🦋
The sub-sections below cover the child elements that make up the contents of <mrbnotification> 🎀
5.1.5.1. <media-server-id>
The <media-server-id> element gives a unique, system-wide identifier for a Media Server instance 🆔 It MUST be present, and it MUST be chosen so that it's extremely unlikely two different Media Servers would show the same id to a given MRB. No twins allowed 👯♀️
5.1.5.2. <supported-packages>
The <supported-packages> element lists the Media Control Channel packages the Media Server supports 📦 It MAY be present.
This element has no attributes.
It has a single child element:
<package>: gives the name of a package the Media Server supports. The<package>element has a single attribute,name, which gives the name of the supported Media Control Channel Framework package. That name has to comply with Section 13.1.1 of [RFC6230] 📖
5.1.5.3. <active-rtp-sessions>
The <active-rtp-sessions> element shows what's going on right now with the active Real-time Transport Protocol (RTP) sessions 🎧 It MAY be present.
This element has no attributes.
It has a single child element:
<rtp-codec>: describes a supported codec and how many active sessions are using it. The<rtp-codec>element has one attribute. The value of that attribute,name, is a media type (which can include parameters per [RFC6381]). The<rtp-codec>element has two child elements. The<decoding>child has, as its content, the decimal number of RTP sessions being decoded with the specified codec. The<encoding>child has, as its content, the decimal number of RTP sessions being encoded with the specified codec 🍓
5.1.5.4. <active-mixer-sessions>
The <active-mixer-sessions> element shows the current active mixed RTP sessions 🎛️ It MAY be present.
This element has no attributes.
It has a single child element:
<active-mix>: describes a mixed active RTP session. The<active-mix>element has one attribute. The value of that attribute,conferenceid, is the name of the mix. The<active-mix>element has one child element,<rtp-codec>, which contains the same RTP session info as defined in Section 5.1.5.3. The element MAY be present. 🌸
5.1.5.5. <non-active-rtp-sessions>
The <non-active-rtp-sessions> element shows the inactive RTP sessions that are currently available, meaning how many more RTP streams this Media Server can handle 💜 It MAY be present.
This element has no attributes.
It has a single child element:
<rtp-codec>: describes a supported codec and the number of non-active sessions for that codec. The<rtp-codec>element has one attribute. The value of that attribute,name, is a media type (which can include parameters per [RFC6381]). The<rtp-codec>element has two child elements. The<decoding>child has, as its content, the decimal number of RTP sessions available for decoding with the specified codec. The<encoding>child has, as its content, the decimal number of RTP sessions available for encoding with the specified codec 🧚
5.1.5.6. <non-active-mixer-sessions>
The <non-active-mixer-sessions> element shows the inactive mixed RTP sessions right now, meaning how many more mixing sessions this Media Server can support 🌈 It MAY be present.
This element has no attributes.
It has a single child element:
<non-active-mix>: describes available mixed RTP sessions. The<non-active-mix>element has one attribute. The value of that attribute,available, is the number of mixes that could be used with that profile. The<non-active-mix>element has one child element,<rtp-codec>, which contains the same RTP session info as defined in Section 5.1.5.5. The element MAY be present. ⭐
5.1.5.7. <media-server-status>
The <media-server-status> element shows the current status of the Media Server 🚦 It MUST be present, and it can return one of these values:
- active: the Media Server is available for service. 🟢
- deactivated: the Media Server has been withdrawn from service, so requests should not be sent to it until it becomes
activeagain. 🛑 - unavailable: the Media Server keeps processing past requests but can't accept new ones, so it should not be contacted until it becomes
activeagain. 🥲
This element has no attributes and no child elements.
5.1.5.8. <supported-codecs> 🎧✨
okay bestie, the <supported-codecs> element is the Media Server's codec wardrobe 👗🎀. It tells you which codecs it's currently rocking and what it can actually do with each one 💅. The element MAY be present.
The <supported-codecs> element has no attributes.
The <supported-codecs> element has a single child element:
<supported-codec>: has a single attribute,'name', which gives the name of the codec this element is spilling about 🫶. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The<supported-codec>element then has one more child,<supported-codec-package>. That one has a single attribute,'name', which is the name of the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the codec support applies to 🦋.<supported-codec-package>has zero or more<supported-action>children, and each one describes an action a Media Server can apply to this codec:'decoding', meaning a decoder for this codec is available;'encoding', meaning an encoder for this codec is available;'passthrough', meaning the Media Server is able to pass a stream encoded using that codec through, without re-encoding.
5.1.5.9. <application-data> 🌸
the <application-data> element is basically a free-texting zone 📱. It carries an arbitrary string of characters as application-level data. This data only has meaning to the application-level logic, so this spec doesn't restrict it any further 🙈. The allowed characters are the same ones XML allows: tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012] (see also Section 2.2 of <http://www.w3.org/TR/xml/>). The element MAY be present.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.1.5.10. <file-formats> 🎬
the <file-formats> element is the list of file formats a Media Server supports for playing media 🍿. The element MAY be present.
The <file-formats> element has no attributes.
The <file-formats> element has zero of more the following child elements:
<supported-format>: has a single attribute,'name', which gives the type of file format that's supported. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The<supported-format>element then has a further child element,<supported-file-package>. The<supported-file-package>element gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the file format support applies to 💖.
5.1.5.11. <max-prepared-duration> ⏳
the <max-prepared-duration> element tells you the longest a media dialog can chill in the prepared state before it times out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231]. The element MAY be present.
The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has a single child element:
<max-time>: has a single attribute,'max-time-seconds', which gives the amount of time in seconds that a media dialog can be in the prepared state. The<max-time>element then has a further child element,<max-time-package>. The<max-time-package>element gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the time period applies to 🧚.
5.1.5.12. <dtmf-support> 📞
the <dtmf-support> element says how a Media Server can detect DTMF tones and how it can generate them 🔥. The element MAY be present.
The <dtmf-support> element has no attributes.
The <dtmf-support> element has zero of more of the following child elements:
<detect>: shows support for DTMF detection. The<detect>element has no attributes. It then has a further child element,<dtmf-type>. The<dtmf-type>element has two attributes:'name'and'package'. The'name'attribute gives the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (detecting tones as signals from the audio stream). The'package'attribute gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the DTMF type applies to 🦋.<generate>: shows support for DTMF generation. The<generate>element has no attributes. It then has a further child element,<dtmf-type>. The<dtmf-type>element has two attributes:'name'and'package'. The'name'attribute gives the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (generating tones as signals in the audio stream). The'package'attribute gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the DTMF type applies to 🎀.<passthrough>: shows support for passing DTMF through without re-encoding. The<passthrough>element has no attributes. It then has a further child element,<dtmf-type>. The<dtmf-type>element has two attributes:'name'and'package'. The'name'attribute gives the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through the audio stream). The'package'attribute gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the DTMF type applies to 💜.
5.1.5.13. <mixing-modes> 🎛️
the <mixing-modes> element is all about audio and video mixing on a Media Server 🎶. It lists which algorithms it can use to mix audio, and which video presentation layouts it supports. The element MAY be present.
The <mixing-modes> element has no attributes.
The <mixing-modes> element has zero or more of the following child elements:
<audio-mixing-modes>: describes the available algorithms for audio mixing. The<audio-mixing-modes>element has no attributes. It has one child element,<audio-mixing-mode>, which contains a specific available algorithm. Valid values for<audio-mixing-mode>are algorithm names, e.g., 'nbest' and 'controller' as defined in [RFC6505]. The element has a single attribute,'package', which gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the algorithm support applies to 🫶.<video-mixing-modes>: describes the available video presentation layouts and the supported functionality related to video mixing. The<video-mixing-modes>element has two attributes:'vas'and'activespeakermix'. The'vas'attribute is of type boolean, and a value of 'true' means the Media Server supports automatic Voice Activated Switching. The'activespeakermix'attribute is of type boolean, and a value of 'true' means the Media Server is able to prepare an additional video stream for the loudest speaker participant without its contribution. The<video-mixing-modes>element has one child element,<video-mixing-mode>, which contains the name of a specific video presentation layout. The name may refer to one of the predefined video layouts defined in the XCON conference information data model [RFC6501], or to non-XCON layouts as well, as long as they are properly prefixed according to the schema they belong to. The<video-mixing-mode>element has a single attribute,'package', which gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], that the algorithm support applies to 🌈.
5.1.5.14. <supported-tones> 🔔
the <supported-tones> element tells you which tones a Media Server can play and recognize 🎵. It reports support by referring to both country codes (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
The <supported-tones> element has no attributes.
The <supported-tones> element has zero or more of the following child elements:
<supported-country-codes>: describes the supported country codes with respect to tones. The<supported-country-codes>element has no attributes. It has one child element,<country-code>, which reports support for a specific country code, compliant with the ISO 3166-1 [ISO.3166-1] specification. The<country-code>element has a single attribute,'package', which gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], in which the tones from the specified country code are supported 🌸.<supported-h248-codes>: describes the supported H.248 codes with respect to tones. The<supported-h248-codes>element has no attributes. It has one child element,<h248-code>, which reports support for a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can be either specific (e.g., cg/dt to only report the Dial Tone from the Call Progress Tones package) or generic (e.g., cg/* to report all the tones from the Call Progress Tones package), using wildcards. The<h248-code>element has a single attribute,'package', which gives the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], in which the specified codes are supported 🍓.
5.1.5.15. <file-transfer-modes> 📂✨
okay bestie, this one tells the MRB which scheme names a Media Server can use for transferring files to it, for each package type 💅 like, does it do HTTP, HTTPS, NFS, whatever? The element MAY be present 🫶
The <file-transfer-modes> element has no attributes 🎀
It has a single child element, <file-transfer-mode> 🧚 which has two attributes:
name: the scheme name of the protocol that can be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.). The value is case insensitive.package: the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g.,"msc-ivr/1.0"), that the scheme name applies to.
⚠️ Big note, bestie: this element tells you NOTHING about live streaming 🙈 A value of"HTTP"for the IVR (Interactive Voice Response) Package only means thehttpscheme makes sense to the Media Server within that package. Whether it can use HTTP just to fetch resources, or also to attach an HTTP live stream to a call, is implementation specific to the Media Server and irrelevant to the Application Server and/or MRB 💀 Also, supporting a scheme doesn't mean it supports the secure version too 🔐 If the Media Server supports both HTTP and HTTPS, both will show up in the element. A lack of the"HTTPS"value needs to be read as a lack of support for thehttpsscheme. Not me being picky, it's just how it works 💜
5.1.5.16. <asr-tts-support> 🎙️
the <asr-tts-support> element tells you about Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) support in a Media Server 🌸 Languages are reported using ISO 639-1 [ISO.639.2002] codes, for both ASR and TTS. The element MAY be present 💖
The <asr-tts-support> element has no attributes 🦋
It has zero or more of the following child elements:
<asr-support>: describes the available languages for ASR. It has no attributes and one child element,<language>, which reports that the Media Server supports ASR for a specific language. The<language>element has a single attribute,xml:lang, which contains the ISO 639-1 [ISO.639.2002] code of the supported language.<tts-support>: describes the available languages for TTS. It has no attributes and one child element,<language>, which reports that the Media Server supports TTS for a specific language. The<language>element has a single attribute,xml:lang, which contains the ISO 639-1 [ISO.639.2002] code of the supported language.
5.1.5.17. <vxml-support> 🌈
the <vxml-support> element says whether the Media Server supports VoiceXML (VXML) and, if it does, which protocols expose that support (e.g., via the control framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]) 🧁 The element MAY be present ✨
The <vxml-support> element has no attributes 🎀
It has a single child element, <vxml-mode> 👑 which has two attributes:
package: the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the VXML support applies.support: the type of VXML support the Media Server provides (e.g., RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package [RFC6231]). Valid values are case-insensitive RFC references, like"rfc6231"to say the Media Server supports VoiceXML as provided by the IVR Package [RFC6231].
So if at least one <vxml-mode> child is there, the Media Server does support VXML as that child element describes 💅 An empty <vxml> element would otherwise mean the Media Server doesn't support VXML at all 🙈
5.1.5.18. <media-server-location> 📍
the <media-server-location> element gives the civic location of a Media Server 🗺️ Its description uses the Civic Address Schema standardized in RFC 5139 [RFC5139]. The element MAY be present. Honestly this whole section is entirely optional 🫶 It's implementation specific, so fill it with just the details each implementer thinks are needed for any optimization that might come up ✨
The <media-server-location> element has no attributes 🦋
It has a single child element, <civicAddress> 🏠 which describes the civic address location of the Media Server, and whose representation refers to Section 4 of RFC 5139 [RFC5139].
5.1.5.19. <label> 🏷️
the <label> element lets a Media Server declare a piece of information the MRB will understand 🫧 Like, the Media Server can say if it's a blue one or a green one 💙💚 It's a string, so arbitrary values can be returned for arbitrary classification. The element MAY be present 💜
The <label> element has no attributes and no child elements 🌸
5.1.5.20. <media-server-address> 🔗
the <media-server-address> element lets a Media Server give a direct SIP URI where it can be reached 📞 Think of the URI the Application Server would call to set up a Control Channel and relay SIP media dialogs 🧚 The element MAY be present.
The <media-server-address> element has no attributes and no child elements 💅
5.1.5.21. <encryption> 🔐
the <encryption> element lets a Media Server declare support for encrypting RTP media streams using RFC 3711 [RFC3711] 🛡️ The element MAY be present. If the element is there, then the Media Server supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP) extension for Datagram Transport Layer Security (DTLS)) [RFC5763] 🦋✨
The <encryption> element has no attributes and no child elements 🎀
5.2. Media Service Resource Consumer Interface 🫧
okay so the Media Server Consumer interface is how clients of an MRB, like Application Servers, ask for an appropriate Media Server that fits specific criteria 💖 This interface lets a client pass detailed meta-information to the MRB to help pick one 🔍 The MRB is then able to make an informed decision and hand the client an appropriate Media Server resource 👑 The MRB Consumer interface includes both 1) the In-line Aware MRB Mode (IAMM), which uses the Session Initiation Protocol (SIP), and 2) the Query mode, which uses the Hypertext Transfer Protocol (HTTP) [RFC2616]. It does NOT include the In-line Unaware Mode (IUMM), which gets explained more in Section 5.3 🙈 The sub-sections below give guidance on using the Consumer interface, which is represented by the application/mrb-consumer+xml media type in Section 11, with HTTP and SIP 💅
5.2.1. Query Mode/HTTP Consumer Interface Usage 🌐
the query style interface is basically an HTTP usage 🌸 Using HTTP and XML together cuts down complexity and encourages the use of common tools that are widely available in the industry today 🧰 The following info covers the primary operations required to request and then receive information from an MRB, using HTTP [RFC2616] and HTTPS [RFC2818] as the transport for a query for a media resource, plus the response 💜
The media resource query, as defined by the <mediaResourceRequest> element from Section 11, MUST be carried in the body of an HTTP/HTTPS POST request 📮 The media type in the HTTP/HTTPS request/response MUST be application/mrb-consumer+xml. This value MUST be reflected in the appropriate HTTP headers, such as Content-Type and Accept 🎀 The body of the HTTP/HTTPS POST request MUST only contain an <mrbconsumer> root element with only one child <mediaResourceRequest> element as defined in Section 11 ✨
The media resource response to a query, as defined by the <mediaResourceResponse> element from Section 11, MUST be carried in the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS POST request 🦋 The media type in the HTTP/HTTPS request/response MUST be application/mrb-consumer+xml. This value MUST be reflected in the appropriate HTTP headers, such as Content-Type and Accept 🫶 The body of the HTTP/HTTPS 200 response MUST only contain an <mrbconsumer> root element with only one child <mediaResourceResponse> element as defined in Section 11 💅
When an Application Server wants to release media resources it was previously awarded through a prior request/response exchange with an MRB, it sends a new request with an <action> element with the value remove, as described in Section 5.2.3 ("Consumer Interface Lease Mechanism") 🧚
5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage 📞
this document gives a complete toolkit for MRB deployment, including the ability to interact with an MRB using SIP for the Consumer interface 💖 The following info covers the primary operations required to request and receive info from an MRB, using SIP [RFC3261] as the transport for a request for media resources, plus the response when using IAMM as the mode of operation (as discussed in Section 5.2.2.1) 👑
IAMM is a whole vibe 🌈 Besides having the MRB pick appropriate media resources on behalf of a client application, it also sets up either a Control Framework Control Channel between an Application Server and one of the Media Servers (Section 5.2.2.1), or a media dialog session between an Application Server and one of the Media Servers (Section 5.2.2.2) 🫧 Note that in either case, the SIP URIs of the selected Media Servers are made known to the requesting Application Server in the SIP 200 OK response, through one or more <media-server-address> child elements in the <response-session-info> element (Section 5.2.6) ✨🎀
5.2.2.1. IAMM and Setting Up a Control Framework Control Channel 💖
Okay so the media resource request info, the <mediaResourceRequest> element from Section 11, rides along inside a SIP INVITE 🦋. That INVITE gets built the same way it would be to connect to a Media Server, as laid out in the Media Control Channel Framework [RFC6230]. Also, this spec doesn't rule out offerless INVITEs from RFC 3261 [RFC3261], ngl 🤷♀️. But offerless INVITEs sent to an MRB can get confusing when it's picking resources, and an MRB (like any SIP device) can totally bounce them with a 4xx response 💀. For an offerless INVITE to get handled properly, you'd need extra context in the request, and that's out of scope for this doc 🙈
The following additional steps MUST be followed when using the Consumer interface:
- The Consumer client will include a payload in the SIP INVITE request of type
multipart/mixed[RFC2046]. One of the parts in thatmultipart/mixedpayload MUST be theapplication/sdpformat, which is constructed as specified in the Media Control Channel Framework [RFC6230] 🎀 - Another part of the
multipart/mixedpayload MUST be of typeapplication/mrb-consumer+xml, as specified in this document and defined in Section 11. The body part MUST be an XML document without prolog, and its root element is<mediaResourceRequest>✨ - The INVITE request then gets dispatched to the MRB, as defined by [RFC6230] 🚀
When the MRB gets a SIP INVITE request with that multipart/mixed payload, it's got some work to do to fulfill the request. It will:
- Extract the multipart MIME payload from the SIP INVITE request. Then it uses the contextual info the client gave in the
application/mrb-consumer+xmlpart to figure out which Media Server (or Media Servers, if more than one is needed) should be picked to service the request 🧚 - Extract the
application/sdppart from the payload and use it as the body of a new SIP INVITE request that connects the client to one of the selected Media Servers, as defined in the Media Channel Control Framework [RFC6230]. The policy the MRB uses to pick one specific Media Server out of the ones it selected is implementation specific and out of scope for this doc. It's really important to configure the SIP elements between the MRB and the Media Server so the INVITE will not fork 😤 If the chosen Media Server can't be reached, the MRB SHOULD proceed to the next one, if available 🫶
If none of the available Media Servers can be reached, the MRB MUST reply with a SIP 503 error message that includes a Retry-After header with a non-zero value. The Application Server MUST NOT attempt to set up a new session before the time the MRB asked it to wait has passed 😭
If at least one Media Server is reachable, the MRB acts as a Back-to-Back User Agent (B2BUA). It extracts the application/mrb-consumer+xml information from the SIP INVITE request, then sends a corresponding SIP INVITE request to the Media Server it picked, to negotiate a Control Channel as defined in the Media Channel Control Framework [RFC6230] 🌈
If negotiating the Control Channel with the Media Server fails, the MRB SHOULD proceed to the next one, if available, as explained above. If none of the available Media Servers can be reached, or the Control Channel negotiations with all of them fail, the MRB MUST reply with a SIP 503 error message that includes a Retry-After header with a non-zero value. The Application Server MUST NOT attempt to set up a new session before the time the MRB asked it to wait has expired 💅
Once the MRB gets the SIP response from the selected media resource (i.e., Media Server), it in turn responds to the requesting client (i.e., Application Server) 🦋
The media resource response an MRB generates for a request, as defined by the <mediaResourceResponse> element from Section 11, MUST be carried in the payload of a SIP 200 OK response to the original SIP INVITE request. The SIP 200 OK response is constructed as it would have been to connect from a Media Server, as defined by the Media Control Channel Framework [RFC6230]. The following additional steps MUST be followed when using the Consumer interface:
- Include a payload in the SIP 200 response of type
multipart/mixed, as per RFC 2046 [RFC2046]. One of the parts in themultipart/mixedpayload MUST be theapplication/sdpformat, which is constructed as specified in the Media Control Channel Framework [RFC6230] and based on the incoming response from the selected media resource 🌸 - Another part of the
multipart/mixedpayload MUST be of typeapplication/mrb-consumer+xml, as specified in this document and defined in Section 11. Only the<mediaResourceResponse>and its child elements can be included in the payload 👑 - The SIP 200 response then gets dispatched from the MRB ✨
- A SIP ACK to the 200 response then gets sent back to the MRB 🫶
Okay, real talk: using SIP as a transport for Consumer transactions can fail, so the IAMM leans on a successful INVITE transaction to handle the sequence (using the seq XML element) increment mechanism we talked about earlier 🧠 This means that if the INVITE is unsuccessful for any reason, the Application Server MUST use the same seq value it used before for the next Consumer request it wants to send to the MRB for the same session. Don't skip that, bestie 🙈
An MRB implementation may be programmed to conclude that the requested resources are no longer needed when it receives a SIP BYE from the Application Server or Media Server that concludes the SIP dialog that started the request, or when the lease (Section 5.2.3) interval expires 🌙
5.2.2.2. IAMM and Setting Up a Media Dialog 🎀
This is giving déjà vu, but it's literally the same as the Control Framework Control Channel setup we just covered in the previous section 🥰 The one difference is that the application/sdp payload carries the content needed to set up the media dialog to the media resource, as per RFC 3261 [RFC3261], instead of setting up a Control Channel. Iconic, periodt 💜
5.2.3. Consumer Interface Lease Mechanism ✨
okay bestie, so the Consumer interface (Sections 5.2 and 11) lets a client ask for a suitable media resource based on what's in the request, either an HTTP POST or a SIP INVITE 💖. If it works, the response back to the client MUST contain a <response-session-info> element in either the SIP 200 or HTTP 200 response 🎀. That success response describes certain resources reserved for that specific Consumer client in a (new or revised) "resource session", and the session is identified inside the <response-session-info> 🦋. The resource session is a "lease", because the reservation is scheduled to expire at a set time in the future, which frees those resources up for other uses ⏰. A future Consumer client request that points at that specific resource session can extend the lease or end it early 💅.
Before we get into the lease details, it's worth knowing its role in the Consumer interface 🧚. Like Section 5.1 explained, the MRB's knowledge of the resources on all the Media Servers it's provisioned to manage is not real-time 😭. How an MRB actually manages those resources is implementation specific. For example, an implementation might have the MRB keep track of the allocated resources and their state, or it might just rely on the Media Servers to provide the information through the Publish interface. More information can also be inferred from the signaling, in the case where an MRB is in the path of media dialogs 👑.
The <mediaResourceResponse> element returned from the MRB contains a <response-session-info> element if the request is successful. The <response-session-info> element has zero or more of the following child elements, which provide the resource session information 🌸:
<session-id>is a unique identifier that lets a Consumer client and MRB match up future media resource requests with the initial one 🔑. The<session-id>MUST be included in all future related requests (see the<session-id>paragraph later in this section, where constructing a subsequent request is discussed).<seq>is a numeric value returned to the Consumer client 🔢. When issuing any future requests related to the media resource session (as determined by the<session-id>element), the Consumer client MUST increment the value returned in the<seq>element and include it in the request (see the<seq>paragraph later in this section, where constructing a subsequent request is discussed). Its value is a non-negative integer that MUST be limited within the0..2^31-1range.<expires>gives a value indicating the number of seconds that the request for media resources is considered alive ⏳. The Consumer client should issue a refresh of the request, as discussed later in this section, if the expiry is about to fire and the media resources are still needed.<media-server-address>provides information representing an assigned Media Server 🖥️. More instances of this element may appear if the MRB assigns more Media Servers to a Consumer request.
The <mediaResourceRequest> element is used in subsequent Consumer interface requests if the client wants to manipulate the session 💜. The Consumer client MUST include the <session-info> element, which lets the receiving MRB figure out which existing media resource allocation session is meant. The <session-info> element has the following child elements, which give the MRB the resource session information 🎀:
<session-id>is a unique identifier that lets a Consumer client point at the existing media resource session the MRB should manipulate for this request 🦋. The value was provided by the MRB in the initial request for media resources, as discussed earlier in this section (<session-id>element included as part of the<session-info>element in the initial<mediaResourceResponse>).<seq>is a numeric value returned to the Consumer client in the initial request for media resources, as discussed earlier in this section (<seq>element included as part of the<session-info>element in the initial<mediaResourceResponse>). When issuing any future requests related to the specific media resource session (as determined by the<session-id>element), the Consumer client MUST increment the value returned in the<seq>element from the initial response (contained in the<mediaResourceResponse>) for every new request. The value of the<seq>element in requests acts as a counter, and when it's used together with the unique<session-id>, it allows each request to be uniquely identified 🧩. As anticipated before, the<seq>value is limited to the0..2^31-1range: in the unlikely case that the counter increases to reach the highest allowed value, the<seq>value MUST be set to 0. The first numeric value for the<seq>element is not meant to be'1'but SHOULD be generated randomly by the MRB. This is to reduce the chances of a malicious MRB disrupting the session created by this MRB, as explained in Section 12 🚨.<action>provides the operation the MRB should carry out when it receives the request 💅:- The value of
'update'is a request by the Consumer client to update the existing session on the MRB with alternate media resource requirements. If the requested resource information is identical to the existing MRB session, the MRB will attempt a session refresh. If the information has changed, the MRB will attempt to update the existing session with the new information. If the operation is successful, the200status code in the response is returned in the status attribute of the<mediaResourceResponseType>element ✅. If the operation is not successful, a409status code in the response is returned in the status attribute of the<mediaResourceResponseType>element ❌. - The value of
'remove'is a request by the Consumer client to remove the session on the MRB. This gives Consumer clients a way to release unwanted resources before they expire 🗑️. If the operation is successful, a200status code in the response is returned in the status attribute of the<mediaResourceResponseType>element. If the operation is not successful, a410status code in the response is returned in the status attribute of the<mediaResourceResponseType>element.
- The value of
Omitting the 'action' attribute means requesting a new set of resources 🌈.
When used with HTTP, the <session-info> element MUST be included in an HTTP POST message (as defined in [RFC2616]). When used with SIP, the <session-info> element MUST instead be included in either a SIP INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP UPDATE (as defined in [RFC3311]) request. Honestly, any SIP dialog, whether it's new or existing, can be used to carry leasing information, so new SIP INVITE messages can update other leases as well as request a new one 🫶.
With IAMM, the Application Server or Media Server will eventually send a SIP BYE to end the SIP session, whether it was for a Control Channel or a media dialog 📞. That BYE contains no Consumer interface lease information 🙈.
5.2.4. <mrbconsumer> 🌷
This section defines the XML elements for the Consumer interface. The formal XML schema definition for the Consumer interface can be found in Section 11 📜.
The root element is <mrbconsumer>. All other XML elements (requests, responses) are contained within it. The MRB Consumer interface request element is detailed in Section 5.2.5.1. The MRB Consumer interface response element is detailed in Section 5.2.6.1.
The <mrbconsumer> element has the following attributes:
version: a token specifying the mrb-consumer package version. The value is fixed as'1.0'for this version of the package. The attribute MUST be present.
The <mrbconsumer> element may have zero or more children of one of the following child element types:
<mediaResourceRequest>for sending a Consumer request. See Section 5.2.5.1.<mediaResourceResponse>for sending a Consumer response. See Section 5.2.6.1.
5.2.5. Media Service Resource Request 💖
This section provides the element definitions for use in Consumer interface requests. The requests are carried in the <mediaResourceRequest> element.
5.2.5.1. <mediaResourceRequest> 🎀
The <mediaResourceRequest> element provides information for clients who want to query an external MRB entity. It has a single mandatory attribute, 'id'. This attribute contains a random identifier, generated by the client, that will be included in the response so it can be mapped to a specific request 🔖. The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and <mixerInfo> as child elements. These three elements are used to describe the requirements of a client requesting a Media Server, and they're covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3, respectively 🧚.
5.2.5.1.1. <generalInfo> 🌸
The <generalInfo> element provides general Consumer request information that is neither IVR specific nor mixer specific. This includes session information that can be used for subsequent requests as part of the leasing mechanism described in Section 5.2.3 🦋. The following sub-sections describe the <session-info> and <packages> elements, as used by the <generalInfo> element.
5.2.5.1.1.1. <session-info> 💜
The <session-info> element is included in Consumer requests when an update is being made to an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3. The element MAY be present.
The <session-info> element has no attributes.
The <session-info> element has zero or more of the following child elements:
<session-id>: A unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3 🔑.<seq>: Used together with the<session-id>element in a subsequent request to update an existing media resource session on an MRB. The<seq>number is incremented from its original value returned in response to the initial request for media resources. Its value is a non-negative integer that MUST be limited within the0..2^31-1range. In the unlikely case that the counter increases to reach the highest allowed value, the<seq>value MUST be set to 0. More information about its use is provided in Section 5.2.3 🔢.<action>: Provides the operation that should be carried out on an existing media resource session on an MRB:- The value of
'update'instructs the MRB to attempt to update the existing media resource session with the information contained in the<ivrInfo>and<mixerInfo>elements ✨. - The value of
'remove'instructs the MRB to attempt to remove the existing media resource session. More information on its use is provided in Section 5.2.3 🗑️.
- The value of
5.2.5.1.1.2. <packages>
I'm basically putting this in the group chat 💅 okay so the <packages> element is how a Consumer client lists the Media Control Channel Framework packages it needs 🎀 It's optional, so it MAY be present 🦋
It has no attributes, zero vibes, zero fuss ✨
It has a single child element:
- <package>: holds a string naming the Media Control Channel Framework package the Consumer client needs 💖 You can have it show up multiple times, bestie 🌈 A valid value is a Control Package name that follows Section 13.1.1 of [RFC6230] 🫶
5.2.5.1.2. <ivrInfo> 🧚
Okay this one is giving IVR realness 📞✨ The <ivrInfo> element holds general Consumer request info that's specifically about IVR 💜 The subsections below break it down: <ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <encryption>, <application-data>, <max-prepared-duration>, and <file-transfer-modes> 🌸
5.2.5.1.2.1. <ivr-sessions>
The <ivr-sessions> element says how many IVR sessions a Consumer client needs from a media resource 🍓 It MAY be present 💅
It has no attributes, which is so clean 🫧
It has a single child element:
- <rtp-codec>: describes a codec the client needs and how many sessions use it 🎀 This one has one attribute, 'name', whose value is a media type (parameters allowed per [RFC6381]) 💫 It also has two child elements: <decoding> holds the number of RTP sessions needed for decoding with that codec, and <encoding> holds the number needed for encoding with that codec 🦋
5.2.5.1.2.2. <file-formats>
The <file-formats> element lists the file formats required for playing media 🎶 Real talk, this element is actually about media types, and it might've been better named "media-formats" 🙈 But because of existing implementations, the name "file-formats" is what we're stuck with 😭 It MAY be present 🌷
It has no attributes ✨
It has a single child element:
- <required-format>: has a single attribute, 'name', that gives the type of file format needed 💖 A valid value is a media type, which can include extra parameters depending on its definition (e.g., [RFC6381]) 🌈 The <required-format> element then has one more child, <required-file-package> 🧁 That one has a single attribute, 'required-file-package-name', which holds the name of the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the file format support applies to 🫶
5.2.5.1.2.3. <dtmf>
The <dtmf> element says which methods are required for detecting DTMF tones and generating them 🔥 It MAY be present 💅
It has no attributes, periodt 💖
It has zero or more of the following child elements:
- <detect>: says what DTMF detection support is required 🎀 It has no attributes. It has a further child, <dtmf-type>, which has two attributes: 'name' and 'package' 🦋 The 'name' attribute gives the type of DTMF needed. It's a case-insensitive string that's either 'RFC4733' [RFC4733] or 'Media' (detecting tones as signals from the audio stream) ✨ The 'package' attribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 💜
- <generate>: says what DTMF generation support is required 🌸 It has no attributes. It has a single child, <dtmf-type>, which has two attributes: 'name' and 'package' 🍓 The 'name' attribute is a case-insensitive string that's either 'RFC4733' [RFC4733] or 'Media' (generating tones as signals in the audio stream) 🧚 The 'package' attribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 🫶
- <passthrough>: says what support is required for passing DTMF through without re-encoding 💫 It has no attributes. It then has a further child, <dtmf-type>, which has two attributes: 'name' and 'package' 🌈 The 'name' attribute is a case-insensitive string that's either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through the audio stream) 👑 The 'package' attribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 💖
5.2.5.1.2.4. <tones>
The <tones> element lists the tones a Media Server MUST support for IVR 🔔 Specifically, the request covers both country codes (ISO 3166-1 [ISO.3166-1]) and the requested functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]) 🌍 It MAY be present 🎀
It has no attributes ✨
It has zero or more of the following child elements:
- <country-codes>: describes the requested country codes for tones 🇺🇳 It has no attributes. It has one child, <country-code>, which requests a specific country code compliant with the ISO 3166-1 [ISO.3166-1] specification 💅 The <country-code> element has a single attribute, 'package', which names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) where the tones from that country code are requested 🦋
- <h248-codes>: describes the requested H.248 codes for tones 🧃 It has no attributes. It has one child, <h248-code>, which requests a specific H.248 code compliant with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification 🌸 The codes can be specific (e.g., cg/dt to only report the Dial Tone from the Call Progress Tones package) or generic (e.g., cg/* to report all the tones from the Call Progress Tones package), using wildcards 🍓 The <h248-code> element has a single attribute, 'package', which names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) where the specified codes are requested 💜
5.2.5.1.2.5. <asr-tts>
The <asr-tts> element asks about support for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) in a Media Server 🎤 It does this by referring to supported languages (using ISO 639-1 [ISO.639.2002] codes) for both ASR and TTS 🌎 It has no attributes 🫧
It has zero or more of the following child elements:
- <asr-support>: describes the available languages for ASR 🗣️ It has no attributes. It has one child, <language>, which requests that the Media Server supports ASR for a specific language 💖 The <language> element has a single attribute, 'xml:lang', which contains the ISO 639-1 [ISO.639.2002] code of that language 🌈
- <tts-support>: describes the available languages for TTS 🔊 It has no attributes. It has one child, <language>, which requests that the Media Server supports TTS for a specific language 🎀 The <language> element has a single attribute, 'xml:lang', which contains the ISO 639-1 [ISO.639.2002] code of that language 🦋
5.2.5.1.2.6. <vxml>
The <vxml> element says whether the Consumer client requires VoiceXML and, if so, which protocols are supported (e.g., via the control framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]) 🎙️ It MAY be present 💫
It has a single child element:
- <vxml-mode>: has two attributes, 'package' and 'require' ✨ The 'package' attribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the VXML support applies to 💜 The 'require' attribute specifies the type of VXML support the Consumer client requires (e.g., RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]) 🌸 Valid values are case-insensitive RFC references (e.g., "rfc6231" to specify that the client requests support for VoiceXML as provided by the IVR Package [RFC6231]) 🍓
The presence of at least one <vxml> child element indicates that the Consumer client requires VXML support as specified by that child element itself 🧚 An empty <vxml> element otherwise indicates that the Consumer client does not require VXML support 🙅♀️
5.2.5.1.2.7. <location>
The <location> element requests a civic location for an IVR Media Server 📍 The request uses the Civic Address Schema standardized in RFC 5139 [RFC5139] 🗺️ It MAY be present 🌷 More precisely, this section is entirely optional and its level of population is implementation specific 🫶
It has no attributes ✨
It has a single child element:
- <civicAddress>: describes the civic address location of the requested Media Server, whose representation refers to Section 4 of RFC 5139 [RFC5139] 🏡 💖
5.2.5.1.2.8. <encryption>
The <encryption> element lets a Consumer client request support for encrypting RTP media streams using RFC 3711 [RFC3711] 🔐 It MAY be present 💅 If the element is present, then the Media Server supports DTLS-SRTP [RFC5763] 🦋
It has no attributes ✨
It has no child elements 🫧
5.2.5.1.2.9. <application-data>
The <application-data> element carries an arbitrary string of characters as IVR application-level data 💌 This data is only meant to have meaning at the application-level logic, so this specification doesn't restrict it otherwise 🧠 The set of allowed characters is the same as in XML (namely tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012], see also Section 2.2 of <http://www.w3.org/TR/xml/>) 🌈 It MAY be present 🎀
It has no attributes ✨
It has no child elements 💀
5.2.5.1.2.10. <max-prepared-duration> ✨
okay so the <max-prepared-duration> element tells us how much time the Consumer client needs for media dialog preparation in the system before it actually gets executed 🧚 it's kind of a prep-time thing, bestie 💅 the element MAY be present 🎀
The <max-prepared-duration> element has no attributes 💖
The <max-prepared-duration> element has a single child element 🌸
<max-time>: this one has a single attribute,max-time-seconds, which gives the number of seconds a media dialog can sit in the prepared state ⏱️ then<max-time>has one more child,<max-time-package>🦋 that one names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the time period applies to ✨
5.2.5.1.2.11. <file-transfer-modes> 🌈
okay this one is so useful, the <file-transfer-modes> element lets the Consumer client say which scheme names it needs for file transfer to a Media Server, for each Media Control Channel Framework package type 🫶 like, does the Media Server support fetching media resources via HTTP, HTTPS, NFS, etc.? 🤔 the element MAY be present 💜
The <file-transfer-modes> element has no attributes 🍓
The <file-transfer-modes> element has a single child element 👑
<file-transfer-mode>: has two attributes,nameandpackage💅 thenameattribute gives the scheme name of the protocol needed for fetching resources, and valid values are case-insensitive scheme names (e.g.,HTTP,HTTPS,NFS, etc.) 🔥 thepackageattribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the scheme name applies to 🎀
The same considerations about file transfer and live streaming are explained further in Section 5.1.5.15, and they apply here too 🦋 so go check that section, it's giving completeness 😭
5.2.5.1.3. <mixerInfo> 🎀
The <mixerInfo> element is where we put general Consumer request information that's specific to the mixer 💖 the sub-sections below describe its elements: <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>, <application-data>, <location>, and <encryption> ✨
5.2.5.1.3.1. <mixers> 🌸
The <mixers> element provides details about the required mixed RTP sessions 🫶 the element MAY be present 🧚
The <mixers> element has no attributes 🍓
The <mixers> element has a single child element 💅
<mix>: describes the required mixed RTP sessions 🌈 the<mix>element has one attribute,users, which is the number of participants required in the mix 👑 the<mix>element has one child element,<rtp-codec>, and it holds the same RTP session info defined in Section 5.1.5.3 🦋 the element MAY be present 💜
5.2.5.1.3.2. <file-formats> 💅
The <file-formats> element is a list of file formats the Consumer client needs in order to play media to a mix 🎬 the element MAY be present 🎀
The <file-formats> element has no attributes 🌷
The <file-formats> element has a single child element 🔥
<required-format>: has a single attribute,name, which gives the type of file format supported 💖 a valid value is a media type that, depending on its definition, can include extra parameters (e.g., [RFC6381]) ✨ the<required-format>element has a child element,<required-file-package>🦋 that one has a single attribute,required-file-package-name, which holds the name of the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the file format support applies to 🍓
5.2.5.1.3.3. <dtmf> 🧚
The <dtmf> element specifies the required methods for detecting DTMF tones and generating them in a mix 📞 the element MAY be present 💜
The <dtmf> element has no attributes 🌸
The <dtmf> element has zero or more of the following child elements 🫶
<detect>: indicates the required support for DTMF detection 👀 the<detect>element has no attributes, but it has a further child element,<dtmf-type>🔥 the<dtmf-type>element has two attributes,nameandpackage🎀 thenameattribute gives the type of DTMF being used, a case-insensitive string that's eitherRFC4733[RFC4733] orMedia(detecting tones as signals from the audio stream) 🌈 thepackageattribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 💅<generate>: indicates the required support for DTMF generation 🎶 the<generate>element has no attributes and a single child element,<dtmf-type>👑 that<dtmf-type>element has two attributes,nameandpackage💖 thenameattribute is a case-insensitive string that's eitherRFC4733[RFC4733] orMedia(generating tones as signals in the audio stream) ✨ thepackageattribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 🦋<passthrough>: indicates the required support for passing DTMF through without re-encoding 🍓 the<passthrough>element has no attributes and a single child element,<dtmf-type>🧚 that<dtmf-type>element has two attributes,nameandpackage💜 thenameattribute is a case-insensitive string that's eitherRFC4733[RFC4733] orMedia(passing tones as signals through the audio stream) 🌸 thepackageattribute names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the DTMF type applies to 🔥
5.2.5.1.3.4. <tones> 🌈
The <tones> element lists the requested tones that a Media Server must support for a mix 🎵 this covers both country codes (ISO 3166-1 [ISO.3166-1]) and requested functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]) 🌍 the element MAY be present 💖
The <tones> element has no attributes 🎀
The <tones> element has zero or more of the following child elements ✨
<country-codes>: describes the requested country codes for tones 🗺️ the<country-codes>element has no attributes and a single child element,<country-code>, which requests a specific country code that complies with the ISO 3166-1 [ISO.3166-1] specification 💅 the<country-code>element has a single attribute,package, which names the Media Control Channel Framework package (compliant with the specification in the related IANA registry, e.g., "msc-ivr/1.0") that the tones from the specified country code are requested in 🦋<h248-codes>: describes the requested H.248 codes for tones 🎶 the<h248-codes>element has no attributes and a single child element,<h248-code>, which requests a specific H.248 code that complies with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification 👑 the codes can be specific (e.g.,cg/dtto only report the Dial Tone from the Call Progress Tones package) or generic (e.g.,cg/*to report all the tones from the Call Progress Tones package), using wildcards 🌟 the<h248-code>element has a single attribute,package, which names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) in which the specified codes are requested 🍓
5.2.5.1.3.5. <mixing-modes> 🎛️
The <mixing-modes> element requests info about support for audio and video mixing 🎧📺 more specifically, it asks for a list of supported algorithms to mix audio and a list of supported video presentation layouts 🌈 the element MAY be present 🫶
The <mixing-modes> element has no attributes 💅
The <mixing-modes> element has zero or more of the following child elements 🌸
<audio-mixing-modes>: describes the requested algorithms for audio mixing 🎶 the<audio-mixing-modes>element has no attributes and one child element,<audio-mixing-mode>, which contains a requested mixing algorithm 💖 valid values for<audio-mixing-mode>are algorithm names, e.g.,nbestandcontrolleras defined in [RFC6505] ✨ the element has a single attribute,package, which names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the algorithm support is requested for 🦋<video-mixing-modes>: describes the requested video presentation layouts for video mixing 📺 the<video-mixing-modes>element has two attributes,vasandactivespeakermix🔥 thevasattribute is a boolean, and a value oftruemeans the Consumer client requires automatic Voice Activated Switching 🎙️ theactivespeakermixattribute is also a boolean, and a value oftruemeans the Consumer client requires an additional video stream for the loudest speaker participant without its contribution 🫣 the<video-mixing-modes>element has one child element,<video-mixing-mode>, which contains the name of a specific video presentation layout 🎀 that name may refer to one of the predefined video layouts in the XCON conference information data model, or to non-XCON layouts too, as long as they're appropriately prefixed 🌷 the<video-mixing-mode>element has a single attribute,package, which names the Media Control Channel Framework package (compliant with Section 13.1.1 of [RFC6230]) that the algorithm support is requested for 🧚
5.2.5.1.3.6. <application-data> 💜
The <application-data> element gives an arbitrary string of characters as mixer application-level data 📝 this data is only meant to have meaning in the application-level logic, so this specification doesn't otherwise restrict it 🌈 the allowed characters are the same as in XML (viz., tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012] (see also Section 2.2 of http://www.w3.org/TR/xml/)) 🔤 the element MAY be present 🎀
The <application-data> element has no attributes 🍓
The <application-data> element has no child elements 🌸
5.2.5.1.3.7. <location> 📍
The <location> element requests a civic location for a mixer Media Server 🏙️ the request uses the Civic Address Schema standardized in RFC 5139 [RFC5139] 🗺️ the element MAY be present 💖 to be clear, this section is entirely optional, and it's implementation specific, so each implementer fills it with just the details they think are necessary for any optimization that may be needed 🧚
The <location> element has no attributes 🌷
The <location> element has a single child element 🫶
<civicAddress>: describes the civic address location of the requested Media Server, and its representation refers to Section 4 of RFC 5139 [RFC5139] 🏡 ✨
5.2.5.1.3.8. <encryption> 🔐
okay so the <encryption> element is how a Consumer client asks for support for encrypting mixed RTP media streams using RFC 3711 [RFC3711] 💖. The element MAY be present. If it is present, then the Media Server supports DTLS-SRTP [RFC5763] ✨.
The <encryption> element has no attributes 🎀.
The <encryption> element has no child elements 🦋.
5.2.6. Media Service Resource Response 💅
this section gives you the element definitions for Consumer interface responses 🌸. the responses are carried in the <mediaResourceResponse> element 💜.
5.2.6.1. <mediaResourceResponse> 🧚
the <mediaResourceResponse> element gives info to clients that are receiving response info from an external MRB entity ✨.
the <mediaResourceResponse> element has two mandatory attributes, 'id' and 'status' 🎀. the 'id' attribute must contain the same value the client put in the 'id' attribute of the <mediaResourceRequest> that the response is mapped to 🫶. the 'status' attribute shows the status code of the operation 💖. these are the status codes defined for 'status' 👑:
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 405 | Wrong sequence number |
| | |
| 408 | Unable to find Resource |
| | |
| 409 | Unable to update Resource |
| | |
| 410 | Unable to remove Resource |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 2: <mediaResourceResponse> Status Codesif a new media resource request from a client application has been accepted, the MRB MUST reply with a <mediaResourceResponse> with status code 200 🎉. the same rule applies whenever a request to update (action='update') or remove (action='remove') an existing transaction can be fulfilled by the MRB 💫.
a media resource request can still fail, though, for a bunch of reasons 😭. when that happens, the status codes in Table 2 must be used instead 🙈. specifically, if the MRB can't handle a request because of a syntax error in the request itself (like incorrect XML, breaking the schema constraints, or invalid values in any attributes or elements), the MRB MUST reply with a <mediaResourceResponse> with status code 400 💀. if a syntactically correct request fails because it includes any attribute or element the MRB doesn't understand, the MRB MUST reply with a <mediaResourceResponse> with status code 420 🌈. if a syntactically correct request fails because it has a wrong sequence number (a 'seq' value that doesn't match the increment the MRB expects under Section 5.2.3), the MRB MUST reply with a <mediaResourceResponse> with status code 405 🍓. if a syntactically correct request fails because the MRB couldn't find any Media Server able to meet the requirements the Application Server presented, the MRB MUST reply with a <mediaResourceResponse> with status code 408 🔍. if a syntactically correct request fails because the MRB couldn't update an existing request to the new requirements the Application Server presented, the MRB MUST reply with a <mediaResourceResponse> with status code 409 🛠️. and if a syntactically correct request fails because the MRB couldn't remove an existing request and release the related resources as the Application Server asked, the MRB MUST reply with a <mediaResourceResponse> with status code 410 🗑️.
more details on status codes 409 and 410 are in Section 5.2.3, where the leasing mechanism and its scenarios get the full tour 🦋.
the <mediaResourceResponse> element has <response-session-info> as a child element 🎀. it describes the response of a Consumer interface query, and it gets its own sub-section next ✨.
5.2.6.1.1. <response-session-info> 🌸
the <response-session-info> element is included in Consumer responses 💖. this applies to responses for both new resource requests and requests to update an existing media resource session 🫶. Section 5.2.3 has more on changing and removing an existing media resource session 💜.
if the request was successful, the <mediaResourceResponse> MUST have one <response-session-info> child, which describes the media resource session the request addressed ✅. if the request was not successful, the <mediaResourceResponse> MUST NOT have a <response-session-info> child 🙅♀️.
the <response-session-info> element has no attributes 🎀.
the <response-session-info> element has zero or more of these child elements 🧚:
<session-id>: a unique identifier that explicitly references an existing media resource session on the MRB 🔑. it's included to update the existing session, and Section 5.2.3 explains that in more detail 💅.<seq>: used together with<session-id>in a later request to update an existing media resource session on an MRB 🔢. the<seq>number goes up from the original value returned for the initial media resource request ⬆️. Section 5.2.3 has more on how to use it 🌈.<expires>: the number of seconds the media resources are reserved for this interaction ⏳. if the lease isn't refreshed before it expires, the MRB will reclaim the resources and they're no longer guaranteed 😱. it is RECOMMENDED that a minimum value of 300 seconds be used for the value of the'expires'attribute 💡. it is also RECOMMENDED that a Consumer client refresh the lease 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 300 seconds, the Consumer client would refresh the transaction at 240 seconds ⏰. Section 5.2.3 has more on its use 💜.<media-server-address>: gives you the info to reach the Media Server handling the requested media resource 📍. you can get one or more of these elements 🍭. the<media-server-address>element has a single attribute named'uri', which supplies a SIP URI that reaches the specified Media Server 📞. it also has three optional elements:<connection-id>,<ivr-sessions>, and<mixers>🎁. the<ivr-sessions>and<mixers>elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1, respectively, and they mean the same thing, but they apply to individual Media Server instances as a subset of the overall resources reported in the<connection-id>element 🧩. if multiple Media Servers are assigned in an IAMM operation, exactly one<media-server-address>element, specifically the Media Server that provided the media dialog or CFW response, will have a<connection-id>element 👑. more about using<connection-id>for media dialogs is in Section 6 ✨.
5.3. In-Line Unaware MRB Interface 🦋
an entity acting as an In-line MRB can take one of two roles for a request, as introduced in Section 4.2: the In-line Unaware MRB Mode (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of operation 💅. this section goes deeper on IUMM 🌸.
it should be noted that bringing an MRB into the network, as this document specifies, requires the requesting entities (like an Application Server) to implement the interfaces 🫶. this applies when using the Consumer interface, as discussed in Sections 5.2.1 (Query mode) and 5.2.2 (IAMM) 💜. an MRB entity can also act in a client-unaware mode when it's deployed into the network 🧚. this lets any SIP-compliant client entity, as defined by RFC 3261 [RFC3261] and its extensions, send requests to an MRB, which then picks an appropriate Media Server based on the Media Server resources it currently has available, all transparently to the client entity 🎀. using an MRB in this mode makes it easy to migrate current applications and services that don't know about the MRB concept 🍓. they only need a configuration change that sets the MRB as a SIP outbound proxy for clients that need media services ⭐.
with IUMM, the MRB may conclude that an assigned media resource is no longer needed when it receives a SIP BYE from the Application Server or Media Server that ends the SIP dialog that started the request 🌈.
just like IAMM, in IUMM the SIP INVITE from the Application Server could carry the application/sdp payload to set up either a media dialog or a Control Framework Control Channel 📞. either way, to let the Application Server link a media dialog with a Control Channel to the same Media Server, using the procedures of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and not a B2BUA) 🔗. this lets the SIP URI of the targeted Media Server pass back to the Application Server in the SIP response transparently, so you get a direct SIP dialog between the Application Server and the Media Server 🎉.
while IUMM has the least impact on legacy Application Servers, it also gives you the least versatility 🙈. See Section 8 💀.
6. MRB Acting as a B2BUA ✨
okay bestie, so an MRB can be either a SIP Back-to-Back User Agent (B2BUA) or a SIP Proxy Server, as defined in RFC 3261 [RFC3261] 💖. when an MRB acts as a B2BUA, things get a little messy with Media Control Channel packages like the IVR [RFC6231] and mixer [RFC6505] packages 🙈. the framework attribute connectionid from Appendix A ("Common Package Components") of [RFC6230] is built by concatenating SIP dialog identifiers, and that's how you reference SIP dialogs inside the Media Control Channel. but when a request goes through an MRB acting as a B2BUA, those SIP dialog identifiers change, so connectionid can't be used the way it was meant to 💀
so when an MRB wants to act as a SIP B2BUA while handling a request from an Application Server to set up a media dialog to a Media Server, it MUST include the optional <connection-id> element in a Consumer interface response 🫶. the value has to be the equivalent of connectionid (Local Dialog Tag + Remote Dialog Tag) for the far side of the B2BUA. if it's there, that value MUST be used as the value for connectionid in packages where the Common Package Components are used. and the <connection-id> element MUST NOT be included in an HTTP Consumer interface response 🎀
it's important to point out that even though a Consumer response can return more than one Media Server instance (the MRB has assigned more than one Media Server to a Consumer request so the Application Server requirements get met), in IAMM the MRB only acts as a B2BUA with a single Media Server 👑. in that case, exactly one <media-server-address> element, describing the media dialog or CFW response, will have a <connection-id> element, and that <connection-id> element won't be included in any additional <media-server-address> elements ✨
7. Multimodal MRB Implementations 🌈
an MRB implementation can operate multimodally with a bunch of Application Server clients all sharing the same pool of media resources 🧚. that means an MRB can be running in Query mode, IAMM, and IUMM all at the same time 💅. it figures out which mode to use for any particular request from a client, based on the context of that request:
- if the received request is an HTTP POST message with
application/mrb-consumer+xmlcontent, then the MRB processes it in Query mode. - if the received request is a SIP INVITE with
application/mrb-consumer+xmlcontent andapplication/sdpcontent, then the MRB processes it in IAMM. - if the received request is a SIP INVITE without
application/mrb-consumer+xmlcontent but withapplication/sdpcontent, then the MRB processes it in IUMM.
8. Relative Merits of Query Mode, IAMM, and IUMM 💜
at a high level, the possible Application Server and MRB interactions can be sorted into these basic types:
- a. Query mode: the client is requesting the assignment by the MRB of suitable Media Server resources;
- b. IAMM/media dialog: the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a media dialog to one of the Media Servers;
- c. IAMM/Control Channel: the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a CFW Control Channel to one of the Media Servers;
- d. IUMM/media dialog: the client is requesting the establishment of a media dialog to a Media Server resource;
- e. IUMM/Control Channel: the client is requesting the establishment of a CFW Control Channel to a Media Server resource.
every type of interaction has its own pros and cons 🦋. those considerations are about how versatile the MRB can be, technical stuff like efficiency in different application scenarios, complexity, delay, working with legacy Application Servers, or working with the Media Control Channel Framework. depending on the setting an MRB is meant to support, some of those interaction types might fit better than others 🍓. this section gives a few observations on the relative merits, but it's not meant to be exhaustive, and some constraints of a given interaction type can be pretty subtle 🙈
- Operation with other types of media control: any of the types of interactions works with the mechanisms described in RFC 4240 [RFC4240] and RFC 5552 [RFC5552], where initial control instructions are conveyed in the SIP INVITE from the Application Server for the media dialog to the Media Server, and later instructions may be fetched using HTTP. Query mode (a), IAMM/media dialog (b), and IUMM/media dialog (d) work with the Media Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the Media Server Control Markup Language (MSCML) as per RFC 5022 [RFC5022].
- as stated previously, IUMM has no interface impacts on an Application Server 💖. when using IUMM, the Application Server doesn't specify the characteristics of the type of media resource it needs, because the
<mediaResourceRequest>element isn't passed to the MRB. for IUMM/media dialog (d), the MRB can work out an appropriate media resource on a best-effort basis by looking at the SIP INVITE. that includes the SDP information for the media dialog, or initial control information in the SIP Request-URI as per RFC 4240 [RFC4240]. with IUMM/Control Channel (e), there's even less information for the MRB to work with 😭 - if using IUMM/Control Channel (e), sending the media dialog to the Media Server afterwards should not be done using IUMM/media dialog. that is, the SIP signaling to send the media dialog to the selected Media Server must be directly between the Application Server and that Media Server, not through the MRB. unless resources can be confidentially identified, the MRB could send the media dialog to a different Media Server. likewise, if using IUMM/media dialog (d), setting up a Control Channel afterwards should not be done with IUMM/Control Channel (e) unless definitive information is available 🔥
- Query mode (a) and IAMM/Control Channel (c) are great for requesting a pool of media resources (like a number of IVR or conferencing ports) ahead of time and holding onto them over a period of time, whether or not there are media dialogs to those resources at any given moment. the other interaction types don't do that. this also applies when making a later request to increase or decrease the amount of resources previously awarded ✨
- Query mode (a) and IAMM/Control Channel (c) are the most versatile interaction types, but the former is completely decoupled from whether a Control Channel is used or not, while the latter requires the use of a Control Channel 🌸
- when Media Control Channel Framework Control Channels are used together with an MRB, Query mode (a) would typically result in fewer such channels being established over time than IAMM/Control Channel (c) 🧚. that's because the latter sets up an additional Control Channel every single time an Application Server has a new request for an MRB for media resources 💀
9. Examples 🎀
this section gives examples of both the Publish and Consumer interfaces, and it covers both Query mode and In-line mode 🍓
because of RFC formatting conventions, this section often splits HTTP, SIP/SDP, and CFW across lines whose content would go over 72 characters. a backslash character marks where that line folding happened. the backslash, its trailing CRLF, and the whitespace don't show up in the actual protocol contents 🙈. also, the indentation of the XML content is only there for readability: real messages follow strict XML syntax, which allows indentation but doesn't require it 💅
9.1. Publish Example 💖
the following example assumes a Control Channel has already been established and synced, as described in the Media Control Channel Framework ([RFC6230]) ✨
Figure 9 shows the subscription/notification mechanism the Publish interface is based on, as defined in Section 5.1. the MRB subscribes for information at the Media Server (message A1.), and the Media Server accepts the subscription (A2.). notifications are triggered by the Media Server (B1.) and acknowledged by the MRB (B2.) 🦋
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
Figure 9: Publish Example: Sequence Diagramthe rest of this section has a full dump of the messages for that sequence diagram, specifically:
- the subscription (A1.), in an <mrbrequest> (CFW CONTROL);
- the Media Server accepting the subscription (A2.), in an <mrbresponse> (CFW 200);
- a notification (B1.), in an <mrbnotification> (CFW CONTROL);
- the ack to the notification (B2.), in a framework-level 200 message (CFW 200).
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>600</expires>
<minfrequency>20</minfrequency>
<maxfrequency>20</maxfrequency>
</subscription>
</mrbrequest>
</mrbpublish>A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4226B2. MRB -> MS (200 to CONTROL)
CFW 03fff52e7b7a 2009.2. Consumer Examples ✨
Okay so, as Section 5.2 explains, the Consumer interface can be used in two different modes: Query and In-line aware 💅. In Query mode, Consumer messages travel inside HTTP messages, and Section 9.2.1 walks through an example of that 🌐. In In-line aware mode, the messages ride along as part of SIP negotiations instead 🎀. Since those SIP negotiations can be about setting up a Control Channel or about a User Agent Client (UAC) media dialog, there are two separate examples of that in Section 9.2.2 🦋.
9.2.1. Query Example
This example assumes the Application Server already knows the HTTP URL where an MRB is listening for Consumer messages 🧚.
Figure 10 shows the HTTP chat between the Application Server (AS, as shown in the figure) and the MRB 💌. The Application Server sends a Consumer request as the payload of an HTTP POST message (1.), and the MRB replies with an HTTP 200 OK message (2.) 🫶. The plot: the Application Server wants 100 IVR ports ✨. The MRB finds two Media Servers that can cover that, one giving 60 ports and the other giving 40, and reports both back to the Application Server 👑.
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with first MS reported by MRB |
| |
. .
. .
Figure 10: Consumer Example (Query): Sequence DiagramNext up is the full dump of every message in that sequence diagram, so you can see exactly what goes over the wire 🍓. Here's the breakdown:
- the Consumer request (1.), in a
<mediaResourceRequest>(HTTP POST, Content-Type 'application/mrb-consumer+xml'); - the Consumer response (2.), in a
<mediaResourceResponse>(HTTP 200 OK, Content-Type 'application/mrb-consumer+xml').
1. AS -> MRB (HTTP POST, Consumer request)
POST /Mrb/Consumer HTTP/1.1
Content-Length: 893
Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="gh11x23v">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>2. AS <- MRB (200 to POST, Consumer response)
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 1133
Date: Mon, 12 Apr 2011 14:59:26 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"
id="gh11x23v">
<response-session-info>
<session-id>5t3Y4IQ84gY1</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>Okay so the request and response get matched up through the id attribute (id="gh11x23v"), which is how everyone knows they belong together 🔗 The MRB also picked 9 as the random sequence number, and the Application Server has to bump it for the next request in that same session 🧚
The rest of the scenario got left out to keep things short 🙈 Once the AS gets that mediaResourceResponse, it's holding the URIs of two Media Servers that can cover its media needs 🎀 It can start a control dialog with one of them, or with both ✨
9.2.2. IAMM Examples 🦋
There are two separate IAMM examples here 🌈 IAMM has two different ways to deal with the SIP dialogs that carry Consumer messages: i) a SIP control dialog that creates a Control Channel, and ii) a UAC media dialog that attaches to a Media Server. To keep things clear, we're sending the same Consumer request from the Query mode example, so you can see how the parties behave differently 💅
9.2.2.1. IAMM Example: CFW-Based Approach 💜
This one assumes the Application Server already knows the SIP URI of an MRB, so no hunting needed 🫶
Figure 11 is the first approach: SIP transactions between the Application Server, the MRB, and one Media Server that the MRB picks out of the two allocated for the request 👑 The diagram is a bit more complex than last time 😅 Basically the MRB is acting as a B2BUA here 💅
The Application Server kicks things off with a SIP INVITE (1.) that carries a CFW-related SDP and a Consumer request, packed together as a multipart body 🎀 The MRB sends back a provisional response (2.) and gets to work ⭐ First up, it reads the Consumer request to figure out which Media Servers to use 🔍 Once it has picked the right ones (MS1 and MS2 in this example), the MRB sends a fresh SIP INVITE (3.) to one of them (MS1 here), copying over only the SDP part of the original request 🦋
MS1 negotiates that INVITE the way [RFC6230] spells out (4., 5., 6.), and hands the MRB its own CFW-related SDP ✨ Then the MRB answers the original INVITE with a SIP 200 OK carrying another multipart body (7.) 💖 That body holds the Consumer response the MRB used to pick its Media Servers, plus the SDP MS1 sent back in (5.). The AS wraps things up with an ACK (8.) and can open a CFW connection to MS1 🫶
Since the MRB handed over two Media Server instances, the AS can also grab the URI from the other <media-server-address> element inside the <mediaResourceResponse> and set up a CFW channel with MS2 too 🌸
Heads up 🙈 to make things easier to read, every multipart/mixed boundary is just =_Part, instead of the real boundary that would show up in the SIP messages.
AS MRB MS1 MS2
| | | |
| 1. INVITE | | |
| (multipart/mixed) | | |
|---------------------->| | |
| 2. 100 (Trying) | | |
|<----------------------| | |
| |--+ Extract SDP and | |
| | | MRB payloads; handle | |
| |<-+ Consumer request to | |
| | pick MSs (MS1 and MS2) | |
| | | |
| | 3. INVITE | |
| | (only copy SDP from 1.) | |
| |-------------------------->| |
| | 4. 100 (Trying) | |
| |<--------------------------| |
| | |--+ Negotiate |
| | | | CFW Control |
| | |<-+ Channel |
| | 5. 200 OK | |
| |<--------------------------| |
| | 6. ACK | |
| |-------------------------->| |
| Prepare new +--| | |
| payload with | | | |
| SDP from MS and +->| | |
| Consumer reply | | |
| | | |
| 7. 200 OK | | |
| (multipart/mixed) | | |
|<----------------------| | |
| 8. ACK | | |
|---------------------->| | |
| | | |
|--+ Read Cons. reply | | |
| | and use SDP to | | |
|<-+ create CFW Chn. | | |
| | | |
| | |
| Create TCP CFW channel towards MS1 (if needed) | |
|-------------------------------------------------->| |
| | |
|<<############## TCP CONNECTION #################>>| |
| | |
| CFW SYNC | |
|++++++++++++++++++++++++++++++++++++++++++++++++++>| |
| | |
. . . .
. . . .
| | |
| Negotiate SIP control dialog with MS2 |
|<------------------------------------------------------------------>|
| Create TCP CFW channel towards MS2 as well (if needed) |
|------------------------------------------------------------------->|
| |
|<<######################## TCP CONNECTION ########################>>|
| |
| CFW SYNC |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
| | | |
. . . .
. . . .Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram 📊
Next up is an almost-full trace of the messages from that diagram 📜 Only the important SIP messages show up (the INVITEs and the 200 OKs), and only the headers that matter stay, so Content-Type and the multipart stuff. Specifically:
- the original INVITE (1.) containing both a CFW-related SDP (Connection-Oriented Media (COMEDIA) information to negotiate a new Control Channel) and a Consumer
<mediaResourceRequest>; - the INVITE sent by the MRB (acting as a B2BUA) to the Media Server (3.), containing only the CFW-related SDP from the original INVITE;
- the 200 OK sent by the Media Server back to the MRB (5.) to complete the CFW-related negotiation (SDP only);
- the 200 OK sent by the MRB back to the Application Server in response to the original INVITE (7.), containing both the CFW-related information sent by the Media Server and a Consumer
<mediaResourceRequest>documenting the MRB's decision to use that Media Server.
1. AS -> MRB (INVITE multipart/mixed) 💌
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="pz78hnq1">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
=_Part
3. MRB -> MS (INVITE sdp only) 🧚
[..]
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0okay so this is the INVITE the MRB forwards to the Media Server, and it's giving very "here's my whole setup, please take notes" 💅 The SDP is where the CFW channel negotiation lives, so the m=application line with TCP cfw and the a=cfw-id value are the important bits 🦋 ✨
5. MRB <- MS (200 OK sdp)
[..]
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0Now the Media Server answers back 🎀 Notice it flips to a=setup:passive, keeps the same a=cfw-id:vF0zD4xzUAW9, and lists its own control packages, including mrb-publish/1.0 and msc-example-pkg/1.0 🌸 bestie, the cfw-id matching is lowkey the whole point 🫶
7. AS <- MRB (200 OK multipart/mixed)
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"
id="pz78hnq1">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
=_PartAnd here comes the big multipart reply 🌈 The first part is the SDP we just saw from MS1, and the second part is the mrb-consumer+xml body with two media-server-address entries, one per Media Server, both with their own rtp-codec settings 💜 Honestly it's so organised I'm obsessed.
As the previous example illustrates, the only difference in the response that the MRB provides to the Application Server is in the connection-id attribute that is added to the first allocated Media Server instance ✨ This is how the Application Server knows the MRB sent the CFW channel negotiation to that specific Media Server, and which connection-id it should use, which is the one provided 🧚 This will be described in more detail in the following section for the media dialog-based approach, so stay tuned, bestie 🍓
The continuation of the scenario (the Application Server connecting to MS1 to start the Control Channel and the related SYNC message, the Application Server connecting to MS2 as well later on, all the media dialogs being attached to either Media Server) is omitted for brevity 🙈 We're skipping ahead, but it's still giving main character energy in the full story 👑
9.2.2.2. IAMM Example: Media Dialog-Based Approach ✨
okay so this example assumes the interested Application Server already knows the SIP URI of an MRB 🫶
Figure 12 shows the second approach, which is SIP-based transactions between a SIP client, the Application Server, the MRB, and the Media Server that the MRB picks 🦋 The vibe is basically the same as the previous examples (like the multipart body contents), but now there's a new party in the chat, so the diagram is a little more complex. As before, the MRB acts as a B2BUA 💅 A UAC sends a SIP INVITE to a SIP URI handled by the Application Server, because it's interested in its services (1.). The Application Server sends a provisional response (2.). Since it doesn't have the resources yet, it sends a new SIP INVITE to the MRB (3.) containing both the UAC media-related SDP and a Consumer request (multipart body) 🎀 The MRB sends a provisional response to the Application Server (4.) and starts working on the request. First, it uses the Consumer request from the Application Server to figure out which Media Servers should be chosen 🔥 Once the Media Server is chosen, the MRB sends a new SIP INVITE to one of the Media Servers, including the SDP part of the original request (5.).
The Media Server negotiates this INVITE as specified in [RFC6230] (6., 7., 8.) to allocate the needed media resources to handle the new media dialog. Eventually it gives the MRB its own media-related SDP 🌸 The MRB replies to the original Application Server INVITE with a SIP 200 OK that has a multipart body (9.). This multipart body includes the Consumer response from the MRB, which says which Media Servers were chosen, plus the SDP returned by the Media Server in (7.). The Application Server finally acknowledges the 200 OK (10.) and wraps things up by eventually giving the UAC the SDP it needs to set up the RTP channels with the chosen Media Server ✨ A separate direct SIP control dialog may be started by the Application Server to the same Media Server, so it can set up a Control Channel to manipulate the media dialog 🧚
As with the IAMM/Control Channel example in the prior section, this example has the MRB selecting Media Server resources across two Media Server instances 👑 The convention could be that the MRB sent the SIP INVITE to the first Media Server in the list given to the Application Server in the Consumer response information. For brevity, the stuff about connecting to the other Media Servers is left out, since we already covered it in the previous section 🍓
Please note that to make the protocol contents easier to read, a simple =_Part is used whenever a boundary for a multipart/mixed payload is given, instead of the real boundary that would be inserted in the SIP messages 💜
UAC AS MRB MS
| | | |
| 1. INVITE | | |
| (media SDP) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed) | |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (only copy SDP from 3.) |
| | |-------------------------->|
| | | 6. 100 (Trying) |
| | |<--------------------------|
| | | +--|
| | | Handle media dialog | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | |<--------------------------|
| | | 8. ACK |
| | |-------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed) | |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Cons. reply | |
| | | and send SDP | |
| |<-+ back to UAC | |
| 11. 200 OK | | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
|<<*************************** RTP *******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| | |
| | Create TCP CFW channel towards MS (if needed) |
| |-------------------------------------------------->|
| | |
| |<<############## TCP CONNECTION #################>>|
| | |
| | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram
The rest of this section has a trace of the messages that go with the sequence diagram above 🔍 Only the relevant SIP messages are shown (both the INVITEs and the 200 OKs), and only the relevant headers are kept for brevity (Content-Type, From/To, and multipart-related information). Specifically:
- the original INVITE (1.) with the media-related SDP sent by a UAC;
- the INVITE sent by the AS to the MRB (3.), containing both the media-related SDP and a Consumer
<mediaResourceRequest>; - the INVITE sent by the MRB (acting as a B2BUA) to the Media Server (5.), containing only the media-related SDP from the original INVITE;
- the 200 OK sent by the Media Server back to the MRB (7.) to complete the media-related negotiation (SDP only);
- the 200 OK sent by the MRB back to the Application Server in response to the original INVITE (9.), containing both the media-related information sent by the Media Server and a Consumer
<mediaResourceRequest>documenting the MRB's decision to use that Media Server; - the 200 OK sent by the Application Server back to the UAC so it can set up the RTP channel(s) with the Media Server (11.).
1. UAC -> AS (INVITE with media SDP)
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 983. AS -> MRB (INVITE multipart/mixed)
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="ns56g1x0">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
=_Part5. MRB -> MS (INVITE sdp only)
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 987. MRB <- MS (200 OK sdp)
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca29. AS <- MRB (200 OK multipart/mixed) ✨
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>;tag=117652221
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"
id="ns56g1x0">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
=_Part11. UAC <- AS (200 OK sdp) ✨
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2Okay so look at the examples, bestie 🧚 As in the IAMM/Control Channel example, the MRB hands the Application Server a <media-server-address> element in the Consumer response 💜 The uri attribute tells you exactly which Media Server the MRB sent the SDP media negotiation to 🎯, and the connection-id lets the Application Server tell the Media Server which dialog between the MRB and Media Server it's looking at 🫶. This attribute is needed because, according to the framework specification [RFC6230], the connection-id is built out of the From/To tags of the dialog between the MRB and Media Server 💅. The MRB acts as a B2BUA in this scenario, so without that attribute the Application Server just doesn't know the relevant tags 😭, and then the CFW protocol can't work the way it's supposed to 💀.
The continuation of the scenario (the Application Server connecting to the Media Server to start the Control Channel, the SYNC message, etc.) is omitted for brevity. 🌸
10. Media Service Resource Publisher Interface XML Schema ✨
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/mrb-publish+xml" format 🎀
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package.
The schema namespace is urn:ietf:params:xml:ns:mrb-publish
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the framework attributes for
conferenceid and connectionid.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC 5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP-LEVEL ELEMENT: mrbpublish
#####################################################
-->
<xsd:complexType name="mrbpublishType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mrbrequest" />
<xsd:element ref="mrbresponse" />
<xsd:element ref="mrbnotification" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbpublish" type="mrbpublishType" />
<!--
#####################################################
mrbrequest TYPE
#####################################################
-->
<!-- mrbrequest -->
<xsd:complexType name="mrbrequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbrequest" type="mrbrequestType" />
<!-- subscription -->
<xsd:complexType name="subscriptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="minfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="maxfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:attribute name="action" type="action.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" />
<!--
#####################################################
mrbresponse TYPE
#####################################################
-->
<!-- mrbresponse -->
<xsd:complexType name="mrbresponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbresponse" type="mrbresponseType" />
<!--
#####################################################
mrbnotification TYPE
#####################################################
-->
<!-- mrbnotification -->
<xsd:complexType name="mrbnotificationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="media-server-id"
type="subscriptionid.datatype"/>
<xsd:element ref="supported-packages" minOccurs="0" />
<xsd:element ref="active-rtp-sessions" minOccurs="0" />
<xsd:element ref="active-mixer-sessions" minOccurs="0" />
<xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
<xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
<xsd:element ref="media-server-status" minOccurs="0" />
<xsd:element ref="supported-codecs" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="dtmf-support" minOccurs="0" />
<xsd:element ref="mixing-modes" minOccurs="0" />
<xsd:element ref="supported-tones" minOccurs="0" />
<xsd:element ref="file-transfer-modes" minOccurs="0" />
<xsd:element ref="asr-tts-support" minOccurs="0" />
<xsd:element ref="vxml-support" minOccurs="0" />
<xsd:element ref="media-server-location" minOccurs="0" />
<xsd:element ref="label" minOccurs="0" />
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="subscriptionid.datatype"
use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbnotification" type="mrbnotificationType" />okay so the schema goes brr here 💅✨ every supported-* thing is basically a little list of what the server can do, and each type extends Tcore and tacks on a catch-all ##other slot for extensions 🦋
<!-- supported-packages -->
<xsd:complexType name="supported-packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="package" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-packages" type="supported-packagesType"/>
<xsd:complexType name="packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="package" type="packageType" />
<!-- active-rtp-sessions -->
<xsd:complexType name="active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- active-mixer-sessions -->
<xsd:complexType name="active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mixer-sessions"
type="active-mixer-sessionsType" />
<xsd:complexType name="active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attributeGroup ref="fw:framework-attributes" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mix" type="active-mixType" />
<!-- non-active-rtp-sessions -->
<xsd:complexType name="non-active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-rtp-sessions"
type="non-active-rtp-sessionsType" />
<!-- non-active-mixer-sessions -->
<xsd:complexType name="non-active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="non-active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mixer-sessions"
type="non-active-mixer-sessionsType" />
<xsd:complexType name="non-active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="available" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mix" type="non-active-mixType" />
<!-- media-server-status -->
<xsd:element name="media-server-status" type="msstatus.datatype" />
<!-- supported-codecs -->
<xsd:complexType name="supported-codecsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codecs" type="supported-codecsType" />
<xsd:complexType name="supported-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec" type="supported-codecType" />
<xsd:complexType name="supported-codec-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-action" type="actions.datatype"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec-package"
type="supported-codec-packageType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="supported-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-format" type="supported-formatType" />
<xsd:element name="supported-file-package"
type="xsd:string" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- dtmf-support --><xsd:complexType name="dtmf-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="detect" /> <xsd:element ref="generate" /> <xsd:element ref="passthrough" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="dtmf-support" type="dtmf-supportType" />
<xsd:complexType name="detectType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="dtmf.datatype" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="audio-mixing-modes" minOccurs="0" maxOccurs="1" /> <xsd:element ref="video-mixing-modes" minOccurs="0" maxOccurs="1" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="audio-mixing-mode" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="video-mixing-mode" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="vas" type="boolean.datatype" default="false" /> <xsd:attribute name="activespeakermix" type="boolean.datatype" default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- supported-tones -->
<xsd:complexType name="supported-tonesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="supported-country-codes" minOccurs="0" maxOccurs="1" /> <xsd:element ref="supported-h248-codes" minOccurs="0" maxOccurs="1" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="supported-tones" type="supported-tonesType" />
<xsd:complexType name="supported-country-codesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="country-code" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="supported-country-codes" type="supported-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="supported-h248-codesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="h248-code" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="supported-h248-codes" type="supported-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" /> <!-- file-transfer-modes -->
<xsd:complexType name="file-transfer-modesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="file-transfer-mode" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="file-transfer-modes" type="file-transfer-modesType" />
<xsd:complexType name="file-transfer-modeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="transfermode.datatype" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
<!-- asr-tts-support -->
<xsd:complexType name="asr-tts-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="asr-support" minOccurs="0" maxOccurs="1" /> <xsd:element ref="tts-support" minOccurs="0" maxOccurs="1" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
<xsd:complexType name="asr-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="language" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="language" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute ref="xml:lang" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- media-server-location -->
<xsd:complexType name="media-server-locationType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="civicAddress" type="ca:civicAddress" minOccurs="1" maxOccurs="1" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:element name="media-server-location" type="media-server-locationType" />
okay bestie, the vxml bits and the whole DATATYPES crew are up next 💅✨
<!-- vxml-support -->
<xsd:complexType name="vxml-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="support" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- label -->
<xsd:element name="label" type="label.datatype" />
<!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- encryption -->
<xsd:complexType name="encryptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption" type="encryptionType" />
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="msstatus.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="active" />
<xsd:enumeration value="deactivated" />
<xsd:enumeration value="unavailable" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="create" />
<xsd:enumeration value="update" />
<xsd:enumeration value="remove" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="transfermode.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>11. Media Service Resource Consumer Interface XML Schema ✨
this section is where we drop the full XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] for the "application/mrb-consumer+xml" format 💖🎀
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB Consumer interface.
The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC 5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP-LEVEL ELEMENT: mrbconsumer
#####################################################
-->
<xsd:complexType name="mrbconsumerType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mediaResourceRequest" />
<xsd:element ref="mediaResourceResponse" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbconsumer" type="mrbconsumerType" />
<!--
#####################################################
mediaResourceRequest TYPE
#####################################################
-->
<!-- mediaResourceRequest -->
<xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="generalInfo" minOccurs="0" />
<xsd:element ref="ivrInfo" minOccurs="0" />
<xsd:element ref="mixerInfo" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceRequest"
type="mediaResourceRequestType" />
<!--
#####################################################
generalInfo TYPE
#####################################################
-->
<!-- generalInfo -->
<xsd:complexType name="generalInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generalInfo" type="generalInfoType" />
<!-- session-info -->
<xsd:complexType name="session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="session-info" type="session-infoType" />
<!-- packages -->
<xsd:complexType name="packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="package" type="xsd:string" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="packages" type="packagesType"/>
<!--
#####################################################
ivrInfo TYPE
#####################################################
-->
<!-- ivrInfo -->
<xsd:complexType name="ivrInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ivr-sessions" minOccurs="0" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="dtmf-type" minOccurs="0" />
<xsd:element ref="tones" minOccurs="0" />
<xsd:element ref="asr-tts" minOccurs="0" />
<xsd:element ref="vxml" minOccurs="0" />
<xsd:element ref="location" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="file-transfer-modes" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivrInfo" type="ivrInfoType" />
<!--
#####################################################
mixerInfo TYPE
#####################################################
-->
<!-- mixerInfo -->
<xsd:complexType name="mixerInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:element ref="file-formats" minOccurs="0"/>
<xsd:element ref="dtmf-type" minOccurs="0"/>
<xsd:element ref="tones" minOccurs="0"/>
<xsd:element ref="mixing-modes" minOccurs="0"/>
<xsd:element ref="application-data" minOccurs="0"/>
<xsd:element ref="location" minOccurs="0"/>
<xsd:element ref="encryption" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixerInfo" type="mixerInfoType" />
<!--
#####################################################
mediaResourceResponse TYPE
#####################################################
-->okay bestie, this is where the mediaResourceResponse schema comes in and it's giving structure 🎀✨
<!-- mediaResourceResponse -->
<xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="response-session-info" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceResponse"
type="mediaResourceResponseType" />
<!--
####################################################
ELEMENTS
####################################################
-->
<!-- response-session-info -->
<xsd:complexType name="response-session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="response-session-info"
type="response-session-infoType" />
<!-- media-server-address -->
<xsd:complexType name="media-server-addressTYPE">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="connection-id" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="ivr-sessions" minOccurs="0"/>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="uri" type="xsd:anyURI" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-address"
type="media-server-addressTYPE" />
<!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="required-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-format" type="required-formatType" />
<xsd:complexType name="required-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="required-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-file-package"
type="required-file-packageType" />
<!-- dtmf-type -->
<xsd:complexType name="dtmfType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf" type="dtmfType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />okay the tones bit is next and it's giving country codes and H.248 codes 🧚💜
<!-- tones -->
<xsd:complexType name="required-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tones" type="required-tonesType" />
<xsd:complexType name="required-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-codes"
type="required-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="required-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-codes"
type="required-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />last bit of this batch: the asr-tts schemas 🎤💖 speech recognition and text-to-speech, literally so iconic
<!-- asr-tts -->
<xsd:complexType name="asr-ttsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts" type="asr-ttsType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />okay the schema keeps going and it's giving organized 🎀✨
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- vxml -->
<xsd:complexType name="vxmlType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml" type="vxmlType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="require" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- location -->
<xsd:complexType name="locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="location" type="locationType" />
<!-- encryption -->
<xsd:complexType name="encryptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption" type="encryptionType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- file-transfer-modes -->
<xsd:complexType name="file-transfer-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="file-transfer-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-modes"
type="file-transfer-modesType" />
<xsd:complexType name="file-transfer-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="transfermode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
<!-- mixers -->
<xsd:complexType name="mixerssessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixers" type="mixerssessionsType" />
<xsd:complexType name="mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="users" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mix" type="mixType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="transfermode.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="remove" />
<xsd:enumeration value="update" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
</xsd:schema>12. Security Considerations 🔐✨
Okay bestie, this section is SERIOUS 😭 but we're still gonna make it cute 🎀. The MRB network entity has two main interfaces, Publish and Consumer. Both carry sensitive info, so they NEED proper protection 🫶
The Publish interface, as defined in and described in Section 5.1, uses the Media Control Channel Framework [RFC6230] to connect an MRB to a Media Server. It's super important that the communication between the MRB and the Media Server is secured 🔒. If a malicious entity changes or even deletes subscriptions to a Media Server, the MRB ends up with a wrong view of what resources the Media Server actually has 💀. That can lead it to pick the wrong server when an Application Server asks for media resources. It gets worse, too: a malicious entity could manipulate the available resources on a Media Server so the MRB thinks there's nothing available at all 😱. Since the Publish interface is a CFW Control Package, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between an MRB and a Media Server 🦋.
The Publish interface also lets a Media Server, as explained in Section 5.1.5.18, share more or less accurate info about its geographic location 🌍. This could be useful if Application Servers want to find services near them at an MRB. Using this info is totally optional, and how much detail to share is up to the implementation 🍓. Still, the security issues that come with disclosing these addresses are a big deal, so draw attention to them! MRB implementations should NOT hand this info over as is to interested Application Servers 🙅♀️. They should only use those addresses inside computation algorithms that pick the most adequate resources Application Servers are looking for.
Oops, I wrote "NOT" in caps there, and that's not in the original, so let me fix it. Here's the correct version of that last bit: MRB implementations should make sure they don't disclose this info as is to interested Application Servers 🙅♀️. They should only use those addresses inside computation algorithms that pick the most adequate resources Application Servers are looking for.
The Consumer interface, as defined in and described in Section 5.2, is built around transactions based on a session ID 📝. These transactions can be carried either over HTTP messages or SIP dialogs. This means malicious users could disrupt or manipulate an MRB session if they have access to that session ID (or can replicate it somehow) 😈. For example, a malicious entity could change an existing session between an Application Server and the MRB. It could request fewer resources than originally asked for, which would cause media dialogs to be rejected by the Application Server. Or it could request way more resources to lock up as many (if not all) of the resources an MRB can provide. Then other legitimate Application Servers couldn't get any in later requests 🥲. To prevent this, MRB implementations are strongly advised to generate session identifiers that are very hard to replicate ✨. That way, the chances of malicious users getting valid identifiers just by guessing or through brute-force attacks stay low. It's also very important to secure how these identifiers are transported by the parties involved, in both requests and responses. That stops network attackers from intercepting Consumer messages and grabbing session IDs 👀. The Consumer interface uses either the Hypertext Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) so clients can connect to an MRB and request media resources. When HTTP is used, any binding using the Consumer interface MUST be capable of being transacted over Transport Layer Security (TLS), as described in RFC 2818 [RFC2818] 🔐. When SIP is used, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between a client requesting media resources and an MRB 💅.
Now, what if a valid session ID gets compromised anyway? Like, it's intercepted or a malicious user just guesses it 😬? As an extra layer of protection, the Consumer interface also uses a sequence number in its transactions. This sequence number increases after each successful transaction. It starts from a first value that the MRB randomly generates when the session is first created, and it must match in every request/response. Yes, this adds complexity, because implementations have to pay close attention to those sequence numbers. If the values are wrong, you'll get Wrong sequence number errors and the related requests will fail 😤. But it's an important added value for security, no cap 🧢. Different transactions tied to the same session could be transported in different, unrelated HTTP messages (or in SIP INVITEs when In-line mode is used). This sequence number protection lowers the chances of session replication or disruption, especially when the session ID has been compromised. In other words, it should be harder for malicious users to manipulate or remove a session they got the session ID for 🛡️. It is strongly advised that the MRB doesn't choose 1 as the first sequence number for a new session. It should pick a random value to start from instead 🎲. How to react to out-of-sequence transactions is left up to MRB implementations. There's a related error code available, but implementations may also decide to enforce further limitations or actions. For example, they could do that after receiving too many failed attempts in a row, or after what looks like blatant attempts to guess the current, valid sequence number 🚨.
It's also worth noting that in In-line mode (both IAMM and IUMM), the MRB may act as a Back-to-Back User Agent (B2BUA) 🔁. When it acts as a B2BUA, the MRB may modify SIP bodies. The IAMM does this when handling multipart/mixed payloads, for instance. That affects the ability to use any SIP security feature that protects the body (for example, RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as a mediator for the security association 🙈. Keep this in mind when implementing an MRB compliant with this specification 📌.
Both the Publishing interface and the Consumer interface can address the location of a Media Server. The Publishing interface can be used to tell the MRB where a Media Server is located, approximately or precisely 📍. The Consumer interface can be used to ask for a Media Server located somewhere in a particular region (for example, a conference bridge close to San Francisco 🌉). Both Media Server and MRB implementers need to think about this when deciding whether or not to make this location info available. If they do, they also need to figure out how many bits of information really need to be made available for brokering purposes 🧠.
Let's talk authorization, because it matters too 👑. Neither the Publishing interface nor the Consumer interface provides an explicit means for implementing authentication. In other words, they don't have specific protocol interactions that make sure authorized Application Servers can use the services an MRB instance provides. But since both interfaces are carried over well-established protocols (HTTP, SIP, CFW), support for this can be expressed through the authentication mechanisms those protocols already provide 🫧. So any MRB-aware entity (Application Servers, Media Servers, MRBs themselves) MUST support HTTP and SIP Digest access authentication 🔑. Using Digest access authentication is recommended, not mandatory, which means MRB-aware entities MAY use it in deployment 🎀.
An MRB may want to enforce extra constraints on interactions between an Application Server or Media Server and an MRB 💫. For example, it may choose to only accept requests tied to a specific session ID if they come from the IP address that sent the first request 🕵️♀️. Or it may just use pre-shared certificates to check the identity of legitimate Application Servers and/or Media Servers 🦋.
13. IANA Considerations 📋
There are several IANA considerations tied to this specification 💅.
13.1. Media Control Channel Framework Package Registration
This section registers a brand new Media Control Channel Framework package, following the instructions in Section 13.1 of [RFC6230] 🌸. Here's the registration:
Package Name: mrb-publish/1.0
Published Specification(s): RFC 6917
Person and email address to contact for further information: IETF
MediaCtrl working group (mediactrl@ietf.org), Chris Boulton
(chris@ns-technologies.com).13.2. application/mrb-publish+xml Media Type
Next up is the media type registration for the Publish side ✨:
To: application
Subject: Registration of media type application/mrb-publish+xml
Type name: application
Subtype name: mrb-publish+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: See Section 10 of RFC 3023 [RFC3023] and
Section 12 of RFC 6917.
Interoperability considerations: none.
Published specification: Section 10 of RFC 6917.
Applications that use this media type: This media type is used to
support a Media Resource Broker (MRB) entity.
Additional Information:
Magic Number: None
File Extension: .xdf
Macintosh file type code: "TEXT"
Person and email address to contact for further information: Chris
Boulton (chris@ns-technologies.com).
Intended usage: COMMON
Author/Change controller: The IETF.13.3. application/mrb-consumer+xml Media Type
And the Consumer side gets its own media type registration 🎀:
To: application
Subject: Registration of media type application/mrb-consumer+xml
Type name: application
Subtype name: mrb-consumer+xml
Mandatory 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: See Section 10 of RFC 3023 [RFC3023] and
Section 12 of RFC 6917.
Interoperability considerations: none.
Published specification: Section 11 of RFC 6917.
Applications that use this media type: This media type is used to
support a Media Resource Broker (MRB) entity.
Additional Information:
Magic Number: None
File Extension: .xdf
Macintosh file type code: "TEXT"
Person and email address to contact for further information: Chris
Boulton (chris@ns-technologies.com).
Intended usage: COMMON
Author/Change controller: The IETF.13.4. URN Sub-Namespace Registration for mrb-publish
IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish" 🦋. The schema of the XML namespace named urn:ietf:params:xml:ns:mrb-publish is in Section 10.
13.5. URN Sub-Namespace Registration for mrb-consumer
IANA has registered the URN "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer" 🌈. The schema of the XML namespace named urn:ietf:params:xml:ns:mrb-consumer is in Section 11.
13.6. XML Schema Registration for mrb-publish
IANA has registered the schema for mrb-publish 🧚:
URI: urn:ietf:params:xml:schema:mrb-publish
ID: mrb-publish
Filename: mrb-publish
Registrant Contact: IETF MediaCtrl working group
(mediactrl@ietf.org)
Schema: The XML for the schema is in Section 10 of this document.13.7. XML Schema Registration for mrb-consumer ✨
Okay bestie, last one for this section 💅 We need to register the schema for mrb-consumer, and it goes like this:
URI: urn:ietf:params:xml:schema:mrb-consumer
ID: mrb-consumer
Filename: mrb-consumer
Registrant Contact: IETF MediaCtrl working group
(mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document.14. Acknowledgements 🫶
Huge shoutout to the Publish Interface design team, who gave super valuable input on this document 🌸 The team was Adnan Saleem, Michael Trank, Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors also want to thank John Dally, Bob Epley, Simon Romano, Henry Lum, Christian Groves, and Jonathan Lennox for their input on this spec. You all are iconic 👑
Ben Campbell did the RAI expert review on an early version of this spec and gave a ton of invaluable input. Literally couldn't have done it without him 🦋
15. References 📚
15.1. Normative References
These are the big, must-read ones 🤓
[ISO.10646.2012]
International Organization for Standardization,
"Information technology -- Universal Coded Character Set
(UCS)", ISO Standard 10646, 2012.
[ISO.3166-1]
International Organization for Standardization, "Codes for
the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard
3166-1:2006, 2006.
[ISO.639.2002]
International Organization for Standardization, "Codes for
the representation of names of languages -- Part 1:
Alpha-2 code", ISO Standard 639, 2002.
[ITU-T.Q.1950]
International Telecommunication Union, "Bearer independent
call bearer control protocol", ITU-T Recommendation
Q.1950, December 2002.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[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.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.15.2. Informative References
These ones are good for background vibes 🌈
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
Services", RFC 5552, May 2009.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230, May 2011.
[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework", RFC 6231, May 2011.
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and
'Profiles' Parameters for "Bucket" Media Types", RFC 6381,
August 2011.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, March 2012.
[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework",
RFC 6505, March 2012.Authors' Addresses 🎀
Chris Boulton
NS-Technologies
EMail: chris@ns-technologies.com
Lorenzo Miniero
Meetecho
Via Carlo Poerio 89
Napoli 80100
Italy
EMail: lorenzo@meetecho.com
Gary Munson
AT&T
200 Laurel Avenue South
Middletown, New Jersey 07748
USA
EMail: gamunson@gmail.com📦 where this page comes from
- ietf: rfc6917 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms