containing the URI of the participant and with the method set to BYE.
The requestor does not need to know the dialog information about the
dialog between the focus and the participant who will be removed --
the focus knows this information and fills it when it generates the
BYE request.
An example call flow is shown in Figure 11. It is assumed that Alice
and Carol are already participants of the conference and that Alice
is authorized to remove members from the conference. 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: 0
5.12. Deleting a Conference
The default conference policy for conferences created using the
Conference Factory URI is that the conference is deleted when the
creator departs.
Figure 12 shows this call flow in which the creator Alice departs
causing the conference to be deleted. Note that the order of sending
BYEs and final NOTIFYs is not important.
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
A UA MAY send an OPTIONS request to discover if an opaque URI is a
conference URI (resolves to a focus). In addition, the reply to the
OPTIONS request can also indicate support for various SIP call
control extensions used in this document.
Note that the Allow, Accept, Allow-Events, and Supported header
fields should be present in an INVITE from a focus or a 200 OK answer
from the focus to an INVITE as a part of a normal dialog
establishment process.
An example is shown 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.
Following is an example of message detail of message F2 in Figure 13.
Based on the response, Alice’s UA learns that the URI is a conference
URI and that the responding UA is focus that supports a number of SIP
call control extensions.
The response details are as follows:
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 32
Useful information from each of these headers is detailed in the next
sections.
Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY
indicates that the user agent supports call control and SIP events.
Accept. The support of bodies such as message/sipfrag [12] indicates
support of call control.
Allow-Events. Indicates support of event packages such as refer [4]
and conference [9].
Supported. Indicates support of extensions such as replaces, join,
and gruu.
Contact. The presence of the ’isfocus’ feature parameter in the
Contact header indicates that the URI is a conference URI and that
the UA is a focus.
6. Security Considerations
This specification defines the interaction between a focus UA and a
participant UA in a conferencing application. As a result, the
security considerations and mechanisms defined in RFC 3261 [2] apply.
However, there are some aspects unique to conferencing that will be
discussed here.
A conference often involves the use of substantial network bandwidth
and computing resources. As a result, authentication is even more
important than in a simple peer-to-peer session. As discussed in the
conferencing framework [8], conferences often have policy related to
conferencing resources. A focus SHOULD authenticate participants
before joining them to a conference and allowing utilization of
conferencing resources. Different policies can be applied by a focus
to different participants based on the result of authentication.
A participant will be interacting with a number of other participants
through the focus. As a result, a participant should authenticate
the focus and be sure that the focus used for the conference is
trusted. Normal SIP authentication mechanisms are suitable for
participant and focus authentication, such as SIP Digest utilizing a
shared secret, or certificates, or a secured SIP identity mechanism.
In addition, 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 utilizes the ’isfocus’
feature tag to indicate that the UA is acting as a focus. As such,
the SIP header fields such as 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 has learned that the other UA is a focus, SIP call
control operations (such as REFER) can be implemented, or a
subscription to the conference package of the focus might be
attempted. The security considerations described in RFC 3515 [4]
apply to any REFER call control operations. A focus and participant
will apply policy to determine 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.
A focus MUST support a participant’s request for privacy, either
through conference policy or as expressed through the signaling. For
example, a participant joining a conference and including 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 also must be respected.
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.
Thanks 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
This section discusses how a human user operating a conference-
unaware UA can create and add participants to a conference. This
method is described as an appendix since it is NOT RECOMMENDED. The
scenarios involving creating a conference using ad-hoc or manual
means are recommended over this scenario. This scenario is included,
however, for completeness.
A user (human) would choose a conference URI according to system
rules and insert it into the Request-URI of the INVITE. This same
URI is echoed by a focus adhering to certain addressing conventions
(discussed below) in the Contact header by the focus. Additional
participants could be added by non-SIP means (publication of the
chosen conference URI using web pages, email, IM, etc.).
Alternatively, the conference-unaware UA could then add other
participants to the conference using SIP call control by establishing
a session with them, then transferring [17] them to the conference
URI. Note that in this scenario only the user (human) is aware of
the conferencing application, and the conference-unaware UA only need
support RFC 3261 [2] and optionally call transfer.
Making this work does impose certain addressing conventions on a
system. As a service/implementation choice, a system could allow the
creator of the conference to choose the user portion of the
conference URI. However, this requires the URI format to be agreed
upon between a user and the system.
For example, a service provider might reserve the domain
conf.example.com for all conference URIs. Any URI in the domain of
conf.example.com would resolve to the focus. The focus could be
configured to interpret an unknown user part in the conf.example.com
domain as a request for a conference to be created with the
conference URI as the Request-URI. For example, an INVITE sent with
a Request-URI of sip:k32934208ds72@conf.example.com could be routed
to the focus that would then create the conference. This conference
URI should be registered by the newly created focus to become
routable as a conference URI within the conf.example.com domain. The
returned Contact would look as follows:
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
Note, however, that this approach relies on conventions adopted
between the user (human) and the focus. Also, the approach is not
robust against collisions in the conference names. If a second user
wishing to create a new conference happened to choose the same user
part as an existing conference, the result would be that the second
user would be added into the existing conference instead of creating
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. The participant 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 is ignored
by the conference-unaware UA).
Alice Focus Bob Carol
| | | |
| Alice creates the conference and chooses the conference URI. |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |