RFC 5239
A Framework for Centralized Conferencing
Part 1 of 16 ✨
A Framework for Centralized Conferencing 🎀
RFC 5239, bestie, is a Standards Track document from the Network Working Group, dated June 2008. It was written by M. Barnes (Nortel), C. Boulton (Avaya), and O. Levin (Microsoft Corporation). Its title block doesn't list any RFCs it obsoletes or updates, so it's a fresh one 💅
Status of This Memo 📮
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 If you want the current standardization state and status of this protocol, go check the "Internet Official Protocol Standards" (STD 1) document. And the good news: distribution of this memo is unlimited, so share it freely 🦋
Abstract 🌈
Okay so this document defines the framework for Centralized Conferencing ✨ The framework lets participants on different call signaling protocols, like SIP, H.323, Jabber, Q.931, or ISDN User Part (ISUP), swap media in a centralized unicast conference. It's giving "everyone in one room, all connected through one hub" 🫶
The Centralized Conferencing Framework defines logical entities and naming conventions. It also lays out a set of conferencing protocols that sit alongside the call signaling protocols, so you can build advanced conferencing apps 💜 And the whole framework ties every defined component together, so builders of conferencing systems get one clean picture 👑
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
5.1. Conference Information . . . . . . . . . . . . . . . . . . 11
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 16
7. Conferencing System Realization . . . . . . . . . . . . . . . 17
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Ad Hoc Example . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21
7.4. Scheduling a Conference . . . . . . . . . . . . . . . . . 23
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
9.5. Floor Control Using Sidebars . . . . . . . . . . . . . . . 40
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
9.7. Conference Announcements and Recordings . . . . . . . . . 44
9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
10. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11.1. User Authentication and Authorization . . . . . . . . . . 51
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 53
11.3. Floor Control Server Authentication . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 541. Introduction ✨
Okay bestie, this document defines the framework for Centralized Conferencing 💖 The framework lets participants using different call signaling protocols, like SIP, H.323, Jabber, Q.931, or ISUP, exchange media in a centralized unicast conference 🎀 Outside of general stuff like establishment and teardown, the nitty-gritty details of those call signaling protocols are out of scope here, so don't come looking for them in this doc 🙈
The Centralized Conferencing Framework defines logical entities and naming conventions 🌸 It also outlines a set of conferencing protocols that complement the call signaling protocols, which is how you build advanced conferencing applications 🔥
The Centralized Conferencing Framework is compatible with the functional model in the SIP Conferencing Framework [RFC4353] 🦋 Section 10 of this document is where the relationship between the two frameworks gets discussed, using the Centralized Conferencing model this document presents. It's the main character moment for compatibility 👑
2. Conventions 💅
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations 🫶 These are the official words that tell you how strict a rule is, so read them carefully, periodt ✨
3. Terminology ✨
okay so this doc is about to go full dictionary mode 📖💅 but it's basically a glossary of the same concepts as the SIP Conferencing Framework [RFC4353], plus some brand new ones. where it makes sense it stretches the old terms, and then the rest of the doc explains everything in more detail. let's go 🎀
Active conference: an active conference is a conference object that's been created AND activated. activated means it got its identifiers (like the conference object identifier and the conference identifier) and its focus. it starts from either the system's default conference blueprint or a specific conference reservation. ✨
Call Signaling protocol: the call signaling protocol is what a participant uses to talk to a focus. quick note, "call" here means a channel or session that carries media streams 📞
Conference blueprint: a blueprint is a static conference object sitting inside the conferencing system. it describes a typical conference setup the system supports. it's the base that dynamic conference objects get made from, and a system can have lots of blueprints 🌸 each one holds the starting values and ranges for the object's elements, following the data schemas for conference information.
Conference control protocol (CCP): this one gives you the interface for manipulating data and retrieving state for the centralized conferencing data, which is the stuff represented by the conference object 🧚
Conference factory: a logical entity that generates unique URI(s) to identify and represent a conference focus. basically the URI machine 🏭✨
Conference identifier (ID): a call signaling protocol-specific URI that identifies a conference focus and its associated conference instance. so it's the one tied to the signaling side 💖
Conference information: this is the big bucket of definitions for basic conference features: conference identifiers, membership, signaling, capabilities, and media types, all for a wide range of conferencing apps. it also covers media and app-specific stuff for the extra fancy features, like media mixers. and here's the iconic part: conference information is the data type (aka the XML schema) for a conference object 🎀
Conference instance: an internal implementation of one specific conference, shown as a set of logical conference objects plus their identifiers 🦋
Conference object: this represents a conference at a certain stage, like when it's first described, reserved, activated, and so on. the conferencing system keeps these so it can describe its capabilities and give access to the services each object offers on its own 💅 the conference object schema is based on conference information.
Conference object identifier (ID): a URI that uniquely identifies a conference object. a conference control protocol uses it to access and modify the conference information 🔑
Conference policies: a collective term for the rights, permissions, and limitations that apply to operations performed on a particular conference object 🛡️
Conference reservation: a conference object created from either a system default blueprint or a blueprint the client picked 📅
Conference state: this reflects the state of a conference instance and is represented using a specific, well-defined schema 📊
Conferencing system: a conferencing solution that's based on the data model in this framework document and built using the protocol specs this framework document references. so it's the whole package 📦✨
Conference user identifier (ID): a unique identifier for a user within the scope of a conferencing system. one user can have multiple of these, for example to represent different roles 🎭
Floor: a set of data or resources tied to a conference instance, which a participant (or a group of participants) gets temporary access to 🌈
Floor chair: a floor control protocol compliant client who's authorized to manage access to one floor, and can grant, deny, or revoke that access. the client can be a human participant or an automated entity 🤖 and the floor chair doesn't have to be a participant in the conference instance. wild, right? 👑
Focus: a logical entity that keeps the call signaling interface with each participating client, plus the conference object that represents the active state. so the focus acts as an endpoint for each supported signaling protocol. it's also in charge of all the main membership stuff (join, leave, updating the conference instance) and of media negotiation and maintenance between a participant and the focus 🧠💜
Media graph: the logical representation of how media flows through a conference 🕸️
Media mixer: a logical entity that can combine media inputs of the same type, transcode the media, and distribute the results to one or many outputs 🎛️ in this context, "media" means any kind of data delivered over the network using appropriate transport means, like RTP/RTP Control Protocol (RTCP) (defined in [RFC3550]) or Message Session Relay Protocol (defined in [RFC4975]) 🎶
Role: a role gives context for the set of conference operations a participant can perform. there's always a default role (like a standard conference participant) that gives a user basic conference operations. depending on system-specific authentication and authorization, a user can also take on alternate roles, like a conference moderator, which unlocks a wider set of operations 👑✨
Sidebar: a separate conference instance that only exists inside a parent conference instance. the whole point is to give additional or alternate media to only specific participants 🤫
Whisper: a one-time media input sent to specific participant(s) inside a specific conference instance, done using a sidebar. classic example: an announcement that only the conference chair hears, or one that only a brand new participant joining the conference gets 🙈🫶
4. Overview ✨
okay so a centralized conference is basically a group of endpoints (called conference participants) all connected to one central endpoint called a conference focus 👑. The focus keeps a separate call signaling interface open with each participant, so everyone has a direct peer relationship with it. That means in this model the call signaling graph is always a star 🌟 (one hub, lots of spokes, very neat).
The simplest conference in this model would be an ad hoc, unmanaged one 🍓. It wouldn't really need any of the stuff in this framework. For example, it could run on basic SIP signaling with one of the participants acting as the focus. The SIP Conferencing Framework [RFC4353] and SIP Call Control Conferencing for User Agents [RFC4579] already cover these kinds of scenarios, so go check those out 💅.
But a conferencing system following the centralized model in this framework document can do so much more ✨. It can offer dedicated conferencing applications with explicitly defined capabilities, reserved recurring conferences, and the standard protocols for managing and controlling all the different attributes of those conferences. Main character energy, honestly 🎀.
The core requirements for centralized conferencing are laid out in [RFC4245]. They work for conferencing systems using all kinds of call signaling protocols, SIP included. Extra conferencing requirements live in [RFC4376] and [RFC4597] 🧚.
The whole centralized system is built around one big idea: the conference object 🦋. A conference object is the data representation of a conference at each stage of its life (creation, reservation, active, completed, and so on). You reach it through the logical functional elements that a conferencing client talks to, using the protocols shown in Figure 1. The framework defines a conference control server, a floor control server, any number of Foci, and a notification service 💜. Here's how the protocols line up:
- A conference control protocol (CCP) connects a conference and media control client to the conference control server.
- A floor control protocol (for example, the Binary Floor Control Protocol (BFCP)) connects a floor control client to the floor control server.
- A call signaling protocol (for example SIP, H.323, Jabber, Q.931, ISUP, and so on) connects a call signaling client to a focus.
- A notification protocol (for example SIP Notify [RFC3265]) connects the conferencing client to the notification service.
A conferencing system doesn't have to support every function in Figure 1 and the rest of this document 🌸. Some pieces are basically essential, though, because most of the advanced stuff depends on them, and the notification service is a great example. It's how info like the list of participants and their media streams gets correlated between all the other components 🫶.
....................................................................
. Conferencing System .
. .
. +-----------------------------------------------------+ .
. | C o n f e r e n c e o b j e c t | .
. +-+---------------------------------------------------+ | .
. | C o n f e r e n c e o b j e c t | | .
. +-+---------------------------------------------------+ | | .
. | C o n f e r e n c e o b j e c t | | | .
. | | | | .
. | | |-+ .
. | |-+ .
. +-----------------------------------------------------+ .
. ^ ^ ^ | .
. | | | | .
. v v v v .
. +-------------------+ +--------------+ +-------+ +------------+ .
. | Conference Control| | Floor Control| |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-------------------+ +--------------+ +-------+ +------------+ .
. ^ ^ ^ | .
..............|.................|...........|..........|............
| | | |
|Conference |Binary |Call |Notification
|Control |Floor |Signaling |Protocol
|Protocol |Control |Protocol |
| |Protocol | |
| | | |
..............|.................|...........|..........|............
. V V V V .
. +----------------+ +------------+ +----------+ +------------+ .
. | Conference | | Floor | | Call | |Notification| .
. | and Media | | Control | | Signaling| | Client | .
. | Control | | Client | | Client | | | .
. | Client | | | | | | | .
. +----------------+ +------------+ +----------+ +------------+ .
. .
. Conferencing Client .
....................................................................
Figure 1: Conferencing System Logical DecompositionThe media graph can be centralized, decentralized, or a mix of both 🌈, and it can even differ per media type. In the centralized case, a media mixer controlled by the focus sets up media sessions with each participant. In the decentralized (a.k.a. distributed) case, the media graph is a multicast or multi-unicast mesh among the participants 🕸️. That means media processing (like mixing) can be controlled by the focus alone or by the participants themselves. This framework maps cleanly onto the centralized media model 💖. The decentralized case can kinda work with these concepts too, but the details are left for future study 🔮.
Here's the roadmap for the rest of the doc 🗺️. Section 5 digs into the conference object. Section 6 defines the constructs and identifiers that MUST be implemented to manage conference objects, instances, and users in a conferencing system. Section 7 shows how a conferencing system is logically built from the high level data model and how conference objects are kept up to date. Section 8 covers the fundamental conferencing mechanisms and gives a high level overview of the protocols. Section 9 walks through realizations of various conferencing scenarios, showing how the conference objects get manipulated with the defined protocols 🎬. And Section 10 wraps things up by explaining how this Centralized Conferencing Framework relates to the SIP Conferencing Framework 🫶.
5. Centralized Conferencing Data 📦
The centralized conference data is represented logically by the conference object 💜. A conference object is of type 'Conference information type', as shown in Figure 2. And the conference information type is extensible, so it can grow with you 🌱.
+------------------------------------------------------+
| C o n f e r e n c e o b j e c t |
| |
| +--------------------------------------------------+ |
| | Conference information type | |
| | | |
| | +----------------------------------------------+ | |
| | | Conference description (times, duration) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Membership (roles, capacity, names) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Signaling (protocol, direction, status) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor information | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Sidebars, Etc. | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Mixer algorithm, inputs, and outputs | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor controls | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Etc. | | |
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+
Figure 2: Conference Object Type DecompositionSame conference object type gets reused for a conference at every stage of its life 🦋. Whether you're expressing what the conferencing system can do, reserving resources, or reflecting the state of a conference that's already running, it's the same object, just looking different at each stage ✨. Section 7 explains the usage semantics of conference objects. The exact XML schema, including how the conference information is organized, lives in a separate document [XCON-COMMON] 📄.
On top of that basic data model from [XCON-COMMON], this framework also needs a policy infrastructure 🔐. These policies control access to the data, and they cover local, system level boundaries tied to specific data elements (like membership), plus the ranges and limits on other data elements. More policy considerations for a real system built on this data model are discussed in Section 5.2 💅.
5.1. Conference Information ✨
okay so there's a core set of conference info that every conference needs, no matter what kind of media it's doing (mixing, fancy floor control, all of it) 💅 this core set covers the conference object's capabilities, who's in it, their roles, call signaling, and media status at each stage of the conference life-cycle 🦋 it can be represented using the conference-type from the SIP conference event package [RFC4575]. typically, people who only have read-only access to the conference info just care about this core set 🫶
then there's the extra stuff! to support fancier media manipulation and enhanced conferencing features, the conference info (as defined in the data model [XCON-COMMON]) holds more data than [RFC4575] covers 🔥 that's where you find the specific media mixing details, the floor controls that are available, and other data needed for the enhanced features. this lets authorized clients change the mixer's behavior through the focus, and the resulting media gets distributed to everyone or to individual participants. so a client can change its own state, and also the state of other participants in the conference. iconic behavior, honestly 👑
and periodt, new centralized conferencing specs are allowed to extend the basic conference-type from the data model [XCON-COMMON] and add new data elements for use within the conference information type 🌈
5.2. Conference policies 💜
so "conference policies" is the umbrella term for a set of rights, permissions and limitations that apply to operations on a certain conference object 🎀
the rights describe the read/write access privileges for the conference object as a whole. this access is usually granted and defined by giving read-only or read/write access to clients with certain roles in the conference. the conferencing system needs access to basic policy info to make those decisions, but it doesn't necessarily need an explicit representation in the policy model. so for this framework document, the policies represented by the rights are reflected in the system realization (Section 7) ✨
the permissions and limits need explicit policy mechanisms, and they're outside the scope of the data model [XCON-COMMON] and this framework document. BUT there are some important policy considerations for a conferencing system 👀 a conferencing system links specific policies (permissions and limitations) with each user. the permissions can change based on the role tied to a specific conference user identifier. and a conferencing system should provide a default user role that only allows participation in a conference through the default signaling means 💖
the conference object identifier gives access to the data for one specific conference. it's important that elements in the data have their own policy controls, so you can flexibly define roles and pick which data elements users with specific roles can manipulate 🍓
also, the conference notification interface lets specific data elements get sent to users who register for notifications. this is highkey a big deal: the right access control has to be in place so that only users who are authorized to view specific data elements actually receive that data in the notifications 😭🔒
6. Centralized Conferencing Constructs and Identifiers 🧚
this section breaks down the identifiers for the centralized conferencing framework constructs, plus the identifiers REQUIRED to address and manage the clients connected to a conferencing system 🌸 you'll get an overview of how the identifiers are allocated, what they're like, and what job each one does.
6.1. Conference Identifier 🎀
the conference identifier (conference ID) is a call signaling protocol-specific URI. it identifies a specific conference focus and its associated conference instance 💅 one way to generate a unique conference ID (so you can address a conference focus over a call signaling interface) is a conference factory. the details for using a conference factory with SIP signaling are in [RFC4579] ✨ the conference identifier can also be obtained through the conference control protocol, or through other mechanisms (including proprietary, out-of-band ones) 🦋
to realize the centralized conferencing framework in this document, a conferencing system is REQUIRED to support SIP as the default call signaling protocol. other call signaling protocols (e.g., ISUP) are OPTIONAL 🫶
6.2. Conference Object 🔥
a conference object is the logical representation of a conference instance at a certain stage. think of a conference blueprint (which represents what a conferencing system is capable of), the data for a conference reservation, or the conference state during an active conference 🌈 every conference object can be addressed on its own through the conference control protocol interface (see Section 8.3). and a conferencing system MUST provide a default blueprint that represents the basic capabilities that specific conferencing system offers 💖
Figure 3 shows how the conference identifier, the focus, and the conference object ID relate to each other in one logical conference instance, where the conference object is an active conference 👑
A conference object for a conference in the active state can have multiple call signaling conference identifiers, for example one for each call signaling protocol it supports 🍓 there's a one-to-one mapping between an active conference object and a conference focus. the focus is addressed by explicitly associating a unique conference ID for each signaling protocol the active conference object supports ✨
....................................................................
. Conference Instance .
. .
. .
. +---------------------------------------------------+ .
. | Conference Object Identifier | .
. | | .
. | | .
. +---------------------------------------------------+ .
. ^ ^ .
. | | .
. v | .
. ................................................... | .
. . Focus . | .
. . . | .
. . +----------------------------------+ . | .
. . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | .
. . | Conference Identifier (ISUP) | | . | .
. . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | .
. . | |^ | . | .
. . +--------------------------------------+| | . | .
. ............^...............................|.|.... | .
. | | | | .
................|...............................|.|......|..........
| | | |
|SIP | | |Conference
| ISUP | |Y |Control
| | | |Protocol
| +---------------+ | |
| | | |
| | | |
v v v v
+----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client |
| 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+
Figure 3: Identifier Relationships for an Active Conference6.2.1. Conference Object Identifier ✨
okay bestie, every conference object has to be reachable from the outside, so the conferencing system MUST allocate a unique URI per distinct conference object in the system 🔗. The conference object identifier is defined in [XCON-COMMON]. The system makes a conferencing object identifier for every conference blueprint, every conference reservation, and every active conference 🎀. How it gets handed out depends on the use case. It could go through the conference control protocol mechanism, the data model and conference package, or out-of-band stuff like email 📧.
If a user wants to create or join a conference and doesn't have the conference object identifier yet, the more general signaling mechanisms kick in 🧚. A user might have a pre-configured conference object identifier to get into the system, or other signaling protocols can be used, and the conferencing system maps those to a specific conference object identifier. Once a conference is established, a conference object identifier is REQUIRED for the user to manipulate any of the conferencing data or use any of the advanced conferencing features 💅. Same energy for users joining through other signaling protocols. They can start out by joining with any of the other signaling protocols the system supports, but the conference object identifier MUST be used to manipulate any of the conferencing data or take advantage of any of the advanced conferencing features 🫶. The way a user learns the identifier varies. It could be the conference control protocol, the data model and conference package, or totally out of band, like email or a web interface 🌸.
The conference object identifier logically maps to other protocol-specific identifiers tied to the conference instance, like the BFCP 'confid' 🦋. Ngl, the mapping can be seen as sensitive info in lots of conferencing systems 😭. So the conferencing system must ensure that the data is protected, that only authorized users can manipulate that info through the conferencing control protocol, and that only the right people get it through the notification protocol. Generally this info isn't expected to be shared with the average conference participant 🙈.
6.3. Conference User Identifier 👑
Each user in a conferencing system MUST be allocated a unique conference user identifier 💜. The conference user identifier is defined in [XCON-COMMON]. It's used together with the conference object identifier to uniquely identify a user within the scope of the conferencing system. There's also a need to identify conferencing system users who aren't in a conference instance right now, like a non-participating 'Floor Control Chair' or 'Media Policy Controller' 🧑💻. The conference user identifier is REQUIRED in conference control protocol requests to uniquely determine who is issuing commands, so the right policies can be applied to the requested command 🔐.
A typical way to distribute the user identifier is out of band during conferencing client configuration, which means it's outside the scope of the centralized conferencing framework and protocols 🍓. However, a conferencing system MUST also be capable of allocating and distributing a user identifier during the first signaling interaction with the system, like an initial request for blueprints or adding a new user to an existing conference using the conference control protocol 🚀. When a user joins a conference using a signaling-specific protocol, like SIP for a dial-in conference, a conference user identifier MUST be assigned if one isn't already associated with that user. It isn't required for the participant to join, but it is REQUIRED to be allocated and assigned by the conferencing system so it's available for any later conference control protocol operations and/or notifications for that conference ✨. For example, the conference user identifier would be sent in any notifications that go to existing participants, like the moderator, when this user joins 📣.
The conference user identifier is logically associated with the other user identifiers the conferencing client has for other protocol interfaces, like an authenticated SIP user. Mapping the conference user identifier to signaling-specific user identifiers means methods for protecting and securing a user's identity have to be considered 🔒. Section 11.1 addresses "User Authentication and Authorization" and Section 11.2 addresses the "Security and Privacy of User Identity". On top of that, the conferencing system MUST ensure the appropriate access control around any internal data structure that keeps this persistent data 🕵️. This info would typically only be available to a conferencing system administrator.
7. Conferencing System Realization ✨
Implementations based on this centralized conferencing framework can range from systems that only support ad hoc conferences with default behavior, all the way up to sophisticated systems 🎬. Those can schedule recurring conferences, each with distinct characteristics, integrate with external resource reservation tools, and provide snapshots of the conference information at any stage of the conference life-cycle. Totally iconic range.
A conference object is the logical representation of a conference instance at a certain stage, like the capabilities description when a conference is created, reserved, activated, and so on 🌳. The conferencing system keeps these in order to describe its capabilities and to give access to the services it offers. So this centralized conferencing framework doesn't mandate how the conference object is actually used. Instead, it defines the general cloning tree concept and the mechanisms needed to make it real, as described in detail in Section 7.1.
Ad hoc and advanced conferencing examples are in Section 7.2 and Section 7.3. The latter gives more detail on the conference object in terms of the stages of a conference, so scheduled and other advanced capabilities are supported 💖. Scheduling a conference based on these concepts and mechanisms is then detailed in Section 7.4
As discussed in Section 5.2, the overall policy for permissions and limitations is outside the scope of this framework document 🙅♀️. The policies that apply to the conference object as a whole, in terms of read/write access, would require the conferencing system to have access to basic policy information so it can make decisions. In the examples in this section, the policies are shown logically associated with the conference objects. That's to really emphasize the general need for policy functionality to realize this framework 👑🌈.
7.1. Cloning Tree 🌳
okay so this part is a logical model only, bestie 🫶 It's reflected through the centralized conferencing mechanisms (the URIs and the protocols), but the actual system can be built differently. The whole point is to show how the logical pieces give you an interface to the data, based on what the conferencing system and the client do, and what that means for the protocols. 💅
Every conference object is made in one of two ways. It's either explicitly cloned from an existing parent object, or implicitly cloned from a default system conference blueprint. A blueprint is a static conference object that describes a typical conference setting the system supports. A system can keep several blueprints, usually one for each type of conferencing, written in the conference information format. 📋 This document says "cloning" instead of "inheritance" because cloning is about object replication, not about reusing and extending a data type. 🧚
The cloning operation has to say whether the link between parent and child should be kept in the system. If there's no link, the objects become independent. Then the child isn't affected by anything that happens to the parent, and it isn't bound by any limits the parent has. 🦋
Once the new object exists, the system gives it a unique conference object URI, which you can read about in Section 6.2.1. 🔗 By default, the new object has all the data the parent had. It can add more data, as long as it uses schema types the parent supports. It can also limit who gets read/write access to its objects. But unless the object is independent, it can't change the access restrictions the parent put in place. 🔒
Any piece of data in the child can be accessed on its own. By default, it can also be changed on its own, and that won't touch the parent's data. 🌸
Unless the object is independent, the parent can enforce its own policy by marking certain data elements as "parent enforceable". 👑 Nobody can change those values by poking at the child directly, and the child can't expand them on its own either. 🙈
Figure 4 shows an example. Parent B is created independently from Parent A. Parent B then makes two children, Child 1 and Child 2. Any of Parent B's data can be changed (there are no "parent enforceable" elements in this example), and depending on the element, the changes show up in Child 1 and Child 2. Changes to Parent A don't affect Parent B's data at all. Any "parent enforceable" elements that Parent B defined can't be changed in the children. ✨
+---+-----------------------+
| p | |
| o | P A R E N T A |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
|
\| /
\/ INDEPENDENT
/\
/| \
V
+---+-----------------------+
| p | |
| o | P A R E N T B |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
| |
| |
| ---------------------------
| |
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | O B J E C T | | i | O B J E C T |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 4: The Cloning TreeUsing this cloning model and its tools, the next sections show how different systems built on this framework can be set up. 🎀
7.2. Ad Hoc Example 💖
Figure 5 shows how an ad hoc conference gets created and managed in a conferencing system. 📞 A client creates a conference by setting up a call signaling channel with a conference factory, as described in Section 6.1. The conference factory can pick one of the blueprints the system supports on its own, based on the client's privileges and the media lines in the Session Description Protocol (SDP) body. 🧠
The server copies the chosen blueprint, along with its default values, into a brand new conference object called an 'Active Conference'. ⭐ Right then, the conference object becomes independent from its blueprint. The server also allocates a new conference object identifier, a new conference identifier, and a new focus. 🦋
For the rest of the conference's life, an authorized client can change the conference object using the conference control protocol, for example by adding participants. 🫶
+---+-----------------------+
| p | |
| o | System Default |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Active |
| l | |
| i | Conference |
| c | |
| i | |
| e | |
+-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime7.3. Advanced Example 🌈
Figure 6 shows how a recurring conference can be defined to match what the system can do, then scheduled, reserved, and managed. 📅 First, the client asks the conferencing system what it can do. One way to do that is to request the list of conference blueprints the system supports. 🔍 Each blueprint describes a specific mix of what the conference server can do and what it can't. That covers the supported media types (e.g., audio, video, text, or combinations of these), participant roles, the maximum number of participants for each role, whether floor control is available, which controls participants get, whether sidebars exist and what type they are, the definitions and names of media streams, and so on. 🎧
The client clones the chosen blueprint, with its default values, into a brand new conference object called a conference reservation. This reservation says which resources the conference instance needs from the system. 🎟️ Right then, the reservation becomes independent from its blueprint. The client can change the default values within the system's ranges, and it can add extra info, like the list of participants and the conference 'start' time. 🕒
After that, the client can ask the conference server to make new conference reservations by attaching the original reservation to the request. 📎 The server can then reserve the resources needed, create the extra conference objects for the child reservations, and assign conference object identifiers to the original reservation and to every child reservation. 🧚♀️
From here on, any authorized client can access and modify each conference object separately. 💅 By default, changing one child reservation doesn't affect the parent reservation it came from, or its siblings. 🙅♀️
Some sub-objects, though, like the maximum number of participants and the participants list, can be set by the system as parent enforceable. 👑 That means you change them through the parent reservation only. Those changes can then be applied to each child reservation automatically, depending on local policy. 🫧
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
Figure 6: Advanced Conference Definition, Creation, and LifetimeWhen it's time to schedule the reservation, the active conference gets cloned from it. That happens either when the system sees that the 'start' time has arrived, or when a client triggers it. 🚀 Just like the ad hoc example, the active conference is independent from its parent. Changes to the conference reservation won't affect the active conference, so any changes you want have to target the active conference directly. 🎯 You can see an example of this interaction in Section 9.1. 💜
7.4. Scheduling a Conference ✨
Scheduling is a huge part of the conferencing system vibe 📅. A single reservation usually has a 'start' and an 'end' time, and both are measured from one fixed time, like 'start' = 09.00 GMT, 'end'= 'start'+2, all subject to system considerations 💅. Most advanced setups let you schedule one occurrence OR a whole series of related conferences, like a weekly meeting that kicks off Thursday at 09.00 GMT 🗓️.
To pull that off, a conferencing system has to schedule and maintain the reservations that make up a recurring conference 🔁. This mechanism uses the "Internet Calendaring and Scheduling Core Object" spec from [RFC2445], combined with the concepts from Section 5, for advanced scheduling 🧚.
Figure 7 shows the big picture 🎀. A client uses the conference control protocol to add a new reservation to the conferencing system by talking to the conference control server. A CCP request carries a valid conference reservation plus a reference by value to an "iCal" object that holds scheduling info, like 'start' and 'end' times 📦.
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+Figure 7: Resource Scheduling
A CCP create request gets validated, iCal object and all, and then the reservation is made 💖. It's uniquely represented inside the system by a conference object identifier (e.g., xcon:hd87928374), which Section 6.2.1 introduced and [XCON-COMMON] defines 🆔. That unique URI goes back to the client, so if they ever need to change something later (say, the 'start' time), they can reference it in another CCP request 🫶.
The example above is how a basic reservation gets made, with an iCal reference riding along on the conference control protocol 🌸. Figure 7 works for recurring series too 🔁. The only difference is that the iCal object describes a series of recurring instances (like 'start' time, 'end' time, occurring weekly) 📆. The system treats it the same as the first example: validate the CCP request and the iCal object, then create the reservation. This time, though, the reservation and its conference object ID stand for the entire series, not a single Conference 😭.
If the client uses that ID with a CCP request to adjust the reservation, every instance in the series gets altered, including all future occurrences. That even covers an infinite series, subject to the limits of the available calendaring interface 🌀.
A conferencing system that supports series should also handle changes within a specific range of the series ✂️. Say a meeting is scheduled every Monday at 09.00 GMT, but for the next three weeks only, it's moved to 10.00 GMT at a different venue 📍. The client builds a CCP request to modify the existing reservation for that recurring instance. It includes the conference object ID to explicitly reference the reservation, plus all the required changes (e.g., change of venue) 💅.
The system matches the incoming request to the existing reservation, but notices the iCal object only refers to a range of the series. So it creates a child by cloning the original reservation to represent the altered instances 👯. The cloned child isn't independent of the original parent, which prevents scheduling conflicts (e.g., a change to the whole series' ''start' time) 👑. The cloned reservation gets its own conference object ID, returned to the client in a CCP response, and the client uses that ID for future changes to the new sub-series 🦋. This can repeat any number of times, since the new ID for the altered series can itself be manipulated with a CCP request. It's a super flexible way to handle recurring conferences 🌈.
8. Conferencing Mechanisms ✨
8.1. Call Signaling
The focus is the heart of the conference 💖. Participants plug into the focus using an appropriate call signaling protocol (CSP) 📞. They use the CSP to request to establish or join a conference. After checking the applicable policies, the focus either accepts the request, sends a progress indication about its status (e.g., for a parked call waiting on moderator approval to join ⏳), or rejects it through the call signaling interface 🙅.
During an active conference, the conference control protocol can be used to change the conference state 🔧. For example, CCP requests to add and delete participants are sent to the focus and checked against the conference policies. If approved, participants are added or deleted using call signaling to or from the focus 🎉.
8.2. Notifications
A conferencing system is responsible for running a conference notification service 🔔. It gives updates about the conference instance state to authorized parties, including participants 📣. A model for notifications using SIP is defined in [RFC3265], with the conferencing specifics defined in [RFC4575] 🧾.
The conference user identifier and associated role are used by the conferencing system to filter notifications, so each user only gets information they're allowed to receive 🔍.
8.3. Conference Control Protocol
The conference control protocol handles data manipulation and state retrieval for the centralized conferencing data, represented by the conference object 🗂️. The details of the conference control protocol live in separate documents 📚.
8.4. Floor Control 🎀
okay so a floor control protocol lets an authorized client manage access to a specific floor 🌸 and grant, deny, or revoke access for other conference users to that floor 💅. floor control isn't mandatory for a conferencing system implementation, but it gives conference users advanced media input control features ✨. a mechanism for floor control inside a conferencing system is defined in the "Binary Floor Control Protocol (BFCP)" specification [RFC4582] 🦋.
within this framework, a client that supports floor control needs connection info for a floor control server so it can issue floor requests 🧚. that info can be retrieved through mechanisms like negotiation using the SDP [RFC4566] offer/answer [RFC3264] exchange on the signaling interface with the focus 💜. Section 11.3 talks about client authentication of a floor control server 🫶.
as well as the connection info between the client and the floor control server, a client that wants to interact with a floor control server needs access to additional information 👑. this info links floor control interactions to the right floor instance. once a connection has been established and authenticated (see [RFC4582] for authentication details), a specific floor control message needs detailed info to uniquely identify a conference, a user, and a floor 🔥.
the conference is uniquely identified by the conference object ID per Section 6.2.1 🌈. this conference object ID must be included in all floor control messages. when the SDP model is used as described in [RFC4583], this identifier maps to the 'confid' SDP attribute 💖.
each authorized user associated with a conference object is uniquely represented by a conference user ID per Section 6.3 🦋. this conference user ID must be included in all floor control messages. when using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling protocol, the unique conference user identifier is contained in the 'userid' SDP attribute, as defined in [RFC4583] ✨.
a media session within a conferencing system can have any number of floors (0 or more) that are represented by the conference identifier 🧚. when using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 . each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers 🍓. the identifiers represent individual SDP media sessions (as defined using 'm=' from SDP) using the SDP 'Label' attribute, as defined in [RFC4574] 💅.
9. Conferencing Scenario Realizations 🌈
this section covers how advanced conferencing scenarios, many of which are described in [RFC4597], get realized using this centralized conferencing framework 🦋. the goal is to further illustrate the model, mechanisms, and protocols from the earlier sections, and also to check that they're good enough to support advanced conferencing scenarios 👑.
the scenarios give a high level, primitive view of the necessary operations and the general logic flow ✨. the details in the scenarios are for illustrative purposes only 🙈. they don't necessarily reflect the actual structure of the conference control protocol messages, or the detailed data (including states), which are defined in separate documents 💀. it's also worth noting that not all entities affected by the request are shown in the diagram (e.g., focus). the emphasis is on the new entities introduced by this centralized conferencing framework 🫶.
9.1. Conference Creation 💖
there are different ways to create a conference 🌸. a participant can create a conference using call signaling means only, such as SIP detailed in [RFC4579] 📞. but if a conferencing client wants more flexibility in defining the characteristics and capabilities of a conference, it would implement a conference control protocol client 💅. by using a conference control protocol, the client can determine the capabilities of a conferencing system and its various resources 🔥.
Figure 8 shows an example of one client "Alice" figuring out which conference blueprints a particular conferencing system has available, and then creating a conference based on the blueprint she wants 🎀.
+--------------------------------+
| Conferencing System |
"Alice" | +------------+|
+--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+|
blueprintZ, | |
confUserID> | |
"Alice" |
+--------+ | |
| |CCP Request <reserve, | +------------+|
| | blueprintAConfObjID,| +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| | confUserID> | |Control |~~~>|BlueprintA ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <reservationConfObjID, | | | \|/ |
confID> | | | /|\ |
| | | V |
| | | +------------+|
| | |~~~>|Conference ||
| | | |Reservation ||
| +-----------+ +------------+|
"Alice" | | |
+--------+ | | |
| |CCP Request <add, | V |
| |reservationConfObjID, | +-----------+ +------------+|
| Client |-------------------------->|Conference | |Active ||
| | confID,confUserID> | |Control |~~~>|Conference ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <activeConfObjID, | | | |
confID> | +-----------+ |
+--------------------------------+
Figure 8: Client Creation of Conference Using Blueprintswhen the conferencing system gets the conference control protocol request for blueprints, it first authenticates "Alice" (and allocates a conference user identifier, if necessary) 🔐. then it makes sure "Alice" has the right authority, based on system policies, to receive any blueprints the system supports 👑. any blueprints "Alice" is authorized to use get sent back in a response, along with the conference user ID 💜.
once "Alice" gets the conference control protocol response with the blueprints, she picks the one she wants to use for the conference she's making 🌈. she creates a conference object based on that blueprint (i.e., clones it) and tweaks the applicable fields, like the membership list and the 'start' time ✨. then she sends a request to the conferencing system to create a conference reservation based on the updated blueprint 🦋.
when the conferencing system gets the conference control protocol request to "reserve" a conference based on the blueprint in the request, it checks that the blueprint is valid (i.e., the values of the various field are within range) 🧐. it works out the right read/write access for any users being added to the conference, based on this blueprint (using membership, roles, etc.) 💅. the system uses the received blueprint to clone a conference reservation 🍓. it also reserves or allocates a conference ID to be used for any later protocol requests from any of the members of the conference 🎀. the system keeps track of the mapping between this conference ID and the conference object ID linked to the reservation, through the conference instance 🫶.
once "Alice" gets the conference control protocol response to the reserve request, she can make an active conference from that reservation, or make more reservations based on the existing ones 🌸. in this example, "Alice" reserved a meetme conference bridge 🔥. so she gives the conference info, including the necessary conference ID, to the participants she wants 🧚. when the first participant (including "Alice") asks to be added to the conference, an active conference and a focus get created 💖. the focus is associated with the conference ID from that request 👑. any participants who have the authority to manipulate the conference get the conference object identifier of the active conference object in the response 🌈.
9.2. Participant Manipulations 💅
okay so there are a bunch of ways to change a participant's state in a conference bestie 🦋 A participant can join and leave using call signaling only, like SIP. That's called "1st party signaling" and it doesn't touch anyone else's state in the conference 🌸
Limited operations for controlling other participants ("3rd party control") through the focus are also possible with call signaling alone, depending on the signaling protocol ✨ For example, "Conferencing for SIP User Agents" [RFC4579] shows how SIP with REFER can get this done 💜
For richer conference control, a user client needs to implement a conference control protocol client 🎀 With a conference control protocol, the client can change its own state, the state of other participants, and the state of various resources (like media mixers) that can indirectly affect any of the conference participants 🧚
Figure 9 shows one client "Alice" affecting the state of another client "Bob" 👑 This example assumes an established conference, and "Alice" wants to add "Bob" to it 😭
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+
"Bob"Figure 9: Client Manipulation of Conference - Add a Party
When the conference control protocol request to "add" a party ("Bob") arrives, identified by the conference object ID, the conferencing system checks that "Alice" has the right authority based on the policies tied to that conference object 🫶 It also has to figure out whether "Bob" is already a user of this conferencing system or a brand new one 🙈
If "Bob" is new to the system, a Conference User Identifier gets created for him ✨ Then, using the addressing info "Alice" gave for "Bob", the call signaling to add him to the conference gets kicked off through the focus 💖
Once the call signaling shows "Bob" was successfully added, the state gets updated, and depending on the policies, other participants (including "Bob") may be told about it through the conference notification service 🌈
9.3. Media Manipulations 🎀
there are different ways to mess with the media in a conference 🍓 A participant can change its own media streams by, for example, sending a re-INVITE with new SDP content using SIP only 🦋 That's also "1st party signaling," and it doesn't affect anyone else's state in the conference either 💅
For richer conference control, a user client needs to implement a conference control protocol client 🫶 Using that protocol, the client can manipulate the state of resources like media mixers, which may indirectly affect any conference participant 🧚
Figure 10 shows one client "Alice" affecting the media state of another client "Bob" 🌸 Same deal, an established conference is assumed. Here "Alice" has the Role "moderator" of the conference and wants to mute "Bob" in a medium-size multi-party conference 👑 His device isn't muted (and he's obviously not listening to the call), and background noise in his office is disruptive to everyone 😭💀
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+
"Bob"Figure 10: Client Manipulation of Conference - Mute a Party
When the conference control protocol request to "mute" a party ("Bob") comes in, identified by the conference object ID, the conference server checks that "Alice" has the right authority based on the policies for that conference object ✨ Then "Bob's" status gets marked as "recvonly" 🦋 and the conference object gets updated to show that "Bob's" media is not to be "mixed" with the conference media 💜
Depending on the policies, other participants (including "Bob") may get told about this change through the conference notification service 🌈
9.4. Sidebar Manipulations 🧚
okay a sidebar is basically a separate Conference instance that only exists inside a parent conference instance 💖 Even though it acts like an independent conference, it can't exist without a parent 😭 A sidebar gets created with the same mechanisms used for a standard conference, as described in Section 7.1 🎀
A sidebar's conference object is made by cloning the parent associated with the existing conference and then updating whatever's specific to the sidebar 🌸 It's implicitly linked to the parent conference object (so it's not an independent object) and is associated with the parent's conference object identifier, as shown in Figure 11 🦋 A conferencing system manages and enforces the parent and the right localized restrictions on the sidebar object, like no members from outside the parent conference instance joining, and no sidebar existing once the parent conference is terminated, etc. 🫶
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
|
|
|
+---------------------+---------------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference |
| Object | | Object | | Object |
| Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+Figure 11: Conference Object Mapping
Figure 11 shows how a conference object relates to its associated sidebar conference objects inside a conferencing system 👑 Each sidebar conference object has its own unique conference object identifier, as described in Section 6.2.1 ✨ The main conference object identifier acts as the top-level identifier for its sidebars 💅
A sidebar conference object identifier follows a lot of the same ideas as the cloning tree model in Section 7.1 🌈 A sidebar holds a subset of the members from the original conference object 🍓 A Conference Control Protocol can manipulate the properties of a sidebar conference object using that sidebar's unique conference object identifier 💜 The top-level conference object can also enforce policy on the sidebar object, kind of like how a parent is enforceable, as discussed in Section 7.1 🫶
9.4.1. Internal Sidebar ✨
okay bestie, let's talk sidebars 💅🎀 picture this: "Alice" is in an active conference with "Bob" and "Carol" 🦋 she wants a little side chat with "Bob" but she doesn't wanna lose the video from the main call 👀 (or she could just keep the main audio playing quietly in the background, both totally valid 🌸). So she starts it by asking the conferencing system to make a conference reservation based on the active conference object. And here's the lowkey iconic part: "Alice" and "Bob" stay on the main conference roster 💖 so everyone else can still see they're in the main call while the internal sidebar is happening. No cap, that's a whole vibe 😭
Check out Figure 12 below, it's literally the whole flow in one picture 🧚
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=parent, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
Figure 12: Client Creation of a Sidebar ConferenceOnce the conferencing system gets that CCP request to "reserve" a new sidebar conference (based on the active conference in the request), it clones a conference reservation for the sidebar 🪞 Quick reminder from earlier: the sidebar reservation is NOT independent of the active conference (aka the parent) 🫶 The system also reserves or allocates a conference ID that everyone in the conference uses for later protocol requests 🎫 And it keeps track of the mapping between that conference ID and the sidebar reservation's conference object ID through the conference instance. Lowkey genius 🧠
Now that "Alice" has the reply to her reserve request, she can either spin up an active conference from that reservation or make more reservations based on the existing ones ✨ She only wants "Bob" in the sidebar, so she manipulates the membership 👑 She also wants the video from the original call, but the audio limited to sidebar folks. (Or, again, she could pull the main audio at a lower volume instead 🎧.) She sends a CCP request to update the reservation and create an active conference at the same time 💅
When the system gets that update-and-create request for the sidebar (using the conference object ID), it checks that "Alice" actually has the authority under the policies attached to that conference object to do this 🔐 It also MUST validate the updated reservation info, making sure a member like "Bob" is already a user of this conferencing system 🙅♀️ Non-negotiable.
Depending on the policies, "Alice" (the one who started it) and "Bob" (the sidebar participant) might get a heads-up about his addition to the sidebar through the conference notification service 🔔 Periodt 💜
9.4.2. External Sidebar ✨
okay so 🎀 Figure 13 shows "Alice" in a full-on active conference with "Bob", "Carol", "David", and "Ethel" 💅. Then "Bob" slides a whisper into her DMs: a critical customer needs to talk to "Alice", "Bob", and "Ethel" 😭. So "Alice" creates a sidebar to chat with the customer "Fred" and invites the current crew except "Carol" and "David", who stay put in the active conference 🫶. She starts it by sending a request to the conferencing system 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 everyone else can see that hold state depends on individual and local policy 🤷♀️.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+ ||
| |CCP Response | | | |"David"| ||
+--------+ <sidebarResvConfObjID, | | | +-------+ ||
confID> | | | |"Ethel"| ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=sidebar, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | +-------+ ||
+--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | ||
| Client |<-------------------------|Notification|<~~~+-------+ ||
+--------+ "Ethel"=added, ||Service | |"Ethel"| ||
"Fred"=added,> || | +-------+ ||
"Ethel" +---| | |"Fred" | ||
+--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+|
| Client | <--------------------+ +--------------------------------+
+--------+ "Ethel"=added,"Fred"=added,>
Figure 13: Client Creation of an External SidebarOnce the conference control protocol request to "reserve" a new sidebar arrives, the conferencing system uses the active conference from that request to clone a conference reservation for the sidebar 👯♀️. As covered earlier, the sidebar reservation is NOT independent of the active conference (aka the parent) 👀. The system also reserves or allocates a conference ID for any later protocol requests from members of the conference, and it keeps track of the mapping between that conference ID and the sidebar reservation's conference object ID through the conference instance 🗺️.
When "Alice" gets the conference control protocol response for that reservation, she can turn it into an active conference or create more reservations based on the existing ones 🧠. Here she only wants "Bob", "Ethel", and the new guest "Fred" in the sidebar, so she edits the membership 💁♀️. She also sets the media so sidebar participants don't receive any media from the main conference 🔇. Then she sends a conference control protocol request to update the reservation and create the active conference 🚀.
When the server gets that update-and-create request for the sidebar (identified by its conference object ID), it checks that "Alice" has the right authority under the policies attached to that specific conference object 🛂. It also has to validate the updated reservation info, including whether members like "Fred" are already users of this conferencing system or brand new 🧐. Since "Fred" is new here, a conference user identifier gets created for him ✨. Using the addressing info "Alice" gave for "Fred", call signaling to add him to the conference is kicked off through the focus 📞.
Depending on policy, the person who made the request ("Alice") and the sidebar participants ("Bob" and "Ethel") may get notified that "Fred" was added to the sidebar through the conference notification service 🔔. Main character energy, honestly 👑🦋
9.5. Floor Control Using Sidebars 🎤
Okay so floor control with sidebars can totally set up an analyst briefing 💼✨. Picture this: the main call has a panel of speakers who can talk freely in the main conference. Everyone else is the analysts, and they stay muted unless they have the floor. To ask a question, they have to hop into a new sidebar with the moderator 🙋♀️. The moderator can also whisper to each analyst about their spot in the floor control queue, kinda like the vibe of Figure 15 below.
Here's the setup in Figure 14 🦋. Same as the earlier sidebar examples, there's a main conference plus a sidebar. "Alice" and "Bob" are the main participants, and "A1", "A2", and "A3" are the analysts. The sidebar stays active the whole time, with the moderator "Carol" as the chair. As discussed previously, the sidebar conference is NOT independent of the active conference (i.e., parent). The analysts get the conference object ID for the active sidebar when they join the main conference. The conferencing system also hands out a conference ID for any later manipulations of the sidebar conference, and it keeps track of the mapping between that conference ID and the sidebar's conference object ID through the conference instance. The analysts are permanently muted in the main conference and only get moved to the sidebar when they want to speak. Only one analyst gets the floor at a time. Everyone in the main conference hears audio from the sidebar, plus audio from the panelists in the main conference 🔊.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"A1" | ||
| |Server | +-------+ ||
| | | |"A2" | ||
| | | +-------+ ||
| | | |"A3" | ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | |Active ||
| +-----------+ |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Request <"A1", |+------------+ +-------+ ||
| |------------------------->|Floor Ctrl | |"Carol"| ||
|Client | activeSideConfObjID,||Server |~~~>| | ||
+--------+ confID > || | +-------+----+|
|+------------+ | |
| V |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Granted <"A1", |+------------+ +-------+ ||
| |<-------------------------|Floor Ctrl |<~~~|"Carol"| ||
| Client | activeSideConfObjID,||Server | +-------+ ||
+--------+ confID > || | |"A1" | ||
|+------------+ +-------+----+|
+--------------------------------+Figure 14: Floor Control with Sidebars
When "A1" wants to ask a question, he sends a Floor Request message to the floor control server. Once it gets the request, the floor control server lets the moderator, "Carol", know about it in the active sidebar conference, since she's the one serving as floor chair 👑. Note, that this signaling flow isn't shown in the diagram. Since no other analysts have asked for the floor yet, "Carol" tells the floor control server that "A1" may be granted the floor 🎀.
9.6. Whispering or Private Messages 🤫
Private messages can be handled as a sidebar with just two participants, kinda like Section 9.4.1, but rather than using audio in the sidebar, "Alice" could add an extra text based media stream to it 💬. The other context, called whisper, here refers to situations involving one time media targeted to specific user(s). Think of an announcement that's injected only to the conference chair or to a new participant who just joined. Iconic behaviour, honestly 🧚.
Figure 15 shows one user, "Alice", chairing a fixed length conference with "Bob" and "Carol". The setup is such that only the chair gets a warning when there are only 10 minutes left in the conference. At that time, "Alice" is moved into a sidebar created by the conferencing system, and only "Alice" receives the announcement 📣.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"Carol"| ||
| |Server | +-------+----+|
| | | | |
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ |Sidebar ||
"Alice" | |Conference ||
+--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification| | | ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to "Alice"~~~
| +-----------+ |
| |Conference | |
| |Control | |
| |Server | |
| | | |
| | | \---------+--/|
| | | |\ /||
| | |~~~>+ \ / ||
| | | | \ / ||
| +-----------+ |Sid\bar / ||
"Alice" | |Conf\re/ce ||
+--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ ||
| |<-------------------------|Notification|<~~~| /\| ||
| Client | activeSideConfObjID,||Service | |"Ali/ce\ ||
+--------+ confID > || | +---/---+\---+|
|+------------+ / \ |
+--------------------------------+Figure 15: Whisper
When the conferencing system works out that there are only 10 minutes left in the conference "Alice" is chairing, it skips the reservation step from Section 9.4.1 💅. Instead, it directly creates an active sidebar conference, based on the active conference associated with "Alice". As discussed previously, the sidebar conference is NOT independent of the active conference (i.e., parent). The conferencing system also allocates a conference ID for any subsequent manipulations of the sidebar conference, and it maintains the mapping between that conference ID and the conference object ID associated with the active sidebar conference through the conference instance.
Right when the active sidebar conference is created, the announcement media is provided to "Alice". Depending upon the policies, "Alice" may be notified of her addition to the sidebar via the conference notification service. "Alice" keeps receiving the media from the main conference 🌈.
Once the announcement is done, "Alice" is removed from the sidebar, and the sidebar conference is deleted 🫶. Depending upon the policies, "Alice" may be notified of her removal from the sidebar via the conference notification service.
9.7. Conference Announcements and Recordings ✨
okay so every participant can ask the system for a different kind of announcement or recording service, bestie 🎀 For example, "Alice" is the conference chair, so she could be listening to a roll call 📋 while "Bob" is using a telephony user interface to set up a sidebar 🧚. Some announcements are for everyone, like "This conference will end in 10 minutes" ⏰. Recording is often needed to capture participants' names as they join. This usually happens after the participant enters an access code, which we'll get to in Section 9.8 💜. The recorded names are then announced to all the participants as the new person is added to the active conference 🫶.
An example of a conference recording and announcement, including collecting the dual tone multi-frequency (DTMF) digits, is shown in Figure 16 in this framework 💅.
+--------------------------------+
| Conferencing System |
"Alice" | +-----------+ |
+--------+ | |Conference | |
| |CCP Request < | |Control | |
| Client |--------------------------->| |Server | |
| |Bob's Conference ID, | | | |
+--------+ Join > | | | |
| | | |
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Digits collected from "Alice"~~~
| ~ ~ +---------+--+|
| | |~~~>|policies | ||
| | | +---------+ ||
| | | |Active ||
| | | |Conference ||
| | | +-------+ ||
| | | |"Bob" | ||
| | | +-------+ ||
| | | |"Carol"| ||
| | | +-------+----+|
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Alice records her name ~~~
| ~ ~ +---------+--+|
| | | |policies | ||
| | | +---------+ ||
| | |~~~>|Active ||
| +-----------+ |Conference ||
| +-------+ ||
| |"Bob" | ||
"Bob " | +-------+ ||
+--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| ||
| |<-------------------------|Notification| +-------+ ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to All Parties~~~
| |
+--------------------------------+
Figure 16: Recording and Announcementsokay so picture this 🦋 When the system gets the conference control protocol request from "Alice" to join "Bob's" conference, it matches the identifier in that request to the conference object for "Bob's" active conference 🔍. The system figures out that this particular conference needs a password, so "Alice" gets an announcement asking her to enter it 🔐. Once she types it in, it gets checked against the policies attached to "Bob's" active conference ✅. Then the system connects to a server that prompts "Alice" for her name and records it 🎙️. The system must also figure out whether "Alice" is already a user of this conferencing system or whether she's brand new 👀.
If "Alice" is a new user, the system creates a conference user identifier for her 🆕. Using the addressing information "Alice" gave, the call signaling to add her to the conference is started through the focus 📞.
Once the call signaling shows that "Alice" was successfully added to the specific conference, and the state gets updated, other participants (like "Bob") get notified about it through the conference notification service 🔔. Depending on the policies, an announcement also goes out to all the participants saying "Alice" has joined 🎉. iykyk, it's giving main character entrance 👑✨.
9.8. Monitoring for DTMF 🎀
the conferencing system also needs to be able to keep an ear out for DTMF from each individual participant 👂. This is usually how people enter the identifier and/or access code to join a specific conference 🔑.
An example of DTMF monitoring, within the context of the framework elements, is shown in Figure 16 💖.
9.9. Observing and Coaching ✨
okay so the observing capability lets someone with the right authority listen in on a conference, usually without being an active participant and often as a hidden participant 👀. When a conferencing system has this, there's often an announcement that plays for each participant as they join, saying the call may be monitored 📢. It's super useful when a conference is having technical difficulties, because a technician can listen in and figure out what kind of problem it is 🔧.
This could also totally slay in call center apps 💅, since it gives a supervisor a way to watch how an agent handles a call with a customer 🎧. The supervisor adds themselves to the existing active conference with a listen-only audio media path, and that's the whole trick ✨. Whether the agent knows when the supervisor joins should be configurable ⚙️.
Now take the supervisor thing one step further and the agent can hear the supervisor and the customer, while the customer can still only hear the agent 🫶. This is done by creating a sidebar with just the agent and the supervisor 🍓. Both the agent and the supervisor receive the audio from the main conference. When the agent talks, the customer hears it in the main conference. When the supervisor talks, only the agent hears it, in the sidebar conference 🤫.
Here's an example in Figure 17 🦋. Call center agent "Bob" is on a conference with customer "Carol". Since "Bob" is new and "Alice" notices he's been on the call with "Carol" for longer than normal, she decides to observe the call and coach "Bob" as needed 🌸.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | | ||
+--------+ | | ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID> | | | +------------+|
| | | | | | |
| | | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | "chair"="Alice" ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+Figure 17: Supervisor Creating a Sidebar for Observing/Coaching
Okay this part is so cool 🧚. When the conferencing system gets the conference control protocol request from "Alice" to "reserve" a new sidebar conference, it looks at the active conference in that request and uses it to clone a conference reservation for the sidebar 🪞. It also reserves or allocates a conference ID, which gets used for any later protocol requests from any of the members of the conference 🎀. The conferencing system keeps track of the mapping between that conference ID and the conference object ID for the sidebar reservation, through the conference instance 🗂️.
Once "Alice" gets the conference control protocol response to reserve the conference, she can create an active conference from that reservation, or make more reservations based on the existing ones 💜. Here, "Alice" only wants "Bob" in the sidebar, so she manipulates the membership 👑. She also wants her and "Bob" to receive 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 that both "Alice" and the customer "Carol" hear the same audio from "Bob" 🫧. So "Alice" sends a conference control protocol request to update the info in the reservation and create an active conference 🚀.
When the conferencing system gets that request, it checks that "Alice" has the right authority, based on the policies tied to that specific conference object, to do the operation 🔐. Then, using the addressing info "Alice" gave for "Bob", the call signaling to add "Bob" to the sidebar with the right media characteristics gets kicked off through the focus 📞.
Last step: "Bob" is told he's been added to the sidebar through the conference notification service 🔔. So he knows "Alice", the supervisor, is there to coach him through this call 🥹💖.
10. Relationships between SIP and Centralized Conferencing Frameworks 🌈
The SIP Conferencing Framework [RFC4353] gives an overview of a wide range of centralized conferencing solutions that exist in the conferencing industry today 🗺️. It introduces terminology and logical entities to organize that overview and show the common core of many of these systems 🧩. The logical entities and the listed scenarios in the SIP Conferencing Framework are used to illustrate how SIP [RFC3261] can be used as a signaling means in these conferencing systems 📡. The SIP Conferencing Framework doesn't define new conference control protocols for the general conferencing system 🙅. It only uses basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] for basic SIP conferencing realization 💜.
This centralized conferencing framework document defines one particular centralized conferencing system and the logical entities that implement it ✨. It also defines a particular data model, and it refers to the set of protocols (beyond call signaling) that the logical entities use to implement advanced conferencing features 🎀. The goal of the XCON Working Group and this framework is to get interoperability between logical entities from different vendors, so they can control different aspects of advanced conferencing applications 🤝.
The logical entities in the two frameworks are not meant to map one-to-one 🙈. The two frameworks interpret the internal decomposition of the conferencing system differently, along with the operations that go with it 🔍. Still, basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] are fully compatible with both framework documents 💅. That compatibility comes from including the basic data elements defined in [RFC4575] in the Conference Information Data Model for Centralized Conferencing (XCON) [XCON-COMMON] 🫶. User agents that only support [RFC4579] and don't support the Conferencing Control Protocol still get basic SIP conferencing, but they can't use any of the advanced features 😭.
11. Security Considerations 🔒✨
okay bestie, security is where this gets dramatic 😭 there are SO many ways things can go wrong, because you've got multiple endpoints AND a bunch of features that users trigger themselves 💀 like:
- an endpoint sneaking in to listen to conferences it isn't authorized to join 👀
- an endpoint trying to disconnect or mute other users 🙅♀️
- theft of service, where an endpoint tries to create conferences it isn't allowed to create 🫢
there are a few issues to think about here 💅. the first set is about actually securing the protocols and their authorization mechanisms. that should be handled in the specs for the protocols from Section 8 and in policy control 🔐. any protocols used to manipulate or fetch confidential info need a confidentiality and integrity mechanism, and the floor control protocols need the same kind of protection 🫶. Section 11.3 covers a way for clients to authenticate a floor control server. and it is RECOMMENDED that every protocol that talks to the conferencing system implements Transport Layer Security (TLS) 🔥.
then there's authorization for doing things on the system and invoking specific capabilities 👑. Section 5.2 is all about the policies on the conference object, making sure only authorized entities can manipulate the data to reach those capabilities. and another set is about the privacy and security of a user's identity in the conference, which Section 11.2 digs into 🌸.
last but not least, Denial of Service (DoS) attacks on the conferencing system itself 💀. to cut down on the chances of DoS, it is recommended that conferencing systems require user authentication and authorization for any client joining a conference 🛡️. it is also recommended that the specific signaling and media protocols include mechanisms to minimize DoS potential ✨.
11.1. User Authentication and Authorization
so a LOT of policy decisions depend on who the user is or what role they have 🎀. conferencing systems usually require users to authenticate so the system can validate their identity 🪪. there are a few ways a user can authenticate themselves to the system:
- for users joining through one of the call signaling protocols, the protocol's own user authentication mechanisms often do the job 📞
- for users joining via SIP signaling or using the conference control protocol, TLS is RECOMMENDED 🔐
the conferencing system might also know about specific users through out-of-band mechanisms, like if it assigned them passwords so they can be authorized 🗝️. sometimes (like with Public Switched Telephone Network (PSTN) users) extra authorization is needed before someone can join, maybe through an Interactive Voice Response (IVR) system or something else 📱. users can also get authorized by knowing a particular conference ID and a Personal Identification Number (PIN) for it 🔢. and sometimes there's no PIN at all, so the conference ID is basically acting as a shared secret 🤫.
if a user gets authorized through multiple mechanisms, it's up to the conferencing system to correlate (if it wants to) the call signaling authorization with the other mechanisms 🧩. one way to dodge the multiple-mechanism headache is to limit how a conference can be joined 🚪. for example, lots of conferencing systems with a web interface correlate PSTN call signaling by forcing a dial-out mode for joining the conference 📲. that way, only a single PIN or password is needed to get in, which is so much simpler 💖.
when a conferencing system presents the identity of an authorized user, it can choose to share how that identity was proven or verified 🕵️♀️. and a user can also come in as a completely unauthenticated user 👻. that fact needs to be communicated to anyone who cares 📣.
when guest users interact with the system, it's usually within the context of one particular conference 🎉. in that case, the user might give a PIN or password that's specific to that conference, which authorizes them to take on a certain role there 🎭. the guest can then do anything that's allowed for any user with that role ✨.
a quick terminology note: "password" means the usual, reasonable-sized, hard-to-predict shared secret. today, users often have passwords with up to 30 bits (8-16 characters) of entropy 🔑. a PIN is a special kind of password, a shared secret that's only numeric and often has a pretty small number of bits (sometimes as few as 10 bits, or 3 digits) 🔢. when conferencing systems are used for audio over the PSTN, authenticating with a PIN is often needed 📞. usually, if someone gets the PIN wrong a few times in a row, the PSTN call gets disconnected 📴. the rate at which calls get made and reach the PIN prompt makes it pretty hard to exhaustively search the PIN space, even for 4 digit PINs 🙅♀️. but over a high speed interface, it's often possible to make thousands of attempts per second, and the PIN space could get searched really fast 😱. because of that, PINs are not appropriate for authorization on any interface that offers fast queries or lots of simultaneous queries 🚫.
once a user is authenticated and authorized through the various mechanisms on the conferencing system, a conference user identifier gets associated with any signaling-specific user identifiers that were used for authentication and authorization 🆔. that conference user identifier may be given to a specific user through the conference notification interface, and it will be given to users who interact with the system using the conference control protocol 💌. this conference user identifier is required for any later operations on the conference object 🔑.
11.2. Security and Privacy of Identity
okay so this conferencing system knows who each user is 👀, but that doesn't mean it can reveal that identity to other users, because privacy matters 🫶. users can pick from a few options for how much of their identity gets revealed 🎭. a user can be "hidden", which means other users can't even see they're in the conference 🥷. a user can be "anonymous", which means other users can tell someone is there but can't see who they are 🎭. or a user can be "public", where other users can see their identity 🌈. if there are multiple "anonymous" users, everyone else will see them as separate "anonymous" parties, and they'll be able to tell how many "anonymous" parties are in the conference 🔢.
ngl, who can see what depends on their role 👑. for example, users' identities (including "anonymous" and "hidden" ones) may be shown to the moderator or administrator, depending on the conferencing system's local policies 🧐. "hidden" status is often used by automated or machine participants of a conference (like call recording), and it's also used a lot in call center situations 📼.
since a conferencing system based on this framework gives every user its own unique conference user identifier, there's no need to share any signaling-specific user identifiers with other users or participants 🙅♀️💖. and if you do need to control access to those signaling-specific user identifiers, you can apply the right access control to them in the data schema 🗂️.
11.3. Floor Control Server Authentication
the floor control protocol has mechanisms that clients can use to authenticate servers, and that servers can use to authenticate clients 🤝. this is described in Section 9 of [RFC4582] 📖. the exact mechanisms used for this can change depending on which call control protocol is in use 🔄. clients using call control protocols that employ an SDP offer/answer model, like SIP, use the mechanism described in Section 8 of [RFC4583] 🎯. clients using other call control protocols use the mechanisms described in the BFCP Connection Establishment document [RFC5018] 📄.
12. Acknowledgements 🙏💜
this document is the result of architectural discussions among IETF XCON Working Group participants 🌷. the authors want to say a huge thank you to Henning Schulzrinne for the "Conference Object Tree" proposal and general feedback 🎀, and to Cullen Jennings for input on the "Security Considerations" section 🔐. thank you also to Keith Lantz, Dave Morgan, Oscar Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan Mahy, Brian Rosen, Pierre Tane, Bob Braudes, Gregory Sperounes, and Gonzalo Camarillo for their reviews and constructive input 🫶✨. and extra love to Scott Brim for his gen-art review comments and Kurt Zeilenga for his secdir review comments 💅🌈.
13. References 📚
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.13.2. Informative References 📚🎀
okay so these are the "fyi, go read this if you want the full tea" references 🧚 they aren't required to get the main spec, but they're the receipts behind it 💅
[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🌸[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. 📞✨[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 🤝[RFC3265]Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 🔔[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎙️[RFC2445]Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. 🗓️[RFC4245]Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. 💜[RFC4353]Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. 🧩[RFC4575]Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. 👀[RFC4376]Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006. ✋[RFC4597]Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, 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. 🍓[RFC4574]Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. 🏷️[RFC4583]Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006. 🌈[XCON-COMMON]Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", Work in Progress, March 2008. 🚧[RFC4975]Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. 💌[RFC5018]Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007. 🔥
Authors' Addresses 💖
Meet the squad who wrote this 🫶
Mary Barnes
Nortel
2201 Lakeside Blvd
Richardson, TX
EMail: mary.barnes@nortel.com
Chris Boulton
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
EMail: cboulton@avaya.com
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: oritl@microsoft.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🪞
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5239 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms