RFC 4353
A Framework for Conferencing with the Session Initiation Protocol (SIP)
A Framework for Conferencing with the Session Initiation Protocol (SIP) ✨
Part 1 of 6 💖
Okay bestie, this is RFC 4353 📄, and it's all about how to set up group calls with SIP. It was written by J. Rosenberg at Cisco Systems and dated February 2006. It's in the Informational category 🎀, so it's sharing knowledge with the Internet community, not laying down a standard. The title block doesn't list anything it obsoletes or updates, so it's standing on its own, periodt 💅.
Status of This Memo 📜
This memo is here to give information to the Internet community 🌸. It is not an Internet standard of any kind. Distribution of this memo is unlimited 🦋.
Copyright Notice ©️
Copyright (C) The Internet Society (2006) 💜.
Abstract 🌈
Okay so SIP handles starting, changing, and ending media sessions between user agents ☎️. Those sessions are run by SIP dialogs, which are basically a SIP relationship between two user agents. Since dialogs are always between a pair of user agents, using SIP for a two-person call (like a regular phone call) is super obvious 🙄✨. Calls with lots of people, usually called conferencing, are way more complicated 😭. This document lays out a framework for how conferencing can happen 🎀. It covers the overall architecture, the terminology, and the protocol pieces you need for multi-party conferencing 🫶.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................271. Introduction 🎀
So SIP [1] handles starting, changing, and ending media sessions between user agents 📞. Those sessions are managed by SIP dialogs, which are a SIP relationship between a pair of user agents 🤝. Since dialogs are always between two user agents, SIP for two-party stuff (like a phone call) is obvious 💁♀️. Multi-party sessions, though, are where it gets messy 😩. SIP can support lots of different multi-party models 🌸.
The first one is called loosely coupled conferences 🦋. These use multicast media groups. In this model there's no signaling relationship between participants, no central point of control, and no conference server 🙅♀️. Participation is figured out slowly through control info that gets passed along as part of the conference, like with the Real Time Control Protocol (RTCP) [2] 📡. Loosely coupled conferences are easy to do in SIP by using multicast addresses inside session descriptions ✨.
The second model is fully distributed multiparty conferencing 💫. Here, each participant keeps a signaling relationship with every other participant using SIP. There's no central point of control, it's totally spread out across the participants 🌐. This model is outside the scope of this document 🙈.
The third is the tightly coupled conference, which has a central point of control 👑. Every participant connects to that central point. It offers a bunch of conference functions and might also do media mixing 🎛️. RFC 3261 doesn't directly cover tightly coupled conferences, though basic participation is possible without any extra protocol support 💅.
This document gives the overall framework for tightly coupled SIP conferencing, which from here on we'll just call "conferencing" 🧚. It sets out a general architectural model, defines the terminology used to talk about these conferences, and covers how SIP itself is involved in conferencing 💖. The goal is to meet the general conferencing requirements outlined in [3] 🎯. This spec also mentions some non-SIP-specific mechanisms for doing several conferencing functions, but those mechanisms are outside its scope 🌈.
2. Terminology 📖
- Conference: Conference is an overused term with different meanings in different contexts 😵💫. In SIP, a conference is an instance of a multi-party conversation. In this specification, a conference is always a tightly coupled conference 🫶.
- Loosely Coupled Conference: A loosely coupled conference is a conference without coordinated signaling relationships among participants 🦋. These conferences often use multicast to distribute conference memberships 📡.
- Tightly Coupled Conference: A tightly coupled conference is a conference in which a single user agent, called a focus, keeps a dialog with each participant 👑. The focus is the centralized manager of the conference and is reached through a conference URI 🎀.
- Focus: The focus is a SIP user agent that's addressed by a conference URI and identifies a conference (remember, a conference is a unique instance of a multi-party conversation) 💅. The focus keeps a SIP signaling relationship with each participant in the conference 🤝. It's responsible for making sure, in some way, that each participant gets the media that make up the conference 🎶. It also implements conference policies 📜. The focus is a logical role 🧠.
- Conference URI: A URI, usually a SIP URI, that identifies the focus of a conference 🔗.
- Participant: The software element that connects a user or automata to a conference 💜. It implements, at a minimum, a SIP user agent, but it can also implement non-SIP-specific mechanisms for extra functionality ✨.
- Conference State: The state of the conference includes the state of the focus, the set of participants connected to the conference, and the state of their respective dialogs 📊.
- Conference Notification Service: A conference notification service is a logical function provided by the focus 🔔. The focus can act as a notifier [4], accepting subscriptions to the conference state and notifying subscribers about changes to that state 📬.
- Conference Policy Server: A conference policy server is a logical function that can store and manipulate the conference policy 🗃️. This function isn't specific to SIP and may not physically exist 👻. It's the component that interfaces a protocol to the conference policy 🔌.
- Conference Policy: The complete set of rules governing a particular conference 📋.
- Mixer: A mixer receives a set of media streams of the same type, combines their media in a type-specific way, and redistributes the result to each participant 🎛️. This includes media sent using RTP [2] 🎶. So the term here is a superset of the mixer concept defined in RFC 3550, since it also covers non-RTP-based media like instant messaging sessions [5] 💬.
- Conference-Unaware Participant: A conference-unaware participant is a participant in a conference that doesn't know it's actually in a conference 🙈. As far as the UA is concerned, it's a point-to-point call 📞.
- Cascaded Conferencing: A mechanism for group communications in which a set of conferences are linked by having their focuses interact in some fashion 🔗✨.
- Simplex Cascaded Conferences: A group of conferences linked so that the user agent representing the focus of one conference is a conference-unaware participant in another conference 🪆.
- Conference-Aware Participant: A conference-aware participant is a participant in a conference that has learned, through automated means, that it's in a conference 🧠. It can use the conference notification service or additional non-SIP-specific mechanisms for extra functionality 🌟.
- Conference Server: A conference server is a physical server that contains, at a minimum, the focus 🖥️. It may also include a conference policy server and mixers 💜.
- Mass Invitation: An attempt to add a large number of users into a conference 📣🎉.
- Mass Ejection: An attempt to remove a large number of users from a conference 🙅♀️💀.
- Sidebar: A sidebar appears to the users within it as a "conference within the conference" 🤫. It's a conversation among a subset of the participants that the remaining participants aren't privy to 👀.
- Anonymous Participant: An anonymous participant is one that's known to other participants through the conference notification service, but whose identity is being withheld 🎭.
3. Overview of Conferencing Architecture ✨
okay so the central component (literally) in a SIP conference is the focus 💅 The focus keeps a SIP signaling relationship with every participant, so the whole thing ends up looking like a star ⭐ Check out Figure 1 below 👇
+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+
Figure 1so the focus is responsible for making sure the media streams that make up the conference are actually available to the participants 🎀 It does this with one or more mixers. Each mixer takes a bunch of input media streams and combines them into one or more output media streams. The focus uses the media policy to figure out the right way to configure the mixers.
the focus has access to the conference policy, and there's one instance of that for each conference 🔥 Basically, the conference policy is like a database that describes how the conference is supposed to operate. It's the focus's job to enforce those policies. The focus needs read access to that database, and it also needs to know when it changes. Some changes can trigger SIP signaling (like ejecting someone from the conference with a BYE), and any change that affects the conference state needs a notification sent to subscribers through the conference notification service 💌
the conference is represented by a URI that identifies the focus 💖 Every conference has its own unique focus and its own unique URI for that focus. Requests sent to the conference URI get routed to the focus for that specific conference.
users usually join by sending an INVITE to the conference URI 🧚 As long as the conference policy allows it, the focus accepts the INVITE and brings the user in. To leave, users send a BYE, same as they would in a normal call.
the focus can also end a dialog with a participant if the conference policy changes and that participant isn't allowed in the conference anymore 🙅♀️ And a focus can start an INVITE to bring a participant in too 👑
now the conference-unaware participant is a super important concept here 🙈 This participant doesn't even know the UA it's talking to is a focus. From its point of view, the UA is just like any other UA. The focus obviously knows it's a focus, and it does all the work the conference needs to run.
conference-unaware participants still get a lot of functionality 🌸 They can join and leave conferences using SIP, and they can get more advanced features through stimulus signaling, as discussed in [6]. BUT if a participant wants to explicitly control aspects of the conference using functional signaling protocols, the participant must be conference-aware.
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
Conference
Functions
Figure 2a conference-aware participant gets access to advanced functionality through extra protocol interfaces 🦋 That can include access to the conference policy through non-SIP-specific mechanisms. Figure 2 shows how this works. The participant can talk to the focus using extensions like REFER to get enhanced call control functions [7]. It can also SUBSCRIBE to the conference URI and connect to the conference notification service the focus provides. That way it can keep track of changes to participants, which basically means keeping up with the state of the dialogs and the media 👀
the participant can also talk to the conference policy server using some kind of non-SIP-specific mechanism to change the conference policy ✨ The conference policy server doesn't need to be available in any particular conference, although there is always a conference policy.
the interfaces between the focus and the conference policy, and between the conference policy server and the conference policy, are non-SIP-specific 💅 For SIP-based conferencing, they're logical roles in a conference, not a physical decomposition. They're spelled out here so the requirements stay clear. This gives individual SIP implementations the flexibility to build a conferencing system that's scalable and robust, without having to fully develop these interfaces 🫶
3.1. Usage of URIs
it's fundamental to this framework that a conference is uniquely identified by a URI, and that this URI identifies the focus in charge of the conference 🔑 No two conferences have the same conference URI, and a conference URI is always a SIP or SIPS URI.
the conference URI is opaque to any participants who might use it 🙈 You can't look at the URI and know for sure whether it identifies a focus, a user, or an interface on a PSTN gateway. This matches the general philosophy of URI usage [8]. Still, contextual info around the URI (like SIP header parameters) may show that the URI represents a conference.
when a SIP request is sent to the conference URI, it's routed to the focus, and only to the focus 💖 The element or system that creates the conference URI is responsible for guaranteeing this.
a conference URI can represent a long-lived conference or interest group, like sip:discussion-on-dogs@example.com 🐶 The focus behind a URI like that always exists and is always managing the conference for whoever is currently joined. Other conference URIs can be short-lived, like an ad-hoc conference.
ideally, a conference URI is never constructed or guessed by a user 🙅♀️ Instead, people learn conference URIs through lots of different mechanisms. A conference URI can be emailed or sent in an instant message, linked on a web page, or obtained from some non-SIP mechanism 🍓
to figure out whether a SIP URI represents a focus, standard URI capability discovery techniques can be used 🔍 The callee capabilities specification [9] provides the "isfocus" feature tag, which shows that the UA is acting as the focus in this dialog. Callee capability parameters also show that a focus supports the conference notification service. A focus does this by declaring support for the SUBSCRIBE method and the relevant package(s) in the caller preferences feature parameters associated with the conference URI.
other functions in a conference can have URIs too 🌈 If the conference policy is exposed through a web application, it's identified by an HTTP URI. If it's accessed using an explicit protocol, it's identified by a URI defined for that protocol.
starting from the conference URI, you can learn the URIs for the other logical entities in the conference using the conference notification service 🧚
4. Functions of the Elements
this section gives a more detailed description of the functions that are typically implemented in each of the elements 💜
4.1. Focus ✨
okay so the focus is literally the center of the conference 🎀 Every participant is connected to it by a SIP dialog. It's responsible for keeping those dialogs alive, and it makes sure they're only hooked up to participants who are allowed in, based on the membership policy 💅 It also uses SIP to manipulate the media sessions so every participant gets all the media for the conference. To pull that off, the focus uses mixers 🦋
When a focus gets an INVITE, it checks the conference policy first. The policy might say this person isn't allowed to join, in which case the call can get rejected 💀 It might instead say another participant, acting as a moderator, has to approve the new person 👑 In that case, the INVITE might get parked on a music-on-hold server, or a 183 response might get sent to show progress. A notification goes out through the conference notification service to the moderator. Then the moderator can let the new participant in, and the focus can accept the INVITE (or unpark it from the music-on-hold server) 🫶 How the focus reads the policy is totally a local policy thing and not something that gets standardized, so no notes on that 🙈
When a SIP participant with a confirmed dialog needs to be removed from a conference, the focus sends a BYE to that participant to take them out 😭 People call this "ejecting" a user, and "mass ejection" when it happens to a bunch of users at once. Same vibe for adding someone new: the focus sends an INVITE request to that participant, and when it's a huge group, that's called mass invitation 🎉 And if the media properties of a session need to change for a SIP participant (like turning off video, for example), the focus can update that participant's session description by sending a re-INVITE or UPDATE [15] request with a new offer 🌸
Lots of signaling stuff the focus does, like ejecting or adding someone, will change the media composition of the conference. To make those changes happen, the focus works with the mixer 🧚 Through that, it makes sure all the valid participants get a copy of the media streams, and that each participant sends media to an IP address and port on the mixer so it gets mixed in properly with everything else 🌈 How the focus talks to the mixer is outside the scope of this spec, so we're leaving that one for another day ✨
4.2. Conference Policy Server 💜
The conference policy server is a logical component of the system, not a physical box you can point at 🍓 It's the interface between clients and the conference policy that runs the conference. Clients talk to the conference policy server using a non-SIP-specific mechanism, so SIP isn't the only way in 💅
4.3. Mixers 🎀
A mixer is the one responsible for combining the media streams that make up the conference, then generating one or more output streams that get sent out to recipients (which could be participants or other mixers) 🦋 How media gets combined depends on the media type, and the focus directs the process, following the rules in the media policy 👑
A mixer isn't aware of a "conference" as an entity, per se 🙈 It just takes media streams in as inputs, and based on what the focus tells it, spits out media streams as outputs. There's no grouping of media streams beyond the policies that describe how the streams get mixed, so that's all it's got 💖
A mixer is always under the control of a focus, either directly or indirectly ✨ The focus interprets the media policy and then installs the right rules in the mixer. If the focus is directly controlling a mixer, the mixer can either live right alongside the focus, or be controlled through some kind of protocol 🧚 If the focus is indirectly controlling a mixer, it hands the mixing off to the participants, and each of them has its own mixer. That's covered in Section 6.4 🌸
4.4. Conference Notification Service 🔥
The focus can provide a conference notification service 🫶 In this role, it acts as a notifier, as defined in RFC 3265 [4]. It accepts subscriptions from clients for the conference URI, and sends them notifications whenever the state of the conference changes 📣
The state of the conference includes the participants connected to the focus, plus info about the dialogs that go with them. When new participants join, that state changes and gets reported through the notification service ✨ When someone leaves, the state changes too, and subscribers can find out about it 😭
If a participant is anonymous, the conference notification service has two options: it can withhold the identity of a new participant from the other conference participants, or it can skip telling everyone else that the anonymous participant is there at all 🙈 Which one it picks depends on the level of anonymity the anonymous participant gets 🎭
4.5. Participants 🌈
A participant in a conference is any SIP user agent that has a dialog with the focus 💅 That user agent can be a PC application, a SIP hardphone, or a PSTN gateway 📞 It can even be another focus! A conference that has a participant who's the focus of another conference is called a simplex cascaded conference 🪆 Those setups can also be used to build scalable conferences with regional sub-conferences, each one connected to the main conference 🌍
4.6. Conference Policy 👑
The conference policy holds the rules that guide how the focus operates 📜 The rules can be simple, like an access list that defines the set of allowed participants in a conference. They can also get wild, like time-of-day-based rules on participation, or rules that depend on who else is in the call 🤯 Here's the key thing: there's no restriction on what kinds of rules can go inside a conference policy 🫶
The conference policy can be manipulated with web applications or voice applications 💻 It can also be manipulated with non-SIP-specific standard or proprietary protocols 🧚
5. Common Operations 💖
There are sooo many ways users can interact with a conference 😭 They can join, leave, set policies, approve members, and so on. This section is a quick overview of the major conferencing operations and how they work. For more detailed examples of the SIP mechanisms, check out [7] 📖
Each subsection in this section also describes the SIP mechanism that supports the operation, so you get the big picture plus the nuts and bolts 🔧 Non-SIP mechanisms are possible too, but this doc doesn't go into them 🙈
5.1. Creating Conferences ✨
There are many ways a conference can get created 🎀 Creating one actually builds several elements at the same time. It results in the creation of a focus and a conference policy 🧚 It also constructs a conference URI, which uniquely identifies the focus 🦋 Since that URI has to be unique, the element that creates conferences is responsible for guaranteeing uniqueness 🔒 This can be done deterministically (by keeping records of conference URIs, or by generating URIs algorithmically), or probabilistically (by creating a random URI with a low enough chance of collision) 🎲
When conference policy gets created, it starts out with default rules that depend on the implementation 📜 If the creator wants to change those rules, they do it with a non-SIP mechanism 💅
SIP can create conferences hosted on a central server too: you send an INVITE to a conferencing application, and it automatically creates a new conference and places you into it 🌈
Creating conferences where the focus lives in an endpoint works differently 🫶 There, the endpoint itself creates the conference URI and hands it out to the other endpoints that'll be participants. What changes from case to case is how the endpoint decides to create a conference 🤔
One important case is the ad-hoc conference described in Section 6.2 🔥 There, an endpoint unilaterally decides to create the conference based on local policy. The dialogs that were connected to the UA get migrated to the endpoint-hosted focus, using a re-INVITE or UPDATE to pass the conference URI to the newly joined participants 💖
Alternatively, one UA can ask another UA to create an endpoint-hosted conference 🧚 This is done with the SIP Join header [10]. The UA that receives the Join header in an invitation may need to create a new conference URI (a new one isn't needed if the dialog being joined is already part of a conference) 👑 The conference URI then gets handed to the recently joined participants through a re-INVITE or UPDATE 🌸
5.2. Adding Participants 🦋
There are many mechanisms for adding participants to a conference 💅 In all cases, additions can be first party (a user adds themself) or third party (a user adds another user) 🫶
First person additions with SIP are trivially done with a standard INVITE 🎀 A participant sends an INVITE request to the conference URI, and if the conference policy lets them join, they get added 🎉
If a UA doesn't know the conference URI, but has learned about a dialog that's connected to a conference (say, through the dialog event package [11]), the UA can join the conference by using the Join header to join that dialog 🧚
Third party additions with SIP are done using REFER [12] 🔥 The client can send a REFER request to the participant, asking them to send an INVITE request to the conference URI. The client can also send a REFER request to the focus, asking it to send an INVITE to the participant 💖 That second technique is a huge win because it lets a client add a conference-unaware participant that doesn't support the REFER method 🙌
5.3. Removing Participants 💀
Just like additions, there are several mechanisms for departures 😭 Removals can also be first person or third person 🫶
First person departures are trivially done by sending a BYE request to the focus 👋 That ends the dialog with the focus and removes the participant from the conference. The focus can also remove a participant from the conference by sending it a BYE 💅 Either way, the focus works with the mixer to make sure the departed participant stops receiving conference media, and that media from them stops getting mixed into the conference 🌸
Third person departures can also be done with SIP, through the REFER method 🦋
5.4. Destroying Conferences ✨
Okay so, conferences can get destroyed in a few different ways 💀 and whether a given method even works for a given conference is decided by its conference policy 📋. Main character energy for the policy, honestly.
When a conference gets destroyed, its conference policy goes down with it 🪦. If anyone tries to read or write that policy after that, they get a protocol error 🙅♀️. The conference URI also becomes invalid, so any INVITE or SUBSCRIBE aimed at it gets a SIP error response. Rip 💔
Usually, if people are still in the conference when it's destroyed, the focus sends a BYE to each of them first and then destroys the conference 👋. Same vibe with the conference notification service: any subscribers get their subscriptions terminated by the server before the actual destruction happens 🫶.
Here's the wild part 🙈. SIP doesn't have an explicit "destroy this conference" button. Instead, a conference can disappear as a side effect of a user leaving, which happens with a BYE. If the conference policy says the conference is destroyed once the last user leaves, or once a specific user leaves, then when that user sends a SIP BYE request, boom, the conference is gone 💥.
5.5. Obtaining Membership Information
Participants are super curious people 👀. A participant in a conference will constantly want to know who else is there, and there are lots of ways to find that out 🔍.
The conference notification service lets a conference-aware participant subscribe and get notifications containing the list of participants 🔔. Whenever someone joins or leaves, the subscribers get notified, so you're never left out of the loop 📬. A user can also do a "fetch" [4] to grab the current listing whenever they want, no subscription needed 🧚.
5.6. Adding and Removing Media
Every conference is made up of a particular set of media that the focus is in charge of managing 🎀. For example, a conference might have a video stream and an audio stream 🎥🎙️. The participants can change which media streams are part of the conference, and when that set changes, the focus has to generate a re-INVITE to each participant so the streams get added or removed for them 🔄.
When a media stream is being added, a participant is allowed to reject it 🙅♀️. If they do, they won't receive or contribute to that stream. But rejecting a stream doesn't mean the stream is gone from the conference. It only means that particular participant isn't involved in it 🫠. The stream is still a whole thing for everyone else, bestie 💅.
A participant can also send a SIP re-INVITE themselves to add or remove a media stream 🦋. This uses the standard offer/answer techniques for adding media streams to a session [13]. And when they do this, it makes the focus generate its own re-INVITEs in response ✨.
5.7. Conference Announcements and Recordings
Announcements and recordings are a huge deal in real conferencing systems 📣. Some of the iconic features you'll see include:
- Asking a user to state their name before joining the conference, so there can be a roll call 📝
- Letting a user request a roll call, so they can hear who else is in the conference 👂
- Letting a user press some keys on their keypad to record the conference 🔴
- Letting a user press some keys on their keypad to get connected with a human operator 🧑💼
- Letting a user press some keys on their keypad to mute or unmute their line 🔇
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 3In this framework, all of these features are modeled as an application that acts as a participant in the conference 🧚♀️. You can see it in Figure 3. The conference has four participants: three real end users and the announcement application as the fourth 🎉.
If the announcement application wants to play something to everyone (like announcing a join), it just sends media to the mixer like any other participant would 📢. The announcement gets mixed in with the conversation and played to everybody 🎶.
If it wants to play an announcement to one specific user instead, it configures the conference policy so the media it generates only gets heard by that target user 🤫. Then it makes the announcement, and only the chosen recipient hears it 💌.
The announcement application can also take input from a specific user through the conference 🎹. To do this, it can use the application interaction framework [6]. That lets it collect user input, possibly through keypad stimulus, and then take actions based on it 💜.
6. Physical Realization 🌸
Now we get into the fun stuff 🤩. This section shows several physical setups for these components, so you can see how the basic functions get combined to solve all kinds of problems 🧩.
6.1. Centralized Server
In the most simplistic realization of this framework, there's just one physical server on the network 🖥️. It runs the focus, the conference policy server, and the mixers all together. This is the classic "one box" solution, and you can see it in Figure 4 📦.
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .
................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 46.2. Endpoint Server
Another important model is the locally-mixed ad-hoc conference 🎧. Picture this: two users, A and B, are in a regular point-to-point call 📞. Then A decides to conference in a third participant, C 🙌. To make that happen, A starts acting as a focus 👑. The dialog A already has with B becomes the first dialog attached to that focus. A re-INVITEs B on that dialog and changes its Contact URI to a new value that identifies the focus 🔁. A basically "mutates" from a single-user UA into a focus plus a single-user UA, and its URI changes during that mutation 🦎. Next, the focus sends an outbound INVITE to C ✉️. Once C accepts, the focus mixes the media from B and C together and sends the results back out 🎛️. A also plays the mixed media locally 🔊. Figure 5 shows this transition.
B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.
Internal
Interface
Figure 5Here's the important bit 🫶. The external interfaces in this model, between A and B and between B and C, are exactly the same as the ones you'd use in a centralized server model 🔒. User A could even run a conference policy and a conference notification service too, so participants can access them if they want 💫. Just because the focus lives on the same box as a participant doesn't change any of the behaviors or external interfaces 🌈.
6.3. Media Server Component ✨
okay so this is the model where TWO servers split the work 🫶 Figure 6 shows the whole setup:
+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 6so in this model each conference has two centralized servers 💅 One of them is the "application server," and it's the one that owns and manages the membership and media policies and keeps a dialog going with each participant. That makes it the focus everyone sees 👑 BUT it doesn't provide any media support at all 🙈 For the actual mixing, it calls in a second server, the "mixing server." This one has a focus and implements a conference policy, but it has NO conference notification service. Its conference policy tells it to accept all invitations from the top-level focus 🎀
The focus in the application server uses third party call control to connect each user's media streams to the mixing server, as needed 🦋 And if that focus gets a conference policy control command from a client, it hands it off to the media server by making the very same media policy control command to it 💜
this model is giving flexibility 🧚 The mixing server can be used as a resource for all sorts of different conferencing applications, because it's literally unaware of conference policy. It's just a "slave" to the top-level server, doing whatever it's told 😭🫶
6.4. Distributed Mixing 🌸
in a distributed mixed conference, there's still a centralized server that implements the focus, conference policy server, and media policy server 🌈 BUT there are no centralized mixers. Instead, the mixers live in each endpoint, along with a conference policy server. The focus distributes the media by using third party call control [14] to move a media stream between each participant and each other participant 🦋
the result is that if there are N participants in the conference, there's a single dialog between each participant and the focus. The session description tied to that dialog is built so the media can get passed around among everyone 🎀 Check out Figure 7:
+---------+
|Partcpnt |
media | | media
...............| |..................
. | Mixers | .
. |C.Pol.Srv| .
. +---------+ .
. | .
. | .
. | .
. dialog | .
. | .
. | .
. | .
. +---------+ .
. |Cnf.Srvr.| .
. | | .
. | Focus | .
. |C.Pol.Srv| .
. / | | \ .
. / +---------+ \ .
. / \ .
. / \ .
. / dialog \ .
. / \ .
. /dialog \ .
. / \ .
. / \ .
. / \ .
. .
+---------+ +---------+
|Partcpnt | |Partcpnt |
| | | |
| | ......................... | |
| Mixers | | Mixers |
|C.Pol.Srv| media |C.Pol.Srv|
+---------+ +---------+
Figure 7there are a few ways the media can get distributed to each participant for mixing 🍓 In a multi-unicast model, each participant sends a copy of its media to every other participant, so the session description manages N-1 media streams 💖 In a multicast model, each participant joins a common multicast group and sends a single copy of its media stream to that group. The underlying multicast infrastructure takes care of distributing the media, so every participant gets a copy ✨ In a single-source multicast model (SSM), each participant sends its media stream to a central point using unicast. The central point then redistributes the media to all participants using multicast 🔥 The focus is responsible for picking the modality of media distribution, and for handling any hybrids needed for clients with mixed capabilities 👑
when a new participant joins or gets added, the focus does the necessary third party call control to distribute media from the new participant to everyone else, and vice versa 🦋
the central conference server also exposes an interface to the conference policy 💅 Of course, the central conference server can't implement any of the media operations or policies directly 🙈 Instead, it delegates the implementation to each participant. For example, if a participant wants to switch the overall conference mode from "voice activated" to "continuous presence," they talk to the central conference policy server. That server then talks to the conference policy servers co-resident with each participant, using some non-SIP-specific mechanism, and tells them to use "continuous presence" 🎀
this model needs extra functionality in user agents, and that functionality may or may not be there 😬 so the participants must be able to advertise this capability to the focus 🫶
6.5. Cascaded Mixers 🧚
in very large conferences, it may not be possible to have one single mixer that can handle all of the media 💀 The solution is cascaded mixers. In this architecture there's still a centralized focus, but the mixing function is handled by a whole bunch of mixers scattered throughout the network 🌈 Each participant is connected to one, and only one, of the mixers. The focus uses some kind of control protocol to connect the mixers together, so that all the participants can hear each other 💜
Figure 8 shows how it all fits:
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 3 | . | | 5 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 2 | | 4 | | 6 |
+---------+ +---------+ +---------+
------- SIP Dialog
....... Media Flow
+++++++ Control Protocol
Figure 87. Security Considerations 🔐
okay so conferences literally need security features to work properly, no cap 💅 The conference policy can say that only certain people are allowed to join, or that only certain people can make new policies. Authorization decisions are a huge deal for conference apps, and having ways to set up and enforce those rules is a central idea all through this document 👑
And authorization rules need authentication to mean anything, obviously 🙄 Normal SIP authentication mechanisms should be enough for the conference authorization stuff described here ✨
Privacy is a big deal in conferencing too 🙈 Sometimes someone wants to join a call without anyone knowing they're there, just quietly listening in 🤫 Other times a participant only wants to hide their identity while still letting everyone know they're present 🦋 The conferencing system needs to provide both of these functions 💖
8. Contributors 🧚
this doc came out of chats with the conferencing design team, and the squad includes 💜
- Alan Johnston
- Brian Rosen
- Rohan Mahy
- Henning Schulzrinne
- Orit Levin
- Roni Even
- Tom Taylor
- Petri Koskelainen
- Nermeen Ismail
- Andy Zmolek
- Joerg Ott
- Dan Petrie
9. Acknowledgements 🫶
the authors gave a huge shoutout to Mary Barnes, Chris Boulton, and Rohan Mahy for their comments 🌸 they also thanked Allison Mankin for her comments and for supporting this work 💕
10. Informative References 📚
these are the references I'm pulling from, with every detail kept 🎀
[1] 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.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Campbell, B., "The Message Session Relay Protocol", Work In
Progress, October 2004.
[6] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Work In Progress, February
2005.
[7] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", Work in Progress,
February 2005.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[14] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.Author's Address 💌
this is where you can find the author, Jonathan Rosenberg, at Cisco Systems 🦋
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.netFull Copyright Statement ©️
so the legal bit: copyright belongs to The Internet Society (2006) 💜
this document is subject to the rights, licenses, and restrictions in BCP 78, and except where that says otherwise, the authors keep 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 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 doesn't take a position on whether any IPR claims about this tech are valid or how wide they are, and it also doesn't claim to have checked for any of them 🙈 info about rights for RFC docs lives in BCP 78 and BCP 79 💅
you can get copies of IPR disclosures sent to the IETF Secretariat, plus any licensing assurances, or the results of an attempt to get a general license for implementers or users, from the IETF online IPR repository at http://www.ietf.org/ipr 🌈
and the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to ietf-ipr@ietf.org 💖
Acknowledgement 🫶
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🌸
⭐ the end ⭐
📦 where this page comes from
- ietf: rfc4353 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms