RFC 6504
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 💖
okay bestie, let's start with the title block tea ☕✨ This is RFC 6504, part of the IETF's Request for Comments series, which is the official paper trail for how Internet protocols get defined 🌐. It's Informational, so it's published for information and is not a standards track spec 🫶. It was written by M. Barnes (Polycom), L. Miniero (Meetecho), R. Presta, and S P. Romano (University of Napoli) 👑, and it's dated March 2012. Its ISSN is 2070-1721. The title block doesn't list anything this RFC obsoletes or updates, so it doesn't change any other RFC 🦋.
Abstract 📜
this doc gives detailed call flows for the scenarios in the Framework for Centralized Conferencing (XCON) (RFC 5239) and the XCON scenarios (RFC 4597) 🎀. The call flows show how a conference control client and a conference control server talk to each other through the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The goal is to give protocol researchers and developers detailed examples they can actually reference 💅.
Status of This Memo 🎀
this is not an Internet Standards Track specification. It's published for informational purposes 💖.
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧚.
For the latest status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6504 ✨.
Copyright Notice 🌸
Copyright (c) 2012 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 stood on the date of publication. Please read them carefully, because they explain your rights and restrictions for this document 🫶. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🔥.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview ........................................................4
4. Working with CCMP ...............................................4
4.1. CCMP and the Data Model ....................................5
4.2. Using HTTP/TLS as a Transport ..............................6
4.3. Conference Notifications ..................................10
5. Conference Creation ............................................11
5.1. Basic Conference Creation .................................12
5.2. Conference Creation Using Blueprints ......................16
5.3. Conference Creation Using User-Provided Conference
Information ...............................................23
5.4. Cloning an Existing Conference ............................28
6. Conference Users Scenarios and Examples ........................31
6.1. Adding a Party ............................................32
6.2. Muting a Party ............................................35
6.3. Conference Announcements and Recordings ...................38
6.4. Monitoring for DTMF .......................................41
6.5. Entering a Password-Protected Conference ..................42
7. Sidebars Scenarios and Examples ................................44
7.1. Internal Sidebar ..........................................45
7.2. External Sidebar ..........................................54
7.3. Private Messages ..........................................60
7.4. Observing and Coaching ....................................64
8. Removing Participants and Deleting Conferences .................71
8.1. Removing a Party ..........................................71
8.2. Deleting a Conference .....................................74
9. Security Considerations ........................................75
10. Acknowledgements ..............................................76
11. References ....................................................76
11.1. Normative References .....................................76
11.2. Informative References ...................................761. Introduction ✨
this doc gives detailed call flows for the scenarios in the Framework for Centralized Conferencing (XCON) [RFC5239] and the XCON scenarios [RFC4597] 💅. The XCON scenarios cover a huge range of use cases that use the advanced conferencing features an XCON framework system can offer 🌈. The call flows show the interface between a conference control client and a conference control server, which talk through the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] 🎀.
Because XCON has so much functionality and CCMP messaging is so flexible, these call flows should not be considered a complete list of everything an XCON framework or its protocol implementations can do 🙈. They're a sample that gives protocol developers, software developers, and researchers a taste of how feature-rich XCON and CCMP are 🦋.
2. Terminology 💜
this doc uses the same terminology as the Architectural Framework for Media Server Control [RFC5567] and the Media Control Channel Framework Call Flow Examples [CALL-FLOWS], plus the terms and abbreviations listed below for the call flows 📚. Heads up: "call flows" is used in a very generic way here, because the media isn't limited to voice. The calls XCON and CCMP support can include text, voice, and video, and even several media types in one active conference 🎬.
Conference and Media Control Client (CMCC): this is defined in the XCON framework 🧚. In these flows, the CMCC is logically the same as a User Agent Client (UAC), which is the client notation used in the media control call flows [CALL-FLOWS]. What makes a CMCC different from a generic media client is that it's XCON-aware, so it can also issue CCMP requests 💖.
Conference Server (ConfS): in this doc, "conference server" is used interchangeably with "Application Server (AS)" from the media control architectural framework [RFC5567] 🌸. A conference server is meant to act as a conference control server, as the XCON framework defines it. That means it can handle CCMP requests and send CCMP responses ✨.
Media Server (MS): this is defined in the media control architectural framework [RFC5567] 🔥.
3. Overview 🧚
this doc samples detailed call flows that can be built on an XCON framework system [RFC5239] and a CCMP implementation [RFC6503] 🦋. Think of it as a simple guide to how the conference control protocol works between the conference server and the conference control client 💖. The goal is to give protocol developers, software developers, and researchers an informational reference 🫶.
This doc focuses on the back-and-forth between the conference and media control client and the conferencing system, which means the conference server 👑. The scenarios are based on the XCON framework, and many of them build on the advanced conferencing features from the XCON scenarios. Some new scenarios were added to show other real-life uses the framework is expected to support 🌈. Apart from one starter example with media control messaging, the examples don't cover the media control [RFC6505], call signaling, or Binary Floor Control Protocols (BFCPs) [RFC4582] 🙈. Instead, this doc points to the scenarios in the media control call flows [CALL-FLOWS], SIP call control conferencing [RFC4579], and the BFCP documents 💅.
Here's how the rest of the doc is laid out 🗺️. Section 4 gives an overview of CCMP, plus some implementation details and related topics like HTTPS transport and notifications ✨. Section 5 shows the different ways CCMP can create a new conference 🎀. Section 6 covers the different user-related changes CCMP can make, through a bunch of interesting scenarios 🌸. Section 7 looks at scenarios that may involve sidebars 🦋. Section 8 shows how CCMP can remove conferences and users from the system 💜. Last, Section 9 covers a few security considerations for implementing CCMP 🔥.
4. Working with CCMP 💖
this section gives a quick intro to how the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] works and how it gets carried across a network 🎀. It describes a typical CCMP interaction, focusing on the important parts of the client-server communication ✨. Heads up: this section assumes you've already read and understood the CCMP document 📚. It's here to help you understand the actual protocol interactions 🧠.
First, Section 4.1 describes the protocol itself, including some implementation considerations 🌈. In Section 4.2, you'll see an effective CCMP interaction that uses HTTPS as the transport 🫶. Finally, Section 4.3 describes notifications 🦋.
After that, the document presents and describes some real flows in detail in the sections that follow 👑.
4.1. CCMP and the Data Model
bestie, CCMP is an protocol based on XML 💅 [W3C.REC-xml-20081126]. It's a request/response protocol, and it is completely stateless, which means implementations can handle each transaction independently of the others 🧚
The protocol lets you manipulate conference objects and their related users ✨ A conference and media control client (called CMCC from here on 💖) can create, update, and remove pretty much everything tied to the objects a conferencing system handles. That's reflected in the allowed operations (retrieve, create, update, delete) and in the request types, which range from blueprints and conferences all the way to users and sidebars. For instance, CCMP gives you ways to:
- retrieve the list of registered and/or active conferences in the system;
- create new conferences by exploiting several different approaches;
- add/remove users to/from a conference;
- update a conference with respect to all of its aspects;
and so on 🌸
Here's the thing though: CCMP is the tool for manipulating conference objects, but it does not define what those objects are 🙈 A separate document spells out how a conference object and all its components have to be built (Conference Information Data Model for Centralized Conferencing (XCON) [RFC6501]). Depending on the request type and operation, CCMP carries pieces of conference objects (or whole objects) that follow that spec. So any implementation that wants to be CCMP-compliant has to make sure the transported objects are fully compliant with the data model and consistent with its constraints 🎀 Some elements are mandatory in a conference object, and a syntactically correct CCMP request carrying a wrong conference object is doomed to fail 💀 That's why implementers are encouraged to take special care when checking the data model handlers, so they don't make potential mistakes.
BUT, there are cases where a mandatory element in the data model can't be filled in by a CCMP user 😭 For example, a CMCC might be requesting the direct creation of a new conference. In that case, a conference object needs an 'entity' attribute that uniquely identifies the conference, and the CMCC has no way of knowing in advance what that entity will be, because the ConfS generates it after the request. For scenarios like this one, CCMP describes a dedicated placeholder wildcard (i.e., "AUTO_GENERATE_X", where X is an integer) so the conference object still complies with the data model. The ConfS then swaps the wildcard out for the right value 🦋
4.2. Using HTTP/TLS as a Transport
Okay, the transport part is so simple, it's giving clean 🫶 CCMP requires that implementations support HTTP/TLS as the transport mechanism. In practice, a CMCC sends a request as part of an HTTPS POST message, and the ConfS replies with a 200 OK HTTPS response. In both directions, the HTTPS messages carry the CCMP messages as their payload, which is reflected in the Content-Type header (application/ccmp+xml). Figure 1 shows a ladder diagram of this interaction, followed by a dump of the exchanged HTTPS messages for further analysis. The examples in the rest of this document only show the CCMP interactions ✨
CMCC ConfS
| |
| 1. HTTPS POST (CCMP request) |
|--------------------------------------------->|
| |
| |--+ Parse request,
| | | update object
| |<-+ and reply
| |
| 2. 200 OK (CCMP response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | update local copy |
|<-+ of conference object |
| |
' '
' '
Figure 1: CCMP on HTTPSLooking at the protocol dump, the CMCC sent a CCMP request (a blueprintRequest message asking for a blueprint retrieval, i.e., with the <operation> element set to "retrieve" ) to the ConfS 🍓 The request rode as the payload of an HTTPS POST (message 1.) to a previously known location. The mandatory Host header is there, and the Content-Type header is set correctly as well (application/ccmp+xml) ✅
The ConfS handled the request and replied accordingly 🌈 The response (a blueprintResponse message with a <response-code> set to a successful value, "200") came back as the payload of a 200 OK HTTPS response (message 2.). Once again, the Content-Type header is set correctly (application/ccmp+xml) 💜
1. CMCC -> ConfS (HTTPS POST, CCMP request)
------------------------------------------
POST /Xcon/Ccmp HTTP/1.1
Content-Length: 657
Content-Type: application/ccmp+xml
Host: example.com:443
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. CMCC <- ConfS (200 to POST, CCMP response)
---------------------------------------------
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/ccmp+xml;charset=ISO-8859-1
Content-Length: 1652
Date: Thu, 04 Feb 2010 14:47:56 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description>
<info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count>
<info:available-media>
<info:entry label="audioLabel">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm
</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Now for the juicy details of the interaction 🎀 Even though the request is simple, this flow still shows how CCMP messages are built 💖 Both the CCMP request and the CCMP response share a subset of elements:
<confUserID>: this element, provided by the CMCC, identifies the requester by their XCON-USERID; except in a few scenarios (presented in the following sections), this element must always contain a valid value;<confObjID>: this element identifies the target conference object, according to the request in place;<operation>: this element specifies the operation the CMCC wants to perform, according to the specific request type.
On top of those, the CMCC (let's say Alice, whose XCON-USERID is "xcon-userid:Alice@example.com") also included an extra element, <blueprintRequest>. The name of that element changes with the request type the CMCC is after 🦋 Here, the CMCC wanted details about one specific blueprint (identified by its XCON-URI "xcon:AudioRoom@example.com", as shown in the <confObjID> target element), so the request was just an empty <blueprintRequest> element. It'll get clearer in the next sections that different request types may need different elements and therefore different content ✨
Since the request was a blueprintRequest message, the ConfS replied with a blueprintResponse message containing a <blueprintResponse> element. That element holds a complete dump of the conference object (compliant with the data model) describing the requested blueprint 🌸
Without going into more detail, this was the simplest CCMP exchange that can happen between a CMCC and a ConfS: a blueprint request. We'll dig into this scenario more in Section 5.2 🫶
4.3. Conference Notifications ✨
okay so the XCON framework [RFC5239] lists a bunch of different ways a conference server and a conferencing client can talk to each other 💬. One of those is called the "notification protocol," and it's basically the group chat ping system 🔔. Every client that wants to know when something relevant happens in a conference gets told by the server. When SIP is the call signaling protocol in a CCMP implementation, the XCON event package [RFC6502] must be supported 🫶. It extends the SIP event package for conference state [RFC4575], so it's very nested and very iconic 💅.
A SIP client uses a SIP SUBSCRIBE message for the XCON event package to subscribe to notifications about one specific conference 📨. After that, it gets every change to the document through a SIP NOTIFY message. Figure 2 shows an example. A CMCC has updated a conference object, and a SIP client that subscribed earlier gets notified about the update 🦋.
CMCC ConfS UAC
| | |
| | 1. SIP SUBSCRIBE |
| |<--------------------------|
| Handle +--| |
| new | | |
| subscription +->| 2. SIP 200 OK |
| |-------------------------->|
| | |
' ' '
' ' '
| | |
| 3. CCMP (add user) | |
|---------------------->| |
| |--+ Add user |
| | | to conf. |
| |<-+ object |
| 4. CCMP (success) | |
|<----------------------| |
| | 5. SIP NOTIFY (changes) |
| |-------------------------->|
| | 6. SIP 200 OK |
| |<--------------------------|
| | |
' ' '
' ' '
Figure 2: XCON Event Package: SIP NotificationsThe detailed flows in this document generically show a notification when it's appropriate 🌸, but they skip the SIP messaging details. Think of them as the highlight reel, not the full director's cut 🎬.
5. Conference Creation ✨
okay this section is where the fun starts 🎀. It covers all the different ways a conference can be created using CCMP and the XCON framework constructs. Like we said before, the media control, call signaling, and floor control details are annotated right in the flows where they apply, without showing every single message. The same goes for CCMP. Its flows only cover the protocol itself and hide any transport detail that might be in use (for example, HTTPS) 🧚. For clarity, though, the first example in Section 5.1 spells out the media control messaging using the standard annotation that gets used through the rest of this document. After that, the later flows only include that annotation (marked with lowercase letters), and you're encouraged to check the call flows in the relevant documents for the details of the other protocols 📚. The call signaling annotations sit on the left side of the conference server vertical bar, and the media control annotations sit on the right side 💜.
5.1. Basic Conference Creation
the simplest way to create a conference is for the client to send a confRequest message to the conference server with the <operation> element set to "create" as the only parameter 🍓. The client also includes the <confUserID> that belongs to the requesting client itself. The server then creates a default conference and returns everything in the confResponse message: an XCON-URI in the form of the <confObjID> element, the XCON-USERID in the form of the <confUserID> element (the same one that was already in the request), and the data for the conference object in the <confInfo> parameter 🎉. This example also adds the issuing user to the conference at creation time, using the 'method' attribute in the <target> child element of <allowed-users-list>, set to "dial-out" 📞.
The conference object data comes back in the <confInfo> parameter of the confResponse message. This lets the client (if it's authorized) change that data, add more participants, and update the data during the conference 👑. The client can also share the conferencing information with other participants so they can join, and those details come up in additional flows. Please notice that, according to the CCMP specification, getting the new conference data back in the <confInfo> element is not mandatory 🙈. If the <confInfo> parameter of is not included in the successful confResponse/create message, the client can send a subsequent confRequest/retrieve message for the returned <confObjID> to get the detailed conference description.
Clients that aren't XCON-aware can still join the conference over a specific signaling interface, such as SIP [RFC3261] (using the signaling interface to the conference focus described in [RFC4579]), or another supported signaling protocol 🦋. XCON doesn't care which one they use, and those details aren't shown in the message flows. Instead, the flows mark the points where this signaling happens with lowercase letter items (i.e., (a)...(x)), along with the matching text for what the conference server does while processing it ✨.
As mentioned before, this example also shows how the conferencing system can use other standard protocol components to be fully functional 💅. One example is the media control framework [RFC5567], which lets the conferencing system configure conference mixes, Interactive Voice Response (IVR) dialogs, and all sorts of media-related interactions an application like this might need 🎧. To show what those interactions look like, the conference server in this example also configures and starts a mixer over a media control channel as soon as the conference is created (transactions A1 and A2). It also attaches clients to that mixer when needed. For example, when CMCC1 joins the conference through SIP signaling, its media channels get attached to the media server (MS) in B1/B2 🌈. The media control interfaces are NOT shown in the remaining call flows in this document. They follow the same annotation scheme as the SIP signaling, so (b) lines up with the A1 and A2 transactions, and (d) lines up with the B1 and B2 transactions.
CMCC1 CMCC2 CMCCx ConfS MS
| | | | |
|(1)confRequest(confUserID, create) | |
|-------------------------------------->| |
| | (a)Create +---| |
| | |Conf | | |
| | |Object | | |
| | |& IDs +-->| |
| | | | A1. CONTROL |
| | | |+++++++++++>>|
| | | |(create conf)|--+ (b)
| | | | | | create
| | | | | | conf and
| | | | A2. 200 OK |<-+ its ID
| | | |<<+++++++++++|
| | | |(confid=Y) |
|(2)confResponse(confUserID,confObjID, | |
| create, 200, success, | |
| version, confInfo) | |
|<--------------------------------------| |
| | | | |
| | (c) Focus +---| |
| | sets up | | |
| | signaling | | |
| | to CMCC1 +-->| |
| | | | |
| | | | B1. CONTROL |
| | | |+++++++++++>>|
| | | | (join CMCC1 |
| | | | <->confY) |
| | | | |
| | | | |--+(d) join
| | | | | | CMCC1 &
| | | | B2.200 OK |<-+ conf Y
| | | |<<+++++++++++|
| | | | |
|<<#################################################>>|
| Now the CMCC1 is mixed in the conference |
|<<#################################################>>|
| | | | |
|******CMCC1 may then manipulate conference data *****|
|****** and add addt'l users, etc. | *****|
' ' ' ' '
' ' ' ' '
' ' ' ' '
Figure 3: Create Basic Conference - Complete flow1. confRequest/create message (Alice creates a default conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>- confResponse/create message ("success", created conference object returned) 🎀✨
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
Default conference initiated by Alice
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>
xcon:8977794@example.com
</info:uri>
<info:display-text>
Conference XCON-URI
</info:display-text>
</info:entry>
</info:conf-uris>
<info:maximum-user-count>10
</info:maximum-user-count>
<info:available-media>
<info:entry label="11">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
<xcon:allowed-users-list>
<xcon:target uri="xcon-userid:Alice@example.com"
method="dial-out"/>
</xcon:allowed-users-list>
</info:users>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 4: Create Basic Conference Detailed Messaging
5.2. Conference Creation Using Blueprints ✨
Okay so, the previous example was all about making a conference with default values 💅. That means Alice didn't tell the server anything about how she wanted it set up. XCON (and CCMP, as a consequence) supports templates, which are called "conference blueprints". A blueprint is basically a conference object with predefined settings already filled in 🧚. So a client can grab a list of blueprints, pick the one that fits its needs best, and use that blueprint to create a brand new conference.
Figure 5 shows Alice discovering the conference blueprints on a conferencing system and then creating a conference from the one she likes 🎬. She's specifically into blueprints that can do a video conference, which means both audio and video are available. So she uses the CCMP filter mechanism to make a selective blueprints retrieve request. This turns into three separate CCMP transactions. Iconic multi-step energy 👑.
CMCC Alice ConfS
| |
| (1) blueprintsRequest |
| (confUserID,xpathFilter) |
|------------------------------>|
| |
| (2) blueprintsResponse |
| (confUserID, |
| 200, success, |
| blueprintsInfo) |
| |
|<------------------------------|
| |
|--+ |
| | choose preferred |
| | blueprint from the |
| | list (blueprintName) |
|<-+ |
| |
| (3) blueprintRequest |
| (confUserID,confObjID, |
| retrieve) |
|------------------------------>|
| |
| 4) blueprintResponse |
| (confUserID,confObjID,|
| retrieve, 200, |
| success, confInfo) |
|<------------------------------|
| |
| (5) confRequest(confUserID, |
| confObjID,create) |
|------------------------------>|
| |
| (a)Create +---|
| Conf | |
| Object | |
| & IDs +-->|
| |--+ (b) MS
| | | creates
| | | conf and
| |<-+ its ID
| | (confid=Y)
|(6) confResponse |
| (confUserID, confObjID*, |
| create, 200, success) |
|<------------------------------|
| |
| |
| |
' '
' 'Figure 5: Client Creation of Conference Using Blueprints
- Alice kicks things off by sending a blueprintsRequest message to the conference server, which she finds through the conference server discovery process 🔍. The request has the <confUserID> set to Alice's XCON-USERID (the one issuing the request). It also has an <xpathFilter> element where Alice says she only wants blueprints that support both audio and video 🎥. The xpath query in that field is:
/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']. When the conference server gets the blueprintsRequest, it first checks the <confUserID> to make sure Alice has the right authority, based on system policies, to receive the kind of blueprints the system supports. Gatekeeping, but make it cute 🔒. - Every blueprint that Alice is allowed to use gets returned in a blueprintsResponse message, inside the <blueprintsInfo> element 📋.
- Once Alice gets the blueprintsResponse with the blueprints in it, she decides which one to use for the conference she's making 💖. Then she sends a blueprintRequest message to get that specific blueprint, identified by its <confObjID>.
- The conference server sends back the details for the blueprint identified by <confObjID>, inside the <confInfo> element of the blueprintResponse message ✨.
- Last step for Alice: she sends a confRequest message with a "create" <operation> to the conference server, asking it to create a conference reservation that clones the blueprint she picked 🫶. She does this by putting the blueprint's XCON-URI in the <confObjID> parameter.
- When the conference server gets the confRequest/create message, it uses the blueprint to clone a conference and allocates a new XCON-URI (called "confObjID*" in the example) 🌈. Then it sends a confResponse message with the new "confObjID*", tied to the newly created conference instance, as the value of the <confObjID> parameter. Once Alice gets that confResponse, she can finally add other users to the conference 🥳.
1. blueprintsRequest message (Alice requires the list of the available blueprints with video support) 🎥
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:blueprintsRequest>
<xpathFilter>/conference-info[conference-description/
available-media/entry/type='audio'
and
conference-description/available-media/entry/type='video']
</xpathFilter>
</ccmp:blueprintsRequest>
</ccmpRequest>
</ccmp:ccmpRequest>2. blueprintsResponse message (the server provides descriptions of the available blueprints fitting Alice's request) 📚
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
4 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri>
<info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference
where both audio and video are available,
only one user can talk
</info:purpose>
</info:entry>
</blueprintsInfo>
</ccmp:blueprintsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>3. blueprintRequest/retrieve message (Alice wants the "VideoRoom" blueprint) 💜
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>4. blueprintResponse/retrieve message ("VideoRoom" conference object returned) 🌸
Okay so the blueprint response is literally the cutest little config bundle 🎀 It gives the whole VideoRoom setup: the name, the max of 4 users, audio and video, join handling, and the floor policy. Here's the rest of it:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:VideoRoom@example.com">
<info:conference-description>
<info:display-text>VideoRoom</info:display-text>
<info:maximum-user-count>4</info:maximum-user-count>
<info:available-media>
<info:entry label="audioLabel">
<info:type>audio</info:type>
</info:entry>
<info:entry label="videoLabel">
<info:type>video</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm
</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioFloor">
<xcon:media-label>audioLabel</xcon:media-label>
</xcon:floor>
<xcon:floor id="videoFloor">
<xcon:media-label>videoLabel</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>5. confRequest/create message (Alice clones the "VideoRoom" blueprint 🧚)
Now Alice wants her very own copy of VideoRoom, so she sends a create request that points at the blueprint. Obsessed with the cloning energy 💜
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>6. confResponse/create message (cloned conference object returned 🦋)
And the server says yes ✨ This is the moment: the cloned conference object comes back with its own brand new ID, a password, and the same media and floor setup. Iconic 💅
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
New conference by Alice cloned from VideoRoom
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>
xcon:8977794@example.com
</info:uri>
<info:display-text>
conference xcon-uri
</info:display-text>
<xcon:conference-password>
8601
</xcon:conference-password>
</info:entry>
</info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count>
<info:available-media>
<info:entry label="11">
<info:type>audio</info:type>
</info:entry>
<info:entry label="12">
<info:type>video</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>
confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="1">
<xcon:media-label>11</xcon:media-label>
</xcon:floor>
<xcon:floor id="2">
<xcon:media-label>12</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 6: Create Conference (Blueprint) Detailed Messaging 🌈
5.3. Conference Creation Using User-Provided Conference Information ✨
okay so there's another way to make a conference 💅 a client (Alice, in this example) can send a confRequest with the "create" <operation> and bring her own data in a <confInfo> element. The request also includes the <confUserID>, set to the XCON-USERID of the requesting entity 🫶
this is giving total control, bestie 🎀 Alice can describe exactly what the conference object should look like, without relying on defaults or blueprints. she can pick which media is available, the topic, who's allowed to join, scheduling stuff, all of it 🧚 she just sends a full conference object and the server parses it.
ok real talk 📋 the <confInfo> has to follow the data model spec, which means the 'entity' attribute is mandatory and can't be missing from the document. but the conference doesn't exist yet, so Alice doesn't know what its entity should be 🙈 that's where Section 4.1 comes in. CCMP lets you use a wildcard placeholder ("xcon:AUTO_GENERATE_1@example.com" in this example). it's only there to keep the <confInfo> compliant, and the conference server swaps it out for the real value 🦋 when the server actually creates the conference, it gets a valid 'entity' value, and that replaces the wildcard in the conference object Alice provided.
to give you a flavor, Alice also wants scheduling info ⏰ so she adds a <conference-time> element to the <confInfo>. the conference happens on a certain date, from a certain start time to a certain stop time, and it gets replicated weekly 🌸
then Alice uses the <allowed-users-list> element to say that at the start time, Bob, Carol, and herself should get called by the conferencing system to join 📞 (yes, she's calling herself too 💀). for each <target> matching one of those clients, the 'method' attribute is set to "dial-out" 💖
once Alice sends it, the request creates a conference as long as the conferencing system can support that type of conference (capabilities, etc.) 🔥 we'll assume it worked. the response gives back the XCON-URI in the <confObjID> and the XCON-USERID in the <confUserID> (same as the requester again 👑) inside the confResponse message.
the created conference object isn't sent back in the <confInfo> of that successful confResponse 👀 but Alice can still grab it by sending a confRequest with a "retrieve" <operation> on the XCON-URI from the <confObjID> of the previous response 🔍 when she does, the 'entity' in the <confInfo> has been swapped for the real one ("xcon:6845432@example.com") ✨ glow-up unlocked.
Alice Bob Carol ConfS
| | | |
| | | |
|(1)confRequest(confUserID, | |
| create, confInfo) | |
| | | |
|-------------------------------------->|
| | | |
| | (a)Create +---|
| | |Conf | |
| | |Object | |
| | |& IDs +-->|
| | | |--+ (b) MS
| | | | | creates
| | | | | conf and
| | | |<-+ its ID
| | | | (confid=Y)
|(2)confResponse(confUserID,| |
| confObjID, create, | |
| 200, success, version) |
|<--------------------------------------|
| | | |
===========================================
... ... ... ...
========== START TIME OCCURS ==============
| | (c) Focus +---|
| | sets up | |
| | signaling | |
| | to Alice +-->|
| | | |
| | | |--+(d) MS joins
| | | | | Alice &
| | | |<-+ conf Y
| | | |
| | | |
|<<###################################>>|
| Alice is mixed in the conference |
|<<###################################>>|
| | | |
| | (e)Focus +---|
| | sets up | |
| | signaling | |
| | to Bob | |
| | | +-->|
| | | |
| | | |--+(f)MS joins
| | | | | Bob &
| | | |<-+ conf Y
| | | |
| |<<###################>>|
| | Bob is mixed too |
| |<<###################>>|
| | | |
| | (g )Focus +---|
| | sets up | |
| | signaling | |
| | to Carol | |
| | CMCCx +-->|
| | | |
| | | |--+(h)MS joins
| | | | | CMCCx &
| | | |<-+ conf Y
| | | |
| | |<<#######>>|
| | |Carol mixed|
| | |<<#######>>|
| | | |
| | | |
| | | |
|<***All parties connected to conf Y***>|
| | | |
| | | |
' ' ' '
' ' ' '
' ' ' 'Figure 7: Create Basic Conference from User-Provided Conference Info
- confRequest/create message (Alice proposes a conference object to be created)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest>
<confInfo entity="xcon:AUTO_GENERATE_1@example.com">
<info:conference-description>
<info:display-text>
Dial-out conference initiated by Alice
</info:display-text>
<info:maximum-user-count>10</info:maximum-user-count>
<info:available-media>
<info:entry label="AUTO_GENERATE_2">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
<xcon:conference-time>
<xcon:entry>
<xcon:base>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML
Mozilla Calendar V1.0//EN
BEGIN:VEVENT
DTSTAMP: 20100127T140728Z
UID: 20100127T140728Z-345FDA-alice@example.com
ORGANIZER:MAILTO:alice@example.com
DTSTART:20100127T143000Z
RRULE:FREQ=WEEKLY
DTEND: 20100127T163000Z
END:VEVENT
END:VCALENDAR
</xcon:base>
<xcon:mixing-start-offset
required-participant="moderator">
2010-01-27T14:29:00Z
</xcon:mixing-start-offset>
<xcon:mixing-end-offset
required-participant="participant">
2010-01-27T16:31:00Z
</xcon:mixing-end-offset>
<xcon:must-join-before-offset>
2010-01-27T15:30:00Z
</xcon:must-join-before-offset>
</xcon:entry>
</xcon:conference-time>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
<xcon:allowed-users-list>
<xcon:target uri="xcon-userid:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:bob83@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
</xcon:allowed-users-list>
</info:users>
</confInfo>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>- confResponse/create message ("200", "success")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 8: Create Basic Conference Detailed Messaging
5.4. Cloning an Existing Conference ✨
A client can also make a brand new conference by cloning one that already exists, like an active conference or a conference reservation 💅. This is basically the blueprint move from before, except instead of copying the preset settings in a blueprint, you copy the settings of a conference that's already sitting there 🦋.
In this example, the client sends a confRequest message with the create <operation>, along with her XCON-USERID in the <confUserID> element and the XCON-URI of the conference to be cloned in the <confObjID> element 🎀.
An example of how a client can create a conference based on a blueprint is in Section 5.2. How a client might find out about a conference reservation or active conferences is similar to the first step of the blueprint example, except that it asks for different types of conference objects supported by the specific conferencing system 🔍. For instance, in this example, the client clones a conference reservation (i.e., an inactive conference) 🌸.
If the conferencing system can support a new instance of the specific type of conference (capabilities, etc.), then the request results in the creation of a conference. It gets an XCON-URI in the form of a new value in the <confObjID> parameter, which reflects the newly cloned conference object returned in the confResponse message 💜.
Alice ConfS
| |
|(1)confRequest(confUserID, |
| confObjID, create) |
|------------------------------>|
| (a)Create +---|
| Conf | |
| Object | |
| & IDs +-->|
| |--+ (b) MS
| | | creates
| | | conf and
| |<-+ its ID
| | (confid=Y)
| |
|(2)confResponse(confUserID, |
| confObjID*,create, |
| 200, success, |
| version, confInfo) |
| |
|<------------------------------|
| |
' 'Figure 9: Create Basic Conference - Clone
- Alice, a conferencing system client, sends a confRequest message to clone a conference based on an existing conference reservation 🙌. Alice indicates this conference should be cloned from the specified parent conference, which is represented by the XCON-URI in the
<confObjID>provided in the request. - When the confRequest message arrives with a
create<operation>and the XCON-URI in the<confObjID>mentioned above, the conference server checks that the received XCON-URI is valid 🕵️. The conference server works out the appropriate read/write access for any users to be added to a conference based on this XCON-URI (using membership, roles, etc.) 👑. The conference server uses the received<confObjID>to clone a conference reservation. It also reserves or allocates a new XCON-URI (called "confObjID*" in Figure 9) for the cloned conference object ✨. This new identifier is, of course, different from the one tied to the conference being cloned, since it represents a different conference object 😭. Any later protocol requests from any of the members of the conference must use this new identifier 🫶. The conference server keeps track of the mapping between this conference ID and the parent conference object ID associated with the reservation through the conference instance. This mapping is explicitly shown in the<cloning-parent>element of the<conference-description>in the new conference object 💅.
1. confRequest/create message (Alice clones an existing conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>2. confResponse/create message (created conference object returned)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
New conference by Alice cloned from 6845432
</info:display-text>
<info:maximum-user-count>10</info:maximum-user-count>
<info:available-media>
<info:entry label="11">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
<xcon:cloning-parent>
xcon:6845432@example.com
</xcon:cloning-parent>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
<xcon:allowed-users-list>
<xcon:target uri="sip:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:bob83@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
</xcon:allowed-users-list>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>
confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="1">
<xcon:media-label>11</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 10: Create Basic Conference (Clone) Detailed Messaging
6. Conference Users Scenarios and Examples 🌈
Section 5 showed the different ways a conference might be created using CCMP 🎉. This section is all about user-related scenarios, i.e., the typical things that happen during a conference's lifetime, like adding new users and handling their media 🧚. The following scenarios are based on those documented in the XCON framework. The examples assume that a conference has already been correctly established, with media, if applicable, following one of the examples in Section 5 💜.
6.1. Adding a Party
okay bestie 💖 so in this example Alice wants to add Bob to a conference that's already up and running 🎀. We're assuming Bob is a brand new user of the system, which means Alice also has to share some details about him 🫶. Bob already being a user is way easier, and we'll get to that later ✨.
Alice Bob
CMCC1 CMCC2 CMCCx ConfS
| | | |
|(1) userRequest(confUserID,| |
| confObjID, create, | |
| userInfo) | | |
|-------------------------------------->|
| | | |
| | (a) Create +---|
| | | Bob | |
| | | as a | |
| | | user +-->|
| | | |
|(2) userResponse(confUserID, confObjID |
| create, 200, success, userInfo) |
|<--------------------------------------|
| | | |
| | | (b) Focus |
| | | sets up |
| | | signaling |
| | | to Bob |
| |<----------------------|
| | | |
| | | (c) Notify|
| | | ("Bob just|
| | | joined") |
| | |<----------|
| | | |
' ' ' '
' ' ' '
' ' ' 'Figure 11: Client Manipulation of Conference - Add a Party
- Alice sends a userRequest message with an operation of "create" to add Bob to the specific conference, the one identified by the XCON-URI in the <confObjID> 📨. The "create" <operation> also makes sure Bob gets created as a user across the whole conferencing system 🌸. To do that, the request includes a <userInfo> element describing Bob as a user. That's needed so the conferencing system knows Bob's characteristics 🧚. If Bob was already a registered user, Alice would just reference him through his XCON-USERID in the 'entity' attribute of the <userInfo> field, without giving any extra data 💅. That data (including, for instance, Bob's SIP-URI to be used later for dial-out) would be pulled from his existing registration 🔥. The conference server checks that Alice has the right authority under the policies attached to that specific conference object before doing the operation 👑. Like we already saw, a new XCON-USERID gets created for Bob, and the <userInfo> is used to update the conference object 🦋. As already seen in Section 5.3, a placeholder wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP messages below) goes in the 'entity' attribute of the <userInfo> element, and it gets swapped for the real XCON-USERID later 🎀;
- Bob gets successfully added to the conference object, and he's allocated an XCON-USERID ("xcon-userid:Bob@example.com") 🥳. This identifier comes back in the response as the value of the 'entity' attribute of the returned <userInfo> 💜;
- In this example, the call signaling to add Bob to the conference also goes through the focus 📞. As noted before, this is implementation specific 🌈. A conferencing system might do different things after creating the user, or it might do nothing at all 🙈. Among the possible actions, for instance, Bob may be added as a <target> element to the <allowed-users-list> element, and his joining 'method' may be either "dial-in" or "dial-out" ⭐. Out-of-band notification mechanisms can get involved too, e.g., emailing Bob about the new conference with details like the date, password, expected participants, and so on (see Section 4.3) 💌.
Once Bob has been successfully added to the specified conference, the state gets updated, and depending on the policies, other participants (Bob included) may be told about his addition through the conference notification service in use 🔔✨.
1. userRequest/create message (Alice adds Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>2. userResponse/create message (a new XCON-USERID is created for Bob and he is added to the conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>10</version>
<ccmp:userResponse>
<userInfo entity="xcon-userid:Bob@example.com">
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text>
</info:endpoint>
</userInfo>
</ccmp:userResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 12: Add Party Message Details 🎀
6.2. Muting a Party
okay so this section is all about muting someone in a conference that's already live 🎧🤫 we assume the person has already been added, and it only covers muting, not unmuting, because unmuting would basically be the exact same CCMP message flow anyway 💅 if any external floor control is involved, the conferencing system has to think about whether a given client can actually mute or unmute itself 🌸
interaction between CCMP and floor control needs real thought 🧠 handling CCMP-based and BFCP-based media control is like layers 🎀 a participant might have the BFCP floor granted but still be muted through CCMP. in that case they're still muted in the conference, and they only get unmuted if both protocols allow it 🙈
Figure 13 shows one client, Alice, changing the media state of another client, Bob 🦋 this example assumes an established conference. Alice is the moderator of the conference, and she wants to mute Bob in a medium-sized multi-party conference 📞 his device isn't muted (and he's clearly not listening to the call 💀), and the background noise in his office is disrupting everyone. BFCP floor control is assumed not to be involved here.
Muting can be done with the <mute> control element tied to the target user's audio, in which case the conference server has to update the settings for that user's media streams ✨ muting and unmuting can also be done by directly changing the settings for the target user's media streams, and that's the approach this example takes 🫶 specifically, Bob's <userInfo> gets updated by changing the <endpoint> element inside the <media> part for audio, which is identified by the 'id' attribute. setting the audio <status> to "recvonly" is how muting happens 🔇
Alice Bob
CMCC1 CMCC2 CMCCx ConfS MS
| | | | |
|(1) userRequest(subject, | | |
| confUserID,confObjID, | | |
| update,userInfo) | | |
| | | | |
|--------------------------------------->| |
| | | | Mute Bob |
| | | |----------------->|
| | | | 200 OK |
| | | |<-----------------|
| | | | |
| |<====== XXX Bob excluded from mix XXX ====>|
| | | | |
| | (a) Update +---| |
| | Bob in | | |
| | data model | | |
| | (muted) +-->| |
| | | | |
| (2)userResponse(confUserID,confObjID, | |
| update,200,success,version) | |
|<---------------------------------------| |
| | | | |
| | | (b) Notify | |
| | | ("Bob is | |
| | | muted") | |
| | |<-----------| |
| | | | |
' ' ' ' '
' ' ' ' '
' ' ' ' 'Figure 13: Client Manipulation of Conference - Mute a Party
1. Alice sends the request 📨 Alice sends a userRequest message with an "update" <operation>, and her <userInfo> has the <status> field in the <media> element for Bob's <endpoint> set to "revconly". to prove she's really her 🔐, Alice puts her registration credentials (her username and password) in the <subject> request parameter. the <subject> parameter is optional: it can be used all the time when the conference server wants to authenticate every requester 👑 in those cases, if the client doesn't include the required authentication info, the conferencing server replies with a CCMP "authenticationRequired" <response-code>, which says the request can't be processed without the proper <subject> parameter 🙅♀️ the conference server checks that Alice has the right authority based on the policies attached to that specific conference object 💅 it recognizes that Alice is allowed to make this change because she's the moderator of the target conference, so it updates the <userInfo> in the conference object to show that Bob's media is not to be mixed with the conference media 🤫 if the conference server depends on a remote media server for its multimedia functions, it then changes Bob's media profile to match, using the related protocol interaction with the MS 🎬 an example of one way to handle this with the media server control architecture [RFC5567] is in Figure 31, "Simple Bridging: Framework Transactions (2)", in [CALL-FLOWS] 📚
2. Alice gets a response 🥳 a userResponse message with a "200" <response-code> ("success") goes back to Alice. depending on the policies, the conference server may notify other participants (including Bob) about this update through any conference notification service that's in use 📢 bestie, this is so iconic 🦋
- userRequest/update message (Alice mutes Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<subject>
<username>Alice83</username>
<conference-password>13011983</conference-password>
</subject>
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>- userResponse/update message (Bob has been muted)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>7</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 14: Mute Message Details
6.3. Conference Announcements and Recordings ✨
Okay bestie, this section is about the stuff every conferencing system needs, like public announcements (a voice saying "someone just joined!") and name recording. It's not strictly CCMP-related, since the CCMP signaling is the same as in Section 6.1 😌, but it's super fun to watch several XCON-compliant pieces work together to make it happen 🦋.
Here's the vibe: Alice wants into Bob's conference, but it's passcode-protected 🔐. Once she enters the passcode, an announcement asks her to say her name so it can be recorded 🎙️. When she's added to the active conference, that recording plays back for everyone already in the call. A very similar example is in Figure 33 of [CALL-FLOWS] 💜.
Figure 15 is the whole story in one picture 👀
CMCC Alice ConfS MS
| | |
|(1)userRequest(confObjID, | |
| create,userInfo) | |
|--------------------------->| |
| |--+ Alice is |
| | | new in the |
| |<-+ system (create |
| | confUserID) |
| ConfS handles +--| |
| SIP signaling | | |
| (Alice<->ConfS<->MS) +->| |
| | |
| |--+ A password is |
| | | required for |
| |<-+ that conference |
| | |
| | Request IVR menu (PIN) |
| |--------------------------->|
| | |
|<========= MS gets PIN from Alice through DTMF =========>|
| | |
| | Provided PIN is... |
| |<---------------------------|
| Check +--| |
| PIN | | |
| +->| |
| |--+ Alice must |
| | | record her |
| |<-+ name |
| | |
| | Request name recording |
| |--------------------------->|
| | |
|<========= MS records Alice's audio RTP (name) =========>|
| | |
| | Audio recording |
| |<---------------------------|
| Complete +--| |
| creation | | |
| of Alice +->| |
| | |
| | |
| (2)userResponse(confUserID,| |
| confObjID,create,200,| |
| success,version) | |
|<---------------------------| |
| | |
' ' '
Figure 15: Recording and AnnouncementsThe step-by-step tea ☕
- Once the conference server gets Alice's userRequest to join Bob's conference, it figures out that this specific conference needs a password 🔑. So it sends back an announcement asking Alice to enter it. Typical IVR functionality can handle this part 📞. After Alice types it in, the password gets checked against the policies tied to Bob's active conference ✅. Then the conference server hooks up with a server that prompts and records Alice's name 🎤. It also has to check whether Alice is already a user of this system or a brand-new one 🧐. Here she's new, so a fresh XCON-USERID gets created for her 🆕. Using the contact info she gave, the call signaling to add her gets kicked off through the focus 📲.
- The conference server sends Alice a userResponse message, and the <confUserID> holds the XCON-USERID the system just gave her 🪪. That's what lets her do stuff with the conference later (if her policies allow it), like registering for event notifications 🔔. Once the call signaling says she's successfully in, and the state updates, other people like Bob get told about her joining through the conference notification service 🎉. Depending on the policies, an announcement also plays for everyone in the call saying she's joined 📢.
1. userRequest/create message (a new conferencing system client, Alice, enters Bob's conference) 💌
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>2. userResponse/create message (Alice gets a shiny new XCON-USERID and is added to the conference) 🎀
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>5</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 16: Announcement Messaging Details 🌸
6.4. Monitoring for DTMF 🎹
Conferencing systems also need to keep an ear out for dual-tone multi-frequency (DTMF) from each participant 👂. This is usually how people punch in the identifier and/or access code to join a specific conference 🔢. It's also a go-to trick for letting non-XCON-aware user agents talk to the system, like using DTMF tones to get muted or unmuted 🔇🔊.
Figure 15 shows DTMF monitoring inside the framework elements 🧩. The media control architecture and protocols [RFC5567] can be used by the conference server for all the DTMF interactions 💅. And if you want examples of DTMF interception in conference instances, check out [CALL-FLOWS] 🦋.
6.5. Entering a Password-Protected Conference 🔐
okay so some conferences are lowkey locked down 🔒 and need a password before you can join, update, or delete stuff over CCMP. the password goes in the <conference-password> element inside the right <conference-uris> entry of the conference data model 🗝️. then whoever's sending the CCMP request has to put that same password in the <conference-password> field of the request aimed at that conference. no password, no entry, periodt 💅
here's a walkthrough where Alice, a conferencing system client, tries to join a password-protected conference 🎀
- Alice sends a userRequest with a "create"
<operation>to add herself to the conference with XCON-URI "xcon:8977777@example.com" (written in the<confObjID>parameter). She gives her XCON-USERID in the<confUserID>field and skips<userInfo>because she's joining herself (first-party join) 🙋♀️. on this first try she doesn't include any password at all. - when the conference server gets that userRequest/create, it notices the conference can't be joined without the right passcode 🚫. so it sends Alice a userResponse with a "423"
<response-code>("conference password required") to say her join got refused and she needs to send it again with the password if she wants in 😭. - Alice gets the passcode through some out-of-band method 🤫, puts it in the
<conference-password>field of a brand new userRequest/create, and sends that back to the server ✨. - the server checks the password, lets Alice into the protected conference, and sends her a userResponse with a "200"
<response-code>("success") 🎉🥳.
1. userRequest/create message (Alice tries to enter the conference without providing the password)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>2. userResponse/create message ("423", "conference password required")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>423</response-code>
<response-string>conference password required</response-string>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>3. userRequest/create message (Alice provides the password)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<conference-password>8601</conference-password>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>4. userResponse/create message (Alice has been added to the conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>10</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 17: Password-Protected Conference Join Messages Details 🧁
7. Sidebars Scenarios and Examples ✨
okay now it's giving sidebars 🧚. while creating conferences and managing users and their media covers a lot of situations 💖, sometimes things get more complicated, and there may be cases that need more advanced management 🌈.
the big one here is sidebars 🫶. a sidebar is basically a child conference 👶, usually holding a subset of the parent conference's participants and a subset of its media too. people usually want sidebars when some participants need a private chat without disrupting the main conference 🤫💬.
this section covers some typical sidebar scenarios like whispering, private messaging, and coaching 🦋. the first subsections show how a generic sidebar can be created, configured, and managed 🔥.
7.1. Internal Sidebar ✨
okay so picture this 💖 Alice is in an active conference with Bob and Carol, and she wants a little side chat with Bob while still watching the video from the main call 📺. Her other option is keeping the main conference audio playing at a lower volume 🔉. To make the sidebar, Alice sends a request to the ConfS to create a conference reservation based on the active conference object 🎀. Alice and Bob stay on the main conference roster, so everyone else can still see that they're part of the main call while the internal sidebar is happening 👀. Bob, meanwhile, decides he doesn't want the conference audio in the background at all (not even quieter, like Alice set it up) 🙈 so he edits the sidebar to make that stream inactive for him. Iconic behaviour, honestly 💅
Alice Bob ConfS
| | |
|(1) sidebarByValRequest(confUserID, |
| confObjID,create) |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-val | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByValResponse(confUserID, | (parent mapping
| (confObjID*,create,200,success, | conf<->sidebar)
| version,sidebarByValInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByValRequest |
| (confUserID, confObjID*, |
| update,sidebarByValInfo) |
|--------------------------------------------->|
| | |
| | (b) Update +---|
| | sidebar-by-val | |
| | (media, users | |
| | etc.) +-->|
| | | Sidebar is
| | | modified
|(4) sidebarByValResponse(confUserID, |
| confObjID*, update, |
| 200, success, version) |
|<---------------------------------------------|
| | |
| |(5) userRequest |
| | (confUserID', |
| | confObjID*, |
| | update,userInfo)|
| |---------------------->|
| | |
| | (c) Update +---|
| | user settings | |
| | (Bob's media) | |
| | +-->|
| | | Sidebar is modified
| | | (original audio
| | | inactive for Bob)
| |(6) userResponse |
| | (confUserID', |
| | confObjID*, |
| | update, 200, |
| | success,version) |
| |<----------------------|
| | |
' ' '
' ' '
' ' '
Figure 18: Client Creation of a Sidebar Conference- Once the CCMP sidebarByValRequest message comes in asking for a new sidebar based on the conference whose XCON-URI is in the
<confObjID>from the request, the conference server uses that XCON-URI to clone a conference reservation for the sidebar 🧚 The sidebar reservation is NOT independent of the active main conference (i.e., parent) 👑 The conference server also allocates a brand new XCON-URI ("confObjID*" in Figure 18) for that sidebar, to be used for any later protocol requests from any of the members of the conference 💜 The new XCON-URI gets sent back in the<confObjID>parameter of the response message 🎀 - The relationship info lives in the sidebarByValResponse message, specifically in the
<sidebar-parent>element 🦋 There's also a full dump of the main/parent conference below, so you can see how the cloning for the sidebar could go down 🌸 - Once Alice gets the sidebarByValResponse for the reservation, she can turn it into an active conference or make more reservations based on the existing ones ✨ In this example, Alice only wants Bob in the sidebar, so she edits the membership so just the two of them show up in the
<allowed-users-list>section 🫶 She also wants both the audio and the video from the original conference available in the sidebar 📺 For the sidebar's own media, the audio should be restricted to the sidebar participants (that's Bob and Alice) 🤫 And Alice tweaks the media values so she gets the main conference audio at a reduced volume, so her chat with Bob isn't drowned out 🔉 She sends a sidebarByValRequest message with an operation of "update" along with the<sidebarByValInfo>holding all those sidebar changes 💅 - When the sidebarByValRequest arrives to update the sidebar reservation, the conference server checks that Alice has the right authority based on the policies attached to that specific conference object 🔐 The conference server must also validate the updated information in the reservation, making sure a member like Bob is already a user of this conference server 🧐 Once the data for the conference identified by
<confObjID>is updated, the conference server sends a sidebarByValResponse message back to Alice 🌈 Depending on the policies, the initiator (Alice) and the sidebar participants (Bob) may get a heads-up about Bob being added to the sidebar through the conference notification service 🔔 - Now Bob sends a userRequest message to the conference server with an operation of "update" to completely turn off the background audio from the parent conference 🙉 Honestly he needs this, because it's stopping him from understanding what Alice says in the sidebar 😭
- Here's the thing: Bob's request only changes the media from his point of view 💁♀️ Alice keeps receiving both the audio from Bob and the background from the parent conference 🎧 This request may be relayed by the conference server to the media server doing the mixing, if there is one 🍓 Once the change is done, the conference server sends a userResponse message to Bob ✅ Depending on the policies, the initiator (Bob) and the sidebar participants (Alice) may get notified about this change through the conference notification service 🔔
The conference object below represents the conference where the sidebar is going to be created 🎀 It's what the conference server uses to build the new conference object for the sidebar 🧚
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<info:conference-info
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="xcon:8977878@example.com">
<info:conference-description>
<info:display-text>MAIN CONFERENCE</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8977878@example.com</info:uri>
<info:display-text>conference sip uri</info:display-text>
</info:entry>
</info:conf-uris>
<info:available-media>
<info:entry label="123">
<info:display-text>main conference audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>main conference video</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
<xcon:controls>
<xcon:video-layout>single-view</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>true</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:Alice@example.com">
<info:display-text>Alice</info:display-text>
<info:endpoint entity="sip:Alice@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:Bob@example.com">
<info:display-text>Bob</info:display-text>
<info:endpoint entity="sip:bob83@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:Carol@example.com">
<info:display-text>Carol</info:display-text>
<info:endpoint entity="sip:carol@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
</info:users>
</info:conference-info>
Figure 19: Conference with Alice, Bob, and CarolThe sidebar gets created by cloning the parent conference 🪞 Once the sidebar exists, an update request makes sure it's customized however you need 💖 The protocol dump below makes the whole flow even clearer 🦋
1. sidebarByValRequest/create message (Alice creates an internal sidebar) 💅✨
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>Okay so Alice is starting her very own private sidebar, and she's giving main character energy 🦋👑 Her request says create, and it's pointing at the main conference through xcon:8977878@example.com.
2. sidebarByValResponse/create message (sidebar returned) 🌸
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by Alice
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Carol@example.com"/>
</xcon:allowed-users-list>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>And the server said YES 🎉 The sidebar now exists with its own conference ID, xcon:8974545@example.com. It comes back with a 200 and success, and it's version 1. Alice, Bob, and Carol are all on the allowed-users list, and the sidebar's parent is the main conference. It's giving organized ✨
3. sidebarByValRequest/update message (Alice updates the created sidebar) 💖
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private sidebar Alice - Bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
<xcon:controls>
<xcon:gain>-60</xcon:gain>
</xcon:controls>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_1">
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValRequest>
</ccmpRequest>
</ccmp:ccmpRequest>Now Alice is glowing up the sidebar 🪞 She renames it "private sidebar Alice - Bob", and the main conference audio goes to recvonly with a gain of -60. Then she adds two brand-new sidebar media entries, AUTO_GENERATE_1 for audio and AUTO_GENERATE_2 for video, and the allowed-users list shrinks down to just Alice and Bob. Private era, iykyk 🤫🔥
4. sidebarByValResponse/update message (sidebar's updates accepted) 🎀
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByValResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>The server approved every single change 🙌 It's a 200, success, and the sidebar is now at version 2. Her vibe got accepted, bestie 💅
5. userRequest/update message (Bob updates his media) 🦋
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@example.com">
<info:media id="1">
<info:display-text>
main conference audio
</info:display-text>
<info:label>123</info:label>
<info:status>inactive</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>Bob's turn to tweak his settings 💜 He's switching his main conference audio, labelled 123, to inactive on his endpoint sip:bob83@example.com.
6. userResponse/update message (Bob's preferences are set) 🌈
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>3</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>And Bob's preferences are locked in ✨ Another 200 and success, and the sidebar is now at version 3. Everybody's happy, the sidebar is serving, and the drama is officially over for this part 🧚💀
Figure 20: Internal Sidebar Messaging Details 🌸
7.2. External Sidebar ✨
okay so this one is giving different energy 💅 Figure 21 shows another way to do sidebars. Alice is in an active conference with Bob, Carol, David, and Ethel 🌸 Then Bob slides a whisper to Alice: a critical customer needs to talk to Alice, Bob, and Ethel, like, now 😭 So Alice makes a sidebar to chat with the customer Fred, and she brings Bob and Ethel along. Carol and David stay in the active conference, no drama 🫶
The big difference from the last scenario is that Fred is not part of the parent conference 👀 That means different policies might be in play, because Fred could access information coming from the parent conference, if the sidebar was set up that way. So in this scenario we assume Alice turns off all the media from the original (parent) conference inside the sidebar 🎀 In the previous example, Alice and Bob could still hear the main conference audio in the background. This time? No background at all 🙈
Here's how it goes down. Alice asks the conference server to create a conference reservation based on the active conference object 🦋 Alice, Bob, and Ethel stay on the main conference roster but in a hold state. Whether other participants can see that hold state depends on the individual and local policy 💜 Still, showing the hold state lets people in the main conference see that others are busy, which is kind of iconic for group etiquette 🍓
Note that Alice could have made a totally separate conference so Bob and Ethel could talk to Fred ✨ But a sidebar has a perk: the new conference can reuse some of the same settings Bob and Ethel had in the main conference (like role, floor control, etc.), and it lets you update things later, like adding the main conference audio back in if you want 🧚
Figure 21 walks through the whole flow between Alice, Bob, and the conference server (ConfS):
Alice Bob ConfS
| | |
|(1) sidebarByRefRequest(confUserID, |
| confObjID, create) |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-ref | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByRefResponse(confUserID, | (parent mapping
| confObjID*,create,200,success, | conf<->sidebar)
| version,sidebarByRefInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByRefRequest(confUserID, |
| confObjID*,update,sidebarByRefInfo) |
|--------------------------------------------->|
| | |
| | (b) Create +---|
| | new user for | |
| | Fred | |
| | +-->|
| | |
| | (c) Update +---|
| | sidebar-by-ref | |
| | (media, users | |
| | policy, etc.) +-->|
| | | Sidebar is modified:
| | | media from the
| | | parent conference is
| | | not available to
|(4) sidebarByRefResponse(confUserID, | anyone
| confObjID*, update, |
| 200, success, version) |
|<---------------------------------------------|
| | |
| | Notify (Fred |
| | added to |
| | sidebar users) |
| |<----------------------|
| | |
' ' '
' ' '
' ' 'Figure 21: Client Creation of an External Sidebar 🌈
Now the step-by-step tea ☕
- Creating the sidebar reservation. When the conference server gets the sidebarByRefRequest to create a new sidebar conference based on the active conference named by
<confObjID>in the request, it uses that active conference to clone a conference reservation for the sidebar. The sidebar reservation is NOT independent of the active conference (i.e., parent) 🧠 The conference server, as before, hands out a new XCON-URI (confObjID*in Figure 21) for any later protocol requests aimed at the sidebar reservation. The mapping between the sidebar XCON-URI and the one for the main conference is kept by the conference server, and it's pulled from the<sidebar-parent>element in the sidebar conference object 💖 - Alice sets up the membership. When the sidebarByRefResponse comes back confirming the sidebar object was created, Alice decides that only Bob and Ethel, plus the new participant Fred, will be in the sidebar 🫶 So she edits the membership to match. She also sets the media in the
<conference-info>so the sidebar participants don't get any media from the main conference 🙈 All of these settings go to the conferencing server in a brand new sidebarByRefRequest with an "update"<operation>. - Updating the reservation and going live. Alice sends that sidebarByRefRequest to update the reservation and create an active conference ✨ When the conference server gets the sidebarByRefRequest/update message, it checks that Alice has the right authority under the policies for that specific conference object. It also validates the updated information in the reservation 💅 Fred is a brand new user for this conferencing system, so a conference user identifier (XCON-USERID) gets created for him. Fred is added just by giving his SIP URI. Based on the contact info Alice provided, the call signaling to add Fred can be kicked off by the focus (for example, if Fred has a "dial-out" value for the 'method' attribute in his
<target>field under<allowed-users-list>) when the sidebar is actually activated 📞 - The server replies. The conference server sends a sidebarByRefResponse message. Depending on the policies, the initiator (Alice) and the sidebar participants (Bob and Ethel) may get a heads-up about Fred joining through the conference notification service 🔔
Here are the messages, bestie 💌
1. sidebarByRefRequest/create message (Alice creates an external sidebar)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>2. sidebarByRefResponse/create message (created sidebar returned)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by Alice
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Carol@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:David@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Ethel@example.com"/>
</xcon:allowed-users-list>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Okay, the sidebar is born 🦋 We're getting the next messages in the next part, so stay tuned! 💜
3. sidebarByRefRequest/update message (Alice updates the sidebar ✨)
Alice is tidying up the sidebar here, so she sends an update with a fresh description, a new list of media, and a new set of allowed users. 💅
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description>
<info:display-text>
sidebar with Alice, Bob, Ethel and Fred
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>inactive</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>inactive</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_1">
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
<xcon:controls>
<xcon:video-layout>
single-view
</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-out"
uri="sip:fred@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefRequest>
</ccmpRequest>
</ccmp:ccmpRequest>4. sidebarByRefResponse/update message (sidebar updated) 🎀
The server replies that the update went through. It's giving "all done, bestie." 🫶
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 22: External Sidebar Messaging Details
7.3. Private Messages 💌
Private messages can be handled as a sidebar with just two participants, kind of like the example in Section 7.1. The difference is that instead of audio inside the sidebar, Alice could just add an extra text-based media stream to it so she can send her messages to Bob, while she keeps watching and listening to the main conference. Iconic multitasking 🧚
In this scenario, Alice asks the conference server to create a private chat room inside the main conference context (presented in Figure 19), where the only participants are Bob and herself. This happens through the CCMP transaction below (Figure 23). 🌸
- Alice forwards a sidebarByValRequest/create message to the conference server. It has the main conference XCON-URI in the
<confObjID>parameter and the desired sidebar conference object in the<sidebarByValInfo>field. So she's basically asking the server to create a sidebar from information she provides. Please note that, unlike the earlier sidebar examples, a completely new conference object describing the sidebar is provided here. There is no cloning involved, but the<confObjID>still keeps the parent-child relationship between the main conference and the sidebar that's about to exist. 💅 - The conference server checks Alice's rights and validates the conference object in the request, then creates the sidebar-by-val conference and a new XCON-URI for it. Instead of cloning the main conference object like in Sections 7.1 and 7.2, the sidebar is built from the user-provided information. The parent relationship still gets maintained by the conference server, because of the request message type she picked (the sidebarByVal one). It shows up in the
<sidebar-parent>element inside the<sidebarByValInfo>element that comes back in the sidebarByValResponse message. Also, according to the CCMP specification, returning the created sidebar data in this kind of "success" response is not mandatory. 🦋
1. sidebarByValRequest/create message (Alice creates a private chat room between Bob and herself) 🙈
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">
<info:conference-description>
<info:display-text>
private textual sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar text
</info:display-text>
<info:type>text</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValRequest>
</ccmpRequest>
</ccmp:ccmpRequest>2. sidebarByValResponse/create message (sidebar returned) 🎀
Here's the server's reply once the sidebar is made, and it comes back with the whole sidebar spelled out. ✨
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private textual sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="789">
<info:display-text>
sidebar text
</info:display-text>
<info:type>text</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 23: Sidebar for Private Messages Scenario 🦋
7.4. Observing and Coaching 🎓
Okay, "Observing and Coaching" is honestly one of the most interesting sidebar scenarios 😭 It's giving two different interactions that have to be properly coordinated, and they both need to vibe together. 💅
Here's the example in Figure 25 🌸 Call center agent Bob is in a conference with customer Carol. Bob is a new agent, and Alice notices he's been on the call with Carol for longer than normal, so she decides to observe the call and coach Bob whenever it's needed. 🫶 Of course, the conferencing system must make sure that customer Carol has no idea coach Alice is even there. ✨ That's why a sidebar is necessary for this scenario to work at all. 🔥
Consider the following as the conference document for the video conference with Bob (the call agent) and Carol (the customer) (Figure 24):
Bestie, this is the call-center conference object, and it's giving real-life customer service vibes 💁♀️✨
Figure 24: A Call-Center Conference Object Example
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<info:conference-info
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="xcon:8978383@example.com">
<info:conference-description>
<info:display-text>
CUSTOMER SERVICE conference
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8978383@example.com</info:uri>
<info:display-text>conference sip uri</info:display-text>
</info:entry>
</info:conf-uris>
<info:available-media>
<info:entry label="123">
<info:display-text>service audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>service video</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
<xcon:controls>
<xcon:video-layout>single-view</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>true</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:bob@example.com">
<info:display-text>Bob - call agent</info:display-text>
<info:endpoint entity="sip:bob@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:carol@example.com">
<info:display-text>Carol - customer</info:display-text>
<info:endpoint entity="sip:carol@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
</info:users>
</info:conference-info>Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
Alice Bob ConfS
| | |
|(1) sidebarByRefRequest(confUserID, |
| confObjID, create) |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-ref | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByRefResponse(confUserID, | (parent mapping
| confObjID*,create,200,success, | conf<->sidebar)
| version,sidebarByRefInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByRefRequest(confUserID, |
| confObjID*,update,sidebarByRefInfo) |
|--------------------------------------------->|
| | |
| | (b) Update +---|
| | sidebar-by-val | |
| | (media, users | |
| | policy, etc.) +-->|
| | | Sidebar is modified:
| | | unilateral sidebar
| | | audio, Carol excluded
| | | from the sidebar
|(4) sidebarByRefResponse(confUserID, |
| confObjID*, update, |
| 200, success, version) |
|<---------------------------------------------|
| | |
| | Notify (Bob |
| | he's been added to |
| | sidebar users) |
| |<----------------------|
| | |
' ' '
' ' '
' ' 'Okay so here's the lowdown on how the sidebar gets made, step by step 🫶
- The conference server gets Alice's sidebarByRefRequest/create message, asking for a new sidebar conference made from the <confObjID> in that request. It uses the active conference it received to clone a conference reservation for the sidebar. It also allocates a brand-new XCON-URI for any later protocol requests aimed at the new sidebar, and it keeps track of the mapping between this sidebar conference ID and the one tied to the main conference instance. Then it sends a sidebarByRefResponse with the new XCON-URI in the <confObjID> field and everything else useful in <sidebarByRefInfo> 🎀
- When Alice gets that response, she tweaks the data in <sidebarByRefInfo> 💅 She only wants Bob in the sidebar, so she updates the <allowed-users-list> to include just Bob and herself. She also wants her and Bob to hear audio from the original conference, but her outgoing audio should only go to the people in the sidebar, while Bob's outgoing audio should go to the main conference, so Alice and the customer Carol both hear the same audio from Bob. Alice sends a sidebarByRefRequest message with an "update" <operation> that includes the updated sidebar info in the <sidebarByRefInfo> element 🦋
- When the server gets that sidebarByRefRequest/update message, it checks that Alice has the right authority based on the policies for that specific conference object. To add another media stream to the sidebar (here, an audio stream from Alice to Bob), the requester has to include a new <entry> element in the <available-media> field of the <sidebarByRefInfo>. The mandatory 'label' attribute of that new <entry> is filled with the dummy value "AUTO_GENERATE_1", and it will hold the real server-generated media stream identifier once the stream is actually allocated on the server 🌸 Same deal for the mandatory 'id' attribute on the <media> element that refers to the new sidebar audio stream under both Alice's and Bob's <endpoint>. Those hold wildcard values: "AUTO_GENERATE_2" for Alice and "AUTO_GENERATE_3" for Bob. Those placeholders get swapped for the appropriate server-generated identifiers when the stream is created. We're assuming the conference server can recognize those dummy values as placeholders 🧚
- After validating all the data, the conference server sends a sidebarByRefResponse message. Based on the contact information Alice gave for Bob, the call signaling to add Bob to the sidebar with the right media characteristics is kicked off through the focus. Bob gets notified about being added to the sidebar through the conference notification service, so he knows Alice the supervisor is available to coach him through this call 👑
1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>2. sidebarByRefResponse/create message (sidebar created)
okay so this is where the sidebar officially gets born and I'm literally obsessed 🎀 Here's Alice's create response. It's the sidebar showing up with all its settings, lowkey iconic 💖
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by alice
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
<xcon:sidebar-parent>
xcon:8971313@example.com
</xcon:sidebar-parent>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:bob@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:carol@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>3. sidebarByRefRequest/update message (Alice introduces unilateral sidebar audio and excludes Carol from the sidebar) 🦋 Alice is making moves here, and Carol is not invited to this one 💅
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
Coaching sidebar Alice and Bob
</info:display-text>
<info:available-media>
<info:entry label="AUTO_GENERATE_1">
<info:display-text>
Alice-to-Bob audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:alice@example.com">
<info:endpoint entity="sip:alice@example.com">
<info:media id="AUTO_GENERATE_2">
<info:label>AUTO_GENERATE_1</info:label>
<info:status>sendonly</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:bob@example.com">
<info:endpoint entity="sip:bob@example.com">
<info:media id="AUTO_GENERATE_3">
<info:label>AUTO_GENERATE_1</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</info:user>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefRequest>
</ccmpRequest>
</ccmp:ccmpRequest>4. sidebarByRefRequest/update message (updates accepted) 🫶 And yes, the server says yes, so the update goes through ✨
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 26: Coaching and Observing Messaging Details 💜
8. Removing Participants and Deleting Conferences ✨
Okay so this section is all about the basic ways to kick someone out of a conference, or wipe the whole conference entirely 🧹 The examples assume a conference is already set up properly, with media if that applies, following one of the examples from Section 5. So we're starting from a happy, working call, no cap 💖
8.1. Removing a Party 💅
Figure 27 shows Alice removing Bob from a conference 👋 This one has Alice, Bob, Claire, and Duck all in the call. Alice wants Bob gone, so the group can keep going in the same conference without him. Bob is not invited to the next hangout 🙈
Alice Bob Claire ConfS
| | | |
|(1) userRequest(confUserID,| |
| confObjID, delete,| |
| userInfo) | |
|-------------------------------------->|
| | | |
| | | (a) Focus |
| | | tears down|
| | | signaling |
| | | to Bob |
| |<----------------------|
| | |
| | (b)Deletes+---|
| | | Bob | |
| | | as a | |
| | | user +-->|
| | | in |
| | | confObj |
| | | |
|(2) userResponse(confUserID,confObjID, |
| delete,200,success,version) |
|<--------------------------------------|
| | | |
| | | |
| | | (c) Notify|
| | | ("Bob just|
| | | left") |
| | |<----------|
| | |
' ' ' '
' ' ' '
' ' ' 'Figure 27: Client Manipulation of Conference - Remove a Party 🦋
- Alice sends a userRequest message with a
"delete"<operation>. Super clear. The conference server checks that Alice actually has the authority to do this, based on the policies tied to that specific conference object 🔐 - Next up, the conferencing system uses the contact and media info for Bob in the
<userInfo>element to start removing him. Think of it like the call signaling to remove Bob getting kicked off through the focus, (e.g., the call signaling to remove Bob from the conference is instigated through the focus). The conference server then updates the conference object and takes Bob off the<users>list. After all that, it sends a userResponse message back to Alice. Depending on the policies, other people in the call (like Claire) may get a heads-up that Bob has left through the conference notification service 🔔
1. userRequest/delete message (Alice deletes Bob) 🙅♀️
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>2. userResponse/delete message (Bob has been deleted) 🌸 Bye Bob 👋
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>17</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 28: Removing a Participant Messaging Details ✨
8.2. Deleting a Conference 🗑️💅
Okay bestie, time for a successful conference deletion example! Check out Figure 29 ✨
Alice ConfS
| |
|(1)confRequest(confUserID, |
| confObjID, delete) |
|------------------------------>|
| (a)Delete +---|
| Conf | |
| Object | |
| +-->|
| |--+ (b) MS
| | | removes related
| | | mixer instances and
| |<-+ their participants
| | (SIP signaling as well)
| |
|(2)confResponse(confUserID, |
| confObjID,delete,200, |
| success) |
| |
|<------------------------------|
| |
' '
Figure 29: Deleting a Conference- So the conferencing client Alice sends a confRequest with a "delete" operation 🫶 aimed at the conference named by the XCON-URI in the <confObjID> parameter. The conference server looks at the <confUserID> in the request to make sure Alice actually has the right authority to pull this off. No cap, it's a security check. 🔐
- Once Alice's rights are confirmed, the conference server starts deleting the conference object. That means disconnecting participants and clearing out associated resources, like mixer instances. ✨ Then the server sends a confResponse back to Alice with "200" as the <response-code> and the deleted conference XCON-URI in the <confObjID> field. Iconic. 👑
1. confRequest/delete message (Alice deletes a conference) 💖
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>2. confResponse/delete message ("200", "success") 🌸
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>Figure 30: Deleting a Conference Messaging Details 🧚
9. Security Considerations 🔒
Okay, serious moment incoming 😭 The security considerations that apply to implementing these call flows are documented in the XCON framework, and there are extra security considerations in the CCMP document. Some flows talk about the security needed, but that's just for information. The implementer is encouraged to carefully consider the security requirements in the normative documents. Read them, bestie. 🫶
10. Acknowledgements 🎀
The detailed content of this document comes from the prototype work of Lorenzo Miniero, Simon Pietro Romano, Tobia Castaldi, and their colleagues at the University of Napoli. Huge thanks to them! 💜
11. References 📚
11.1. Normative References
[RFC5239]Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.[RFC6501]Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.[RFC6502]Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.[RFC6503]Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.[W3C.REC-xml-20081126]Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008,<http://www.w3.org/TR/2008/REC-xml-20081126>.
11.2. Informative References
[CALL-FLOWS]Amirante, A., Castaldi, T., Miniero, L., and S. Romano, "Media Control Channel Framework (CFW) Call Flow Examples", Work in Progress, July 2011.[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.[RFC4575]Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.[RFC4579]Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.[RFC4582]Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.[RFC4597]Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.[RFC5567]Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.[RFC6505]McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012.
Authors' Addresses 💌
Mary Barnes Polycom TX USA
EMail: mary.ietf.barnes@gmail.com
Lorenzo Miniero Meetecho Via Carlo Poerio 89/a Napoli 80121 Italy
EMail: lorenzo@meetecho.com
Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy
EMail: roberta.presta@unina.it
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
EMail: spromano@unina.it
That's the whole RFC, babe! 🦋✨ Every section, number, message, and citation made it through. Go slay your implementation! 💅👑
📦 where this page comes from
- ietf: rfc6504 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms