RFC 4579
Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents
RFC 4579 💖 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents
Okay bestie, this is RFC 4579 🎀, and it's a Best Current Practice (that makes it BCP 119). It came out of the Network Working Group in August 2006 and was written by A. Johnston at Avaya and O. Levin at Microsoft Corporation ✨. The category is Best Current Practice, and the title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Status of This Memo
So this document is an Internet Best Current Practice for the Internet Community, and it's literally asking for discussion and suggestions for improvements 🫶. Distribution of this memo is unlimited, so share away 🦋.
Copyright Notice
Copyright (C) The Internet Society (2006). 🌸
Abstract
Okay so this spec defines conferencing call control features for the Session Initiation Protocol (SIP) ✨. It builds on the Conferencing Requirements and Framework documents to explain how a tightly coupled SIP conference actually works 🔥. We look at it from three perspectives: conference-unaware, conference-aware, and focus UAs 👑. It also covers how URIs are used in conferencing, how OPTIONS handles capabilities discovery, and how call control works with REFER, all with example call flow diagrams 🧚. Last but not least, it defines how the isfocus feature tag gets used 💜.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. SIP User Agent Conferencing Capability Types ....................3
3.1. Focus UA ...................................................4
3.2. Conference Factory URI .....................................4
3.3. Conference-Unaware UA ......................................5
3.4. Conference-Aware UA ........................................5
4. Usage of the 'isfocus' Feature Parameter ........................6
4.1. General ....................................................6
4.2. Session Establishment ......................................6
4.3. Discovery ..................................................7
5. SIP Conferencing Primitives .....................................7
5.1. INVITE: Joining a Conference Using the Conference
URI - Dial-In ..............................................7
5.2. INVITE: Adding a Participant by the Focus - Dial-Out ......11
5.3. INVITE: Manually Creating a Conference by Dialing
In to a Conferencing Application ..........................15
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods ....16
5.5. REFER: Requesting a Focus to Add a New Resource to
a Conference (Dial Out to a New Participant) ..............18
5.6. REFER: Requesting a User to Dial in to a Conference
Using a Conference URI ....................................21
5.7. REFER with REFER: Requesting a Focus to Refer a
Participant to Dial in to the Conference ..................23
5.8. Join Header Field: Dialing in to a Conference
Using a (3rd Party) Dialog Identifier .....................26
5.9. Replaces Header Field: Switching User Agents
within a Conference .......................................28
5.10. Replaces Header Field: Transferring a Point-to-Point
Session in to a Conference ...............................29
5.11. REFER with BYE: Requesting That the Focus Remove a
Participant from a Conference ............................31
5.12. Deleting a Conference ....................................33
5.13. Discovery of URI Properties Using OPTIONS ................34
6. Security Considerations ........................................36
7. Contributors ...................................................37
8. References .....................................................38
8.1. Normative References ......................................38
8.2. Informative References ....................................38
Appendix A: Creating a Conference by a Conference-Unaware UA.......401. Introduction ✨
This spec uses the concepts and definitions from the high level requirements [14] and the SIP conferencing framework [8] documents. This approach is made for tightly coupled SIP conferences 💖. In this setup, a user agent (UA), known as a participant, establishes a SIP dialog with another UA, known as a focus. The focus is the central point of control, authentication, and authorization 👑. This specification defines how a focus and participant UAs operate. Note that only the signalling (SIP) needs to be centralized in this model, so the media can be centrally mixed, distributed, or even multicast 🦋. For a full discussion of this architecture, see the SIP conferencing framework document [8].
The approach described in this document implements key functions in the conferencing framework using SIP primitives only 🎀. This lets you run simple conferences with defined functionalities using SIP mechanisms and conventions. Many other advanced functions can be implemented using additional means, but they are not in the scope of this document 🙈.
This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective 🌸. Possible applications include ad-hoc conferences and scheduled conferences.
Note that a single conference can bridge participants that have different capabilities and who potentially have joined the conference by different means (i.e., dial-in, dial-out, scheduled, or ad-hoc) 🍓.
The call control and dialog manipulation approach is based on the multiparty framework document [15] ✨. That document defines the basic approach of service design adopted for SIP, which includes the following:
- Definition of primitives, not services
- Signaling model independent
- Invoker oriented
- Primitives make full use of URIs
- Include policies for authentication, authorization, logging, etc.
- Define graceful fallback to baseline SIP
The use of opaque URIs and the ability to communicate call control context information within a URI (as opposed to using service-related header fields), as discussed in RFC 3087 [11], is fundamental to this approach 💅.
Capabilities discovery is an important feature of SIP systems, and conferencing systems can make use of such features 🧚. For a UA acting as a focus in a conference, this specification defines the usage of the 'isfocus' feature parameter 💜.
2. Terminology 🌈
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations [1]. Yes, these are the official requirement words, so read them carefully 🙈.
3. SIP User Agent Conferencing Capability Types 👑
From a conferencing perspective, the framework document lays out a bunch of possible SIP components, like conference-unaware participant, conference-aware participant, and focus ✨.
This document applies those concepts to the SIP call control part of the conferencing components 🎀. It defines normative behavior of the SIP UAs in various conferencing situations (referred to later as "scenarios") 🦋.
3.1. Focus UA 💖
A focus, as defined in the framework, hosts a SIP conference and keeps a SIP signaling relationship with each participant in the conference 👑. A focus contains a conference-aware user agent that supports the conferencing call control conventions defined in this document.
A focus SHOULD support the conference package RFC 4575 [9], behave as a notifier for that package, and indicate its support in the Allow-Events header fields in requests and responses 🫶. A focus MAY include information about the conference in Session Description Protocol (SDP) bodies sent as part of normal SIP signaling by populating the Session Information, URI, Email Address, and Phone Number SDP fields 🌸.
To support advanced features, where a session established between two endpoints can migrate to a centralized conference, a focus SHOULD support the Replaces header field [6] 🔥.
A user agent with focus capabilities could be built into end user equipment, and it would be used to create ad-hoc conferences 🧚.
A dedicated conferencing server, whose main job is to host conferences of arbitrary type and size at the same time, may allocate and publish a conference factory URI (as defined in the next section). With that, it can create an arbitrary number of ad-hoc conferences (and their focuses) using SIP call control means 💜.
3.2. Conference Factory URI 🍓
Okay so the framework says there are lots of ways a conference can be created 🦋. A conferencing server implementation is free to choose from these methods, which include non-automated means (such as an Interactive Voice Response (IVR) system), SIP, or any conference control protocol.
To automatically create an arbitrary number of ad-hoc conferences (and their focuses) using SIP call control means, a globally routable Conference Factory URI can be allocated and published ✨.
A successful attempt to call this URI results in the automatic creation of a new conference and its focus 🎀. So note that the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices 🙈.
There's a scenario showing how the conference factory URI is used in Section 5.4 💖.
3.3. Conference-Unaware UA 🌈
The simplest user agent can join a conference while ignoring all SIP conferencing-related information 💅. It's able to dial in to a conference and to be invited to one. Any conferencing information is optionally passed to and from it using non-SIP means 🧚. Such a user agent would not usually host a conference (at least, not using SIP explicitly). A conference-unaware UA only needs to support RFC 3261 [2] 🫶. Call flows for conference-unaware UAs aren't shown in general in this document, since they would be identical to those in the SIP call flows document [13] 🌸.
Note that the presence of an isfocus feature tag in a Contact header field won't cause interoperability issues between a focus and a conference-unaware UA. That's because it gets treated as an unknown header parameter and ignored, as per standard SIP behavior 🦋.
3.4. Conference-Aware UA 💖
okay bestie, a conference-aware UA is a UA that speaks the SIP conferencing call control conventions from this doc as a conference participant, on top of RFC 3261 [2] 🎀 It's giving multitasking. A conference-aware UA should be able to process SIP redirections such as described in Section 8.1.3.4 of RFC 3261 🦋
A conference-aware UA MUST recognize the 'isfocus' feature parameter 👑 It also SHOULD support REFER [4], SIP events [3], and the conferencing package [9] ✨
A conference-aware UA SHOULD subscribe to the conference package if the 'isfocus' parameter is in the remote target URI of a dialog and the conference package is listed by a focus in an Allow-Events header field 🫶 The SUBSCRIBE to the conference package SHOULD be sent outside any INVITE-initiated dialog 💅 And here's the tea: a termination of the INVITE dialog with a BYE does not necessarily terminate the SUBSCRIBE dialog 😭
A conference-aware UA MAY render to the user any information about the conference obtained from the SIP header fields and SDP fields from the focus 🌸
A conference-aware UA SHOULD render to the user any information about the conference obtained from the SIP conference package 💜
4. Usage of the 'isfocus' Feature Parameter ✨
4.1. General 🧚
okay so the main design goals for SIP extensions and conventions for conferencing are to define the minimum number of extensions and to have seamless backward compatibility with conference-unaware SIP UAs 🍓 The minimal requirement for SIP is being able to express that a dialog is a part of a certain conference referenced to by a URI. Because of these extensions, it is possible to do the following using SIP:
- Create a conference
- Join a conference
- Invite a user to a conference
- Expel a user by third party
- Discover if a URI is a conference URI
- Delete a conference
The approach taken is to use the feature parameter 'isfocus' to express that a SIP dialog belongs to a conference 🌈 The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [5], which includes the definition of the 'isfocus' feature parameter 🎀
4.2. Session Establishment 🦋
In session establishment, a focus MUST include the 'isfocus' feature parameter in the Contact header field unless the focus wishes to hide the fact that it is a focus 🙈 To a participant, the feature parameter will be associated with the remote target URI of the dialog. It's an indication to a conference-aware UA that the resulting dialog belongs to a conference, identified by the URI in the Contact header field, and that the call control conventions defined in this document can be applied ✨
By their nature, the conferences supported by this specification are centralized 👑 So typically a conferencing system needs to allocate a SIP conference URI such that SIP requests to this URI are not forked and are routed to a dedicated conference focus. For example, a globally accessible SIP conference could be well constructed with a conference URI using a Globally Routable User Agent URI (GRUU) (defined in [16]), because of its ability to support the non-forking and global routability requirements 💖
4.3. Discovery 🔥
Using the mechanism described in this section, it is possible, given an opaque URI, to determine if it belongs to a certain conference (i.e., meaning that it is a conference URI) or not 🫧 This discovery function can be implemented in SIP using an OPTIONS request, and can be done either inside an active dialog or outside a dialog. A focus MUST include the 'isfocus' feature parameter in a 200 OK response to an OPTIONS unless the focus wishes to hide the fact that it is a focus 💅
5. SIP Conferencing Primitives 🌸
The SIP conferencing call control flows presented in this section are the call control building blocks for various SIP conferencing applications as described in the conferencing requirements [14] and framework [8] documents. The major design goal is that the same SIP conferencing primitives would be used by user agents having different conferencing capabilities and implementing different applications 🧚
5.1. INVITE: Joining a Conference Using the Conference URI - Dial-In 📞
In this section, a user knows the conference URI and "dials in" to join this conference. The focus will authenticate the participant and apply authorization policy before allowing the participant to join the conference 🔐
If the UA is the first participant of the conference to dial-in, it is likely that this INVITE will activate the focus and hence the conference. However, the conference URI must have been reserved prior to its use ✨
If the conference is up and running already, the dialing-in participant is joined to the conference by its focus 🎉
To join an existing specific conference, a UA will send an INVITE with the Request-URI set to the conference URI. The focus MUST include the 'isfocus' feature parameter in the Contact header field of the 200 OK response to the INVITE 👑
An example call flow for joining a conference is shown in Figure 1 🦋
Alice Focus Bob Carol
| | |
| | Carol joins the conference |
| | |
| | INVITE sip:Conf-ID F1 |
| |<----------------------------------------|
| | 180 Ringing F2 |
| |---------------------------------------->|
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |---------------------------------------->|
| | ACK F4 |
| |<----------------------------------------|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|Figure 1. A Participant Joins a Conference Using the Conference URI.
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)
F3 SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=733413
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog, conference
Accept: application/sdp, application/conference-info+xml,
message/sipfrag
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
v=0
o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+1-888-2934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKdf334
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=43524545
Call-ID: k3l43id034ksereree
CSeq: 22 SUBSCRIBE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/conference-info+xml
Supported: replaces
Content-Length: 0
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, join, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>5.2. INVITE: Adding a Participant by the Focus - Dial-Out ✨
okay so if you want to directly add someone to a conference, the focus SHOULD send an INVITE to that person 📞 The INVITE carries a Contact header field with the conference URI and the isfocus feature parameter 🎀
ngl this part is so clever. A conference-unaware UA just ignores all the conferencing info and treats the session as a plain point-to-point call 🙈 That works because standard RFC 3261 [2] behavior is to ignore unknown header parameters like isfocus. It's giving "I don't know what that is, so I'm just gonna move on" 💅
Here's the call flow in Figure 2. Alice is already in the conference 🦋 The focus invites Carol by sending an INVITE. Once the session is up, Carol subscribes to the conference URI 🌸 Carol's SUBSCRIBE (F5) and the NOTIFY to Alice (F9) are totally independent of each other. They happen asynchronously, so one doesn't wait on the other 💜
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | |
| Focus "dials out" to add Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F1 |
| |---------------------------------------->|
| | 180 Ringing F2 |
| |<----------------------------------------|
| | 200 OK F3 |
| |<----------------------------------------|
| | ACK F4 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |Figure 2. A Focus "Dials Out" to Add a Participant to the Conference.
Now the actual messages, babe 🫶 F7 is the NOTIFY that goes to Carol:
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:alice@atlanta.example.com" state="full">
<display-text>Alice</display-text>
<endpoint entity="sip:alice@client.atlanta.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="3">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>647231</src-id>
<status>sendrecv</status>
</media>
<media id="4">
<type>video</type>
<src-id>21345</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>And F9 is the one Alice gets, showing Carol joined 🌈
F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432
Max-Forwards: 70
To: Alice <sip:alice@atlanta.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: 8820450524545
CSeq: 998 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=2450
Supported: replaces, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
<conference-info version="1" state="partial"
entity="sip:3402934234@conf.example.com">
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>5.3. INVITE: Manually Creating a Conference by Dialing in to a Conferencing Application 🧚
in this section, a user sends an INVITE to a conference server application 💅 The app (think an IVR system or a web page) exists because the system needs extra input from the user before it can actually create a conference 🎀 After a normal dialog is established, that extra info comes in, and then the conference and its focus get created ✨ Since the UA is now in a dialog with a focus, the focus will re-INVITE the user with the conference URI in Contact, plus the isfocus feature parameter 🦋
The extra info can also come in during an early dialog instead (see RFC 3261 [2] for the deets on early dialogs in SIP) 🌸 That could happen with a 183 Session Progress response sent by the conferencing application. Once the conference exists, its conference URI gets handed back in a Contact in the 200 OK 🫶
Note that this whole flow is about a human talking to a conferencing application, so any errors and failures get returned to the human 😭 Think recorded announcements, error tones, the works 💀
As the conferencing framework explains, the conference URI has to be unique across all distinct conferences within the same domain 🔥 In general, the user part of a conference URI will contain a pseudo random string 🌈
Here's the example in Figure 3. Alice uses a conference application that gets triggered when she sends an INVITE to it 🧚 Conf-App stands in for the conference application URI here. Alice's conference-aware UA finds out the conference exists from the isfocus feature parameter, and then it subscribes to the conference package so it can get notifications about the conference state 💖
Alice Focus Bob Carol
| | | |
| Alice establishes session with conference application. |
| | | |
| INVITE sip:Conf-App F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK F3 | | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
| | | |
| Alice uses the application to create the conference. |
| | | |
| INVITE Contact:Conf-ID;isfocus F5 | |
|<-------------------| | |
| 200 OK F6 | | |
|------------------->| | |
| ACK F7 | | |
|<-------------------| | |
| RTP | | |
|<==================>| | |
| | | |
| SUBSCRIBE sip:Conf-ID F8 | |
|------------------->| | |
| 200 OK F9 | | |
|<-------------------| | |
| NOTIFY F10 | | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |Figure 3. A Participant Creates a Conference Using an Application.
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods ✨
okay so this section is about making a conference with ad-hoc SIP methods 🎀 The conference factory URI from Section 3.2 does the work here, and it creates the conference automatically. This is different from the last scenario because no human has to step in. An automaton can create the conference and add participants all by itself 🤖 Since nobody schedules or reserves anything and the conference just pops into existence "on the fly," it counts as an "ad-hoc" conference creation 🦋
The best part is that the conference URI doesn't have to be known to the user ✨ A focus creates it, and the participants' UAs use it. Compared with Section 5.3, the big difference is that there's no user intervention (IVR, web page form, etc.) at all 💅
The SIP URI of the conference factory can be provisioned in the UA, like a "create new conference" button on a SIP phone 📞 It can also be discovered some other way 🧚
A SIP entity, such as a conferencing server, can tell this INVITE apart from a request to join an existing conference just by looking at the Request-URI 👀 Both requests might route to the same application, but the different URIs in the request show which service is being asked for 💜
Assuming all the security and policy requirements are met, a new conference is created, and the Contact URI in the 200 OK becomes the conference URI 🎉 That Contact header field MUST contain the 'isfocus' feature parameter so everyone knows this URI is for a conference 🫶
Here's an example call flow in Figure 4 🌸 Conf-Factory is shorthand for the conference factory URI, and Conf-ID is short for the conference URI. Alice has a conference-aware UA, and she creates a conference by sending an INVITE to the conference factory URI 💖 The conference factory application makes the conference and sends Alice to the focus with a 302 Moved Temporarily response. With proxy recursion (part of normal RFC 3261 [2] behavior), Alice might never even see that redirect. She could just get the responses from the focus, starting at message F5 😭 Once the media session is established, Alice subscribes to the conference URI she got from the Contact in the focus's 200 OK ✨
Alice Conf-Factory App Focus Bob
| | | |
| Alice creates the conference. | |
| | | |
| INVITE sip:Conf-Factory F1 | |
|------------------->| | |
| 302 Moved Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| INVITE sip:Conf-ID F4 | |
|---------------------------------------->| |
| 180 Ringing F5 | |
|<----------------------------------------| |
| 200 OK Contact:Conf-ID;isfocus F6 | |
|<----------------------------------------| |
| ACK F7 | |
|---------------------------------------->| |
| RTP | |
|<=======================================>| |
| | |
| Alice subscribes to the conference URI. | |
| | |
| SUBSCRIBE sip:Conf-ID F8 | |
|---------------------------------------->| |
| 200 OK F9 | |
|<----------------------------------------| |
| NOTIFY F10 | |
|<----------------------------------------| |
| 200 OK F11 | |
|---------------------------------------->| |Figure 4. Creation of a Conference Using SIP Ad-Hoc Methods. 🎀
5.5. REFER: Requesting a Focus to Add a New Resource to a Conference (Dial Out to a New Participant) 🦋
a SIP conference URI is basically a portal 🌈 You can use it to inject all kinds of stuff into the conference: new participants, new real-time media sources, new IM messages, and pointers to passive information references (like HTTP URIs) 💜
If you want the focus to add a new information resource to a conference, any SIP UA can send a REFER to the conference URI with a Refer-To holding the URI of the new resource 🫶 This REFER goes to the conference URI, not the conference factory URI, so the focus understands it as "bring this resource into the conference and make it visible to the participants" 👑 What the focus actually does next depends on what kind of resource it is (based on its URI) and on the focus's own policy for IM, central vs. distributed real-time media processing, and so on 🧚
Supporting the scenario where a new UA participant gets added is a big deal 🔥 It works even if the new participant doesn't support REFER and transfer call control. Only the requesting participant and the focus need to support REFER and transfer call control 💅
When the focus gets a REFER with a Refer-To header holding a SIP URI, it SHOULD send an INVITE to the new participant at that Refer-To SIP URI. That INVITE carries a Contact header field with the conference URI and the 'isfocus' feature parameter 🌸
A conference-unaware UA just ignores the conferencing info and treats the session as a plain point-to-point session 🙈
Figure 5 shows an example call flow ✨ The flow uses REFER to add a new participant, but the mechanism works for adding any resource that a URI identifies to the conference 🎀 Here Alice is already a participant. She sends a REFER to the conference URI, and the focus invites Carol by sending an INVITE 💖 Once the session is up, Carol subscribes to the conference URI. Carol's SUBSCRIBE (F11) and the NOTIFY to Alice (F15) have no dependency on each other. They happen asynchronously and independently, so don't go looking for a link there 😭
Alice Focus Bob Carol
| | | |
|<==================>| | |
| REFER sip:Conf-ID Refer-To:Carol F1 | |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus "dials out" to join Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F5 |
| |---------------------------------------->|
| | 180 Ringing F6 |
| |<----------------------------------------|
| | 200 OK F7 |
| |<----------------------------------------|
| | ACK F8 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| NOTIFY (OK) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| | SUBSCRIBE sip:Conf-ID F11 |
| |<----------------------------------------|
| | 200 OK F12 |
| |---------------------------------------->|
| | NOTIFY F13 |
| |---------------------------------------->|
| | 200 OK F14 |
| |<----------------------------------------|
| NOTIFY F15 | |
|<-------------------| |
| 200 OK F16 | |
|------------------->| |Figure 5. Participant Requests That the Focus Add a Participant to the Conference.
Here's the REFER itself, F1 🧚
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com>
Supported: replaces
Content-Length: 05.6. REFER: Requesting a User to Dial in to a Conference Using a Conference URI 📞
okay so a participant who wants to add someone new can just ask that person to send an INVITE to the conference URI 💖 and that can happen without SIP too, like dropping the conference URI in an email, IM, or web page 💌. if it's done without SIP, the flow and requirements are the exact same as Section 5.1 🫶
the SIP way to do this uses the REFER method 🦋
a UA that wants to add a new participant SHOULD send a REFER request to that participant, with a Refer-To header containing the conference URI ✨
after that, the requirements are identical to the dial-in case of Section 5.1 🎀. the inviting participant MAY also get a notification through the REFER action saying the new participant was added, on top of the notification they get through the conference package 🌸
here's the example in Figure 6 💅 it assumes Alice is already in the conference. Alice sends Bob an "out of band" REFER, which means a REFER outside of an established dialog 😭. if Bob rejects the REFER, Alice might send Bob an INVITE to set up a session first, and then send a REFER inside that dialog, which basically transfers Bob into the conference [17] 🧚
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Alice adds Bob into conference | |
| | | |
| REFER Refer-To:Conf-ID F1 | |
|---------------------------------------->| |
| 202 Accepted F2 | | |
|<----------------------------------------| |
| NOTIFY (Trying) F3| | |
|<----------------------------------------| |
| 200 OK F4 | | |
|---------------------------------------->| |
| | INVITE sip:Conf-ID F5 |
| |<-------------------| |
| | 180 Ringing F6 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F7 |
| |------------------->| |
| | ACK F8 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| NOTIFY (OK) F9 | | |
|<----------------------------------------| |
| 200 OK F10 | | |
|---------------------------------------->| |
| NOTIFY F11 | | |
|<-------------------| | |
| 200 OK F12 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F13 |
| |<-------------------| |
| | 200 OK F14 | |
| |------------------->| |
| | NOTIFY F15 | |
| |------------------->| |
| | 200 OK F16 | |
| |<-------------------| |
Figure 6. Adding a Participant to an Existing Conference.5.7. REFER with REFER: Requesting a Focus to Refer a Participant to Dial in to the Conference 🌈
so a participant can ask the focus to refer someone into the conference by sending a REFER method 💜. the Refer-To header field has the method set to REFER, and it holds an escaped Refer-To header field that contains the conference URI 🍓
heads up 👀: in Message F1 below, the Refer-To header field looks like it continues across two lines. that's just the formatting limits of this document. in a real message it would be one line, because the URI would just keep going 🙈
here's the scenario in Figure 7 🦋
Alice Focus Bob Carol
| | | |
|<==================>| | |
| Alice asks focus to REFER Bob into conference |
| | | |
|REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1
|------------------->| | |
| 202 Accepted F2 | | |
|<-------------------| | |
| NOTIFY (Trying) F3| | |
|<-------------------| | |
| 200 OK F4 | | |
|------------------->| | |
| Focus REFERs Bob to the conference |
| | | |
| | REFER Refer-To:Conf-ID F5 |
| |------------------->| |
| | 202 Accepted F6 | |
| NOTIFY (202) F7 |<-------------------| |
|<-------------------| NOTIFY (Trying) F8 | |
| 200 OK F9 |<-------------------| |
|------------------->| 200 OK F10 | |
| |------------------->| |
| | INVITE sip:Conf-ID F11 |
| |<-------------------| |
| | 180 Ringing F12 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F13 |
| |------------------->| |
| | ACK F14 | |
| NOTIFY F15 |<-------------------| |
|<-------------------| RTP | |
| 200 OK F16 |<==================>| |
|------------------->| NOTIFY (200) F17 | |
| |<-------------------| |
| | 200 OK F18 | |
| |------------------->| |
| | SUBSCRIBE sip:Conf-ID F17 |
| |<-------------------| |
| | 200 OK F19 | |
| |------------------->| |
| | NOTIFY F20 | |
| |------------------->| |
| | 200 OK F21 | |
| |<-------------------| |
Figure 7. Requesting That the Focus Refer a Participant to a
Conference.the messages go like this 🧚✨
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:bob@biloxi.example.com;method=REFER
?Refer-To=sip:3402934234%40example.com>
Supported: replaces
Content-Length: 0
F5 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
Max-Forwards: 70
To: <sip:bob@biloxi.example.com>
From: <sip:3402934234@conf.example.com>;tag=345621412
Call-ID: 5494204
CSeq: 4524323 REFER
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:3402934234@conf.example.com>
Supported: join, gruu, replaces
Content-Length: 0
F11 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: 5d4324fa84b4c76e66710
CSeq: 764 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)5.8. Join Header Field: Dialing in to a Conference Using a (3rd Party) Dialog Identifier ✨
okay so picture this 🎀 sometimes a participant wants to join a conference but all they've got is a dialog identifier for one of the legs already in there. Like, they might have learned it from the dialog package [18] or some non-SIP way of grabbing that info from another participant. Iconic resourcefulness, ngl 💅
So a UA can ask to be added to the conference by sending the focus a request with a Join [7] header field. That header holds the dialog ID of one leg of the conference, which is a dialog between another participant and the focus. 🦋
The Join header can do other conferencing call control things too. Check [7] if you want more examples and details, bestie 🧚
Here's the example in Figure 8. Alice is already a participant, and the dialog identifier between Alice and the focus is shortened to A-F. Bob knows A-F. He sends an INVITE (that's F1) to the focus with a Join header that has A-F in it, and the focus adds Bob to the conference. Main character energy 👑
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Bob requests to be added to the conference. |
| | | |
| | INVITE Join:A-F F1| |
| |<-------------------| |
| | 180 Ringing F2 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |------------------->| |
| | ACK F4 | |
| |<-------------------| |
| | RTP | |
| NOTIFY F5 |<==================>| |
|<-------------------| SUBSCRIBE sip:Conf-ID F6 |
| 200 OK F7 |<-------------------| |
|------------------->| 200 OK F8 | |
| |------------------->| |
| | NOTIFY F9 | |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |Figure 8. Adding a Participant to an Existing Conference using Join.
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: d432fa84b4c76e66710
CSeq: 8 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)5.9. Replaces Header Field: Switching User Agents within a Conference 🔁
okay this one is so relatable 💖 participants sometimes wanna swap the user agent they're chatting in (like the actual endpoint or device). You could just have one UA send a BYE to leave and the other UA send an INVITE to rejoin. But the SIP Replaces [6] primitive is literally built for this, periodt 💅
Figure 9 shows how it goes. Alice is in the conference on user agent #1, and the dialog identifier between her UA #1 and the focus is A-F. She switches to user agent #2 and sends an INVITE (F1) to the focus with a Replaces header that has A-F in it. Bob can't tell the difference, lol, no he can't, it's invisible to him 🙈 That dialog identifier might come from a non-SIP mechanism, or from SUBSCRIBE/NOTIFY and the dialog event package [18]. Her UA #2 gets added to the conference, and the focus sends a BYE to UA #1. UA #1 then cleans up after itself by sending a SUBSCRIBE with Expires:0 to end its subscription, bye bye 👋
One thing to note: the participant list (roster) doesn't necessarily change in this scenario, unless the conference state notifications include detailed info about Alice's user agents (endpoints). For the full scoop on conference package notifications, see [9] 🌸
Alice UA#1 Focus Alice UA#2 Carol
| | | |
|<==================>| | |
| | | |
| Alice switches user agents during the conference. |
| | | |
| | INVITE sip:Conf-ID Replaces:A-F F1 |
| |<-------------------| |
| | 200 OK Contact:Conf-ID;isfocus F2 |
| |------------------->| |
| | ACK F3 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| BYE F4 | | |
|<-------------------| | |
| 200 OK F5 | | |
|------------------->| | |
| SUBSCRIBE Expires:0 F6 | |
|------------------->| | |
| 200 OK F7 | | |
|<-------------------| | |
| NOTIFY Subscription-State:terminated F8 | |
|<-------------------| | |
| 200 OK F9 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F10 |
| |<-------------------| |
| | 200 OK F11 | |
| |------------------->| |
| | NOTIFY F12 | |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |Figure 9. Switching a User Agent within a Conference.
5.10. Replaces Header Field: Transferring a Point-to-Point Session into a Conference 🦋
okay so this call flow shows how a point-to-point call can get upgraded into a conference call with an external focus 📞✨
Alice and Bob already have a session going, and its dialog identifier is A-B 💖 Alice joins the conference with the focus by sending an INVITE to the Conference URI. Then she sends a REFER request to the focus, asking it to send an INVITE request to the other participant. Alice puts an escaped Replaces header field inside the URI that goes in the Refer-To header field. Bob gets the INVITE from the focus and matches the dialog in the Replaces header field to the dialog with Alice. So Bob accepts the INVITE, joins the conference, and sends a BYE to Alice to tear down their point-to-point dialog. it's giving seamless handoff 🫶
Alice Focus Bob Carol
| | | |
| Alice is in a session with Bob | |
|<=======================================>| |
| | | |
| Alice joins the conference | |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:sip:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| SUBSCRIBE F4 | | |
|------------------->| | |
| 200 OK F5 | | |
|<-------------------| | |
| NOTIFY F6 | | |
|<-------------------| | |
| 200 OK F7 | | |
|------------------->| | |
|<==================>| | |
| | | |
| Alice asks focus to REFER Bob into conference |
| | | |
| REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 |
|------------------->| | |
| 202 Accepted F9 | | |
|<-------------------| | |
| NOTIFY (Trying) F10| | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
| | | |
| Focus invites Bob to the conference |
| | | |
| | INVITE sip:Conf-ID Replaces:A-B F12 |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
| | ACK F14 | |
| |------------------->| |
| | RTP | |
| |<==================>| |
| BYE F15 | |
|<----------------------------------------| |
| 200 OK F16 | |
|---------------------------------------->| |
| NOTIFY (200) F17 | | |
|<-------------------| | |
| 200 OK F18 | | |
|------------------->| | |
| NOTIFY F19 | | |
|<-------------------| | |
| 200 OK F20 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F21 |
| |<-------------------| |
| | 200 OK F22 | |
| |------------------->| |
| | NOTIFY F23 | |
| |------------------->| |
| | 200 OK F24 | |
| |<-------------------| |
| | | |Figure 10. Transitioning a Point to Point Session into a Conference.
5.11. REFER with BYE: Requesting That the Focus Remove a Participant from a Conference 🚪💅
so if you want someone kicked out of the conference, a properly authorized SIP UA (usually the conference owner) can send a REFER to the conference URI. The Refer-To has the participant's URI, and the method is set to BYE 🙅♀️ The requestor does not need to know the dialog info between the focus and the person being removed, because the focus already knows it and fills it in when it generates the BYE request. the focus handles the messy stuff, bestie 🧚
Figure 11 shows an example. Alice and Carol are already participants, and Alice is authorized to remove members. Alice sends a REFER to the conference URI with a Refer-To header containing a URI of the form sip:carol@chicago.example.com;method=BYE.
Alice Focus Bob Carol
| | | |
|<==================>| |
| REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus removes Carol from the conference |
| | |
| | BYE sip:Carol F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| | NOTIFY Subscription-State:terminated F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY (200) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| NOTIFY F11 | |
|<-------------------| |
| 200 OK F12 | |
|------------------->| |Figure 11. Participant Requests That the Focus Remove a Participant from the Conference.
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com;method=BYE>
Supported: replaces
Content-Length: 0
F5 BYE sip:carol@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4
Max-Forwards: 70
From: <sip:3402934234@conf.example.com>;tag=5393k2312
To: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 78654 BYE
Content-Length: 05.12. Deleting a Conference 🗑️💀
the default conference policy for conferences made with the Conference Factory URI is that the conference gets deleted when the creator leaves. no drama, just vibes 👋
Figure 12 shows this flow, where the creator Alice leaves and the conference gets deleted. Also, the order of sending BYEs and final NOTIFYs doesn't matter, so no stress about it 🌸
Alice Focus Bob Carol
| | | |
|<==================>|<==================>| |
| BYE F1 |<=======================================>|
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| | BYE F3 | |
| |------------------->| |
| | 200 OK F4 | |
| |<-------------------| |
| | BYE F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| NOTIFY Subscription-State:terminated F7 |
|<-------------------| | |
| 200 OK F8 | | |
|------------------->| NOTIFY Subscription-State:terminated F9 |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
| | NOTIFY Subscription-State:terminated F11|
| |---------------------------------------->|
| | 200 OK F12 |
| |<----------------------------------------|Figure 12. Deleting a Conference.
5.13. Discovery of URI Properties Using OPTIONS 🔍
okay bestie, so a UA MAY send an OPTIONS request to check whether an opaque URI is a conference URI (aka it resolves to a focus) 👀. Bonus: the reply can also show which SIP call control extensions from this doc are supported ✨.
Quick note: the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus, or in a 200 OK answer from the focus to an INVITE, as part of the normal dialog establishment process 🎀.
Here's the vibe in Figure 13, where Alice sends an OPTIONS to a URI that resolves to a focus 💅:
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |Figure 13. Participant Queries Capabilities of URI of a Focus.
Now let's look at message F2 from Figure 13 in detail 🧚. From the response, Alice's UA learns that the URI is a conference URI, and that the responding UA is a focus that supports a bunch of SIP call control extensions 🦋.
The response details are:
F2 SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87
;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=93810874
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: refer, conference
Accept: application/sdp, message/sipfrag
Accept-Language: en
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
v=0
o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+18882934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 0 RTP/AVP 0 3 5 7
m=video 0 RTP/AVP 31 32The useful bits from each of these headers get their own breakdown in the next sections, so let's peek 👀:
- Allow 🚪: REFER, SUBSCRIBE, and NOTIFY being supported means the user agent handles call control and SIP events.
- Accept 📬: support for bodies like message/sipfrag [12] means the UA is call-control ready.
- Allow-Events 🎟️: this tells you it supports event packages like refer [4] and conference [9].
- Supported ✨: extensions like replaces, join, and gruu are on the menu.
- Contact 🏷️: the
'isfocus'feature parameter in the Contact header is the big tell. It means the URI is a conference URI and the UA is a focus. iconic 👑
6. Security Considerations 🔐
Okay, security time, and I'm not gonna be chill about it 😭. This spec defines how a focus UA and a participant UA interact in a conferencing app. So the security considerations and mechanisms from RFC 3261 [2] apply here too. There are some conference-specific things we need to talk about though 🫶.
Conferences can eat up a lot of network bandwidth and computing resources 💀. That's exactly why authentication matters even more than in a simple peer-to-peer session. As the conferencing framework [8] talks about, conferences often come with policies about conferencing resources. A focus SHOULD authenticate participants before joining them to a conference and letting them use conferencing resources 🔒. A focus can apply different policies to different participants depending on how authentication went 🎀.
A participant is chatting with a bunch of other participants through the focus, so a participant should authenticate the focus and make sure the focus used for the conference is trusted 🧐. Normal SIP authentication mechanisms work for both participant and focus authentication. That includes SIP Digest with a shared secret, certificates, or a secured SIP identity mechanism 🗝️. On top of that, a focus SHOULD support Secure SIP connections so that hop-by-hop mutual authentication and confidentiality provided by TLS can be achieved 💜.
In the SIP dialog between them, a focus uses the 'isfocus' feature tag to say it's acting as a focus. Because of that, SIP header fields like Contact SHOULD have end to end integrity 🧾. A participant and focus SHOULD support an end-to-end integrity mechanism such as S/MIME 💌.
Once a participant learns the other UA is a focus, SIP call control operations (like REFER) can be implemented, or a subscription to the focus's conference package might be attempted 🦋. The security considerations in RFC 3515 [4] apply to any REFER call control operations. A focus and participant will apply policy to decide which call control operations are allowed 📋.
A focus accepting subscriptions to the conference package must follow the security considerations in RFC 4575 [9]. Since notifications can carry sensitive information, the subscriptions should be authenticated and the notifications delivered with confidentiality and integrity protection. Since a participant is not able to authenticate other participants directly, a participant must rely on the focus to perform this authentication 🚨.
And now the big one 💖: a focus MUST support a participant's request for privacy, whether it comes through conference policy or through the signaling. For example, a participant who joins a conference and includes a Privacy header field [10] must not have identity information revealed to other participants by the focus 🙈. If other signaling protocols are used, privacy signaled through them must be respected too 🫶.
7. Contributors 🌸
We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions. Huge shoutout to them 🫶✨.
Thanks also to Miguel Garcia for his detailed last-call review and suggestions 🎀.
8. References 📚
8.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] 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.
- [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
- [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
- [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
- [7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
- [8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
- [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
- [10] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
8.2. Informative References
- [11] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
- [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
- [13] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
- [14] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
- [15] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
- [16] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
- [17] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, April 2005.
- [18] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
Appendix A: Creating a Conference by a Conference-Unaware UA 🎀
okay bestie, this section is about how a human can make a conference and add people to it when their UA has zero clue about conferencing 🫶 It lives in an appendix because this method is NOT RECOMMENDED 💀 The ad-hoc or manual ways are recommended over this one, but it's included anyway, for completeness 🌸
So the user picks a conference URI according to system rules and drops it into the Request-URI of the INVITE 💅 The focus echoes that same URI in the Contact header, as long as it follows certain addressing conventions (more on those in a sec) ✨ More people can be added through non-SIP stuff too, like posting the URI on web pages, sending it in email, IM, etc. 💌 Or the conference-unaware UA can call other people itself, establishing a session with each one and then transferring [17] them to the conference URI 📞 Note that in this setup only the human knows about the conferencing app, and the conference-unaware UA only needs to support RFC 3261 [2] and optionally call transfer 🦋
Making this work does mean the system has certain addressing conventions 🧚 A system could let the creator choose the user portion of the conference URI as a service or implementation choice, but then the URI format has to be agreed upon between the user and the system 🤝
For example, a service provider might reserve the domain conf.example.com for all conference URIs 🍓 Any URI in that domain would resolve to the focus. The focus could be configured to read an unknown user part in conf.example.com as a request for a conference to be created, with that conference URI as the Request-URI 👑 So an INVITE sent to sip:k32934208ds72@conf.example.com could be routed to the focus, which then creates the conference 🌈 This conference URI should be registered by the newly created focus so it becomes routable as a conference URI within the conf.example.com domain 💜 The returned Contact would look like this:
Contact: <sip:k32934208ds72@conf.example.com>;isfocusHeads up though: this approach relies on conventions adopted between the user and the focus 😬 and it is not robust against collisions in conference names 🙈 If a second user wanted to create a new conference and happened to pick the same user part as an existing one, that second user would get dropped into the existing conference instead of making a new one 💀
As a result, methods of conference creation in which the conference URI is an opaque URI generated by the focus are preferred ✨👑
An example call flow is shown in Figure 14 🦋 Alice creates the conference URI (using some convention agreed to with the focus domain) and sends an INVITE to that URI, which creates the focus 🎀 The focus creates the conference and returns the same conference URI in the 200 OK answer to the INVITE, which the conference-unaware UA ignores 🙈
Alice Focus Bob Carol
| | | |
| Alice creates the conference and chooses the conference URI. |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK Contact:Conf-ID;isfocus F3 | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
Figure 14. Not Recommended: Conferencing Unaware Participant
Creates a ConferenceAuthors' Addresses 💌
Alan Johnston
Avaya
St. Louis, MO 63102
EMail: alan@sipstation.com
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: oritl@microsoft.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2006). 💖
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 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.
Acknowledgement 🫶
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💜🦋
📦 where this page comes from
- ietf: rfc4579 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms