SIPPING Working Group A. Johnston
Internet-Draft MCI
Expires: January 16, 2005 O. Levin
Microsoft
July 18, 2004
Session Initiation Protocol Call Control - Conferencing for User
Agents
draft-ietf-sipping-cc-conferencing-04
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This specification defines conferencing call control features for the
Session Initiation Protocol (SIP). This document builds on the
Conferencing Requirements and Framework documents to define how a
tightly coupled SIP conference works. The approach is explored from
different user agent (UA) types perspective: conference-unaware,
Johnston & Levin Expires January 16, 2005 [Page 1]
Internet-Draft SIP CC Conferencing for UAs July 2004
conference-aware and focus UAs. The use of URIs in conferencing,
OPTIONS for capabilities discovery, and call control using REFER are
covered in detail with example call flow diagrams. The usage of the
isfocus feature tag is defined. A SIP option tag for
conference-aware UAs is defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Usage of the 'isfocus' Feature Parameter . . . . . . . . . . 4
2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Session Establishment . . . . . . . . . . . . . . . . . . 5
2.3 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SIP User Agent Conferencing Capability Types . . . . . . . . 6
3.1 Focus UA . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Conference Factory URI . . . . . . . . . . . . . . . . . . 6
3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . . 7
3.4 Conference-Aware UA . . . . . . . . . . . . . . . . . . . 7
4. SIP Conferencing Primitives . . . . . . . . . . . . . . . . 8
4.1 Joining a Conference using the Conference URI - Dial In . 8
4.2 Adding a Participant by the Focus - Dial Out . . . . . . . 11
4.3 Manually Creating a Conference by Dialing into a
Conferencing Application . . . . . . . . . . . . . . . . . 14
4.4 Creating a Conference using Ad-Hoc SIP Methods . . . . . . 15
4.5 Requesting the Focus Add a New Resource to a Conference . 17
4.6 Adding a 3rd Party Using Conference URI . . . . . . . . . 19
4.7 Requesting Focus Refer a Participant into the Conference . 21
4.8 Adding a 3rd Party Using a Dialog Identifier . . . . . . . 23
4.9 Changing User Agents within a Conference . . . . . . . . . 25
4.10 Bringing a Point-to-Point Session into a Conference . . 26
4.11 Requesting the Focus Remove a Participant from a
Conference . . . . . . . . . . . . . . . . . . . . . . . 28
4.12 Deleting a conference . . . . . . . . . . . . . . . . . 30
4.13 Discovery of Conferencing Capabilities using OPTIONS . . 31
5. Appendix - Creating a Conference by a Conference-Unaware
UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
6.1 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . 35
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 36
10. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 36
11. Changes since -01 . . . . . . . . . . . . . . . . . . . . . 36
12. Changes since -00 . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1 Normative References . . . . . . . . . . . . . . . . . . . 37
13.2 Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
Johnston & Levin Expires January 16, 2005 [Page 2]
Internet-Draft SIP CC Conferencing for UAs July 2004
Intellectual Property and Copyright Statements . . . . . . . 39
Johnston & Levin Expires January 16, 2005 [Page 3]
Internet-Draft SIP CC Conferencing for UAs July 2004
1. Introduction
This specification uses the concepts and definitions from the high
level requirements [10] and the SIP conferencing framework [11]
documents.
The approach described in this document implements key functions in
the conferencing framework using SIP primitives only. This allows
for conducting 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 having
different capabilities and who potentially have joined the conference
by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc).
The call control and dialog manipulation approach is based on the
multiparty framework [12] document. That document defines the basic
approach of service design adopted for SIP which includes:
- Definition of primitives, not services
- Signaling model independent
- Invoker oriented
- Primitives make full use of URIs
- Include authentication, authorization, logging, etc. policies
- 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 service-related
header fields), as discussed in RFC 3087 [13], 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. For a UA which supports the
extensions and scenarios described in this document, the 'conf'
option tag is defined.
2. Usage of the 'isfocus' Feature Parameter
Johnston & Levin Expires January 16, 2005 [Page 4]
Internet-Draft SIP CC Conferencing for UAs July 2004
2.1 General
The main design guidelines for the development of SIP extensions and
conventions for conferencing are to define the minimum number of
extensions and to have seamless backwards 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. As a result 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 [7] document which includes the definition of the
"isfocus" feature parameter.
2.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 is
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.
The Conference URI MUST meet the requirements to be a GRUU (Globally
Routable User Agent URI) as detailed in [9]
2.3 OPTIONS
Currently the only met requirement is: given an opaque URI, being
able to recognize whether it belongs to a certain conference (i.e.
meaning that it is a conference URI) or not. As with any other
OPTIONS request, it 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.
Johnston & Levin Expires January 16, 2005 [Page 5]
Internet-Draft SIP CC Conferencing for UAs July 2004
3. SIP User Agent Conferencing Capability Types
From a conferencing perspective, the framework document outlines a
number of possible different SIP components such as
conference-unaware participant, conference-aware participant, and
focus.
This document applies the concepts above to the SIP call control part
of the conferencing components. It defines normative behavior of the
SIP UAs in various conferencing situations (referred later as
"scenarios").
3.1 Focus UA
A focus, as defined in the framework, hosts a SIP conference and
maintains 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 as defined in this
document.
A focus SHOULD support the conference package [5] and indicate so in
Allow-Events header fields in requests and responses. A focus MAY
include information about the conference in SDP message bodies sent.
A focus SHOULD support the Replaces [8] header field.
A user agent with focus capabilities could be implemented in end user
equipment and would be used for the creation of ad-hoc conferences.
A dedicated conferencing server, whose primary task is to
simultaneously host conferences of arbitrary type and size, may
allocate and publish a conference factory URI (as defined in the next
section) for creating an arbitrary number of ad-hoc conferences (and
subsequently their focuses) using SIP call control means.
3.2 Conference Factory URI
According to the framework, there are many ways in which a conference
can be created. These are open to the conferencing server
implementation policy and include non-automated means (such as IVR),
SIP, and a conference policy control protocol.
In order to automatically create an arbitrary number of ad-hoc
conferences (and subsequently their focuses) using SIP call control
means, a globally routable Conference Factory URI can be allocated
and published.
Johnston & Levin Expires January 16, 2005 [Page 6]
Internet-Draft SIP CC Conferencing for UAs July 2004
A successful attempt to establish a call to this URI would result in
the automatic creation a new conference and its focus. As a result,
note that the Conference Factory URI and the newly created focus URI
MAY resolve to different physical devices.
A scenario showing the use of the conference factory URI is shown in
Section 4.5.
3.3 Conference-Unaware UA
The simplest user agent can participate in a conference ignoring all
SIP conferencing-related information. The simplest user agent is
able to dial into a conference and to be invited to a conference.
Any conferencing information is optionally conveyed to/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 needs
only to support RFC 3261 [2]. Call flows for conference-unaware UAs
are not shown in general in this document as they would be identical
to those in the SIP call flows [15] document.
3.4 Conference-Aware UA
A conference-aware user agent supports SIP conferencing call control
conventions defined in this document as a conference participant, in
addition to support of RFC 3261.
A conference-aware UA MUST recognize the "isfocus" feature parameter.
A conference-aware UA SHOULD support REFER [3], SIP events [4], and
the conferencing package [5].
A conference-aware UA SHOULD subscribe to the conference package if
the "isfocus" parameter is in the remote target URI of a dialog and
if 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. 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.
This specification defines a new SIP option tag, "conf" for use by
UAs. A conference-aware UA SHOULD include the "conf" option tag in a
Supported header field in requests and responses. A conference-aware
UA discovering support for the "conf" option tag MAY make use the
scenarios described in this specification. Note that a UA which is
only acting as a focus (i.e. is not acting as a combined focus/
Johnston & Levin Expires January 16, 2005 [Page 7]
Internet-Draft SIP CC Conferencing for UAs July 2004
participant) in a dialog SHOULD NOT indicates support for this
specification using the "conf" option tag. Instead, the "isfocus"
feature tag should be used.
4. SIP Conferencing Primitives
The SIP conferencing call control flows presented in this section are
the call control building blocks for various SIP tight conferencing
applications as described in the conferencing requirements [10] and
framework [11] documents. The major design goal is that the same SIP
conferencing primitives would be used by user agents having different
conferencing capabilities and comprising different applications.
4.1 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.
If the UA is the first participant of the conference to dial in, it
is likely that this INVITE will create 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 SHOULD 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.
Johnston & Levin Expires January 16, 2005 [Page 8]
Internet-Draft SIP CC Conferencing for UAs July 2004
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@example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:3402934234@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: conf, replaces
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
F3 SIP/2.0 200 OK
Johnston & Levin Expires January 16, 2005 [Page 9]
Internet-Draft SIP CC Conferencing for UAs July 2004
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:3402934234@example.com>;tag=733413
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:3402934234@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: 274
v=0
o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com
s=Example Subject
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@example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKdf334
Max-Forwards: 70
To: <sip:3402934234@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=43524545
Call-ID: k3l43id034ksereree
CSeq: 22 SUBSCRIBE
Contact: <sip:carol@chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Supported: conf, replaces
Content-Length: 0
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Johnston & Levin Expires January 16, 2005 [Page 10]
Internet-Draft SIP CC Conferencing for UAs July 2004
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@example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@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@example.com">
<user uri="sip:carol@chicago.example.com"
display-name="Carol">
<status>connected</status>
<joining-mode>dialed-in</joining-mode>
<media-stream media-type="audio">
<proto>RTP/AVP</proto>
<ssrc>583398</ssrc>
</media-stream>
<media-stream media-type="video">
<proto>RTP/AVP</proto>
<ssrc>345212</ssrc>
</media-stream>
</user>
<conf-uri>tel:+18882934234</conf-uri>
</conference-info>
4.2 Adding a Participant by the Focus - Dial Out
To directly add a participant to a conference, a focus SHOULD send an
INVITE to the participant containing a Contact header field with the
conference URI and the "isfocus" feature parameter.
Note that a conference-unaware UA would simply ignore the
conferencing information and treat the session (from a SIP
perspective) as a point to point session.
An example call flow is shown in Figure 2. It is assumed that Alice
is already a participant of the conference. The focus invites Carol
Johnston & Levin Expires January 16, 2005 [Page 11]
Internet-Draft SIP CC Conferencing for UAs July 2004
to the conference by sending an INVITE. After the session is
established, Carol subscribes to the conference URI. It is important
to note that there is no dependency on Carol's SUBSCRIBE (F5) and the
NOTIFY to Alice (F9) - they occur asynchronously and independently.
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.
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@example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Johnston & Levin Expires January 16, 2005 [Page 12]
Internet-Draft SIP CC Conferencing for UAs July 2004
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@example.com">
<user uri="sip:alice@atlanta.example.com"
display-name="Alice">
<status>connected</status>
<joining-mode>dialed-in</joining-mode>
<media-stream media-type="audio">
<proto>RTP/AVP</proto>
<ssrc>674231</ssrc>
</media-stream>
<media-stream media-type="video">
<proto>RTP/AVP</proto>
<ssrc>213563</ssrc>
</media-stream>
</user>
<user uri="sip:carol@chicago.example.com"
display-name="Carol">
<status>connected</status>
<joining-mode>dialed-out</joining-mode>
<media-stream media-type="audio">
<proto>RTP/AVP</proto>
<ssrc>583398</ssrc>
</media-stream>
<media-stream media-type="video">
<proto>RTP/AVP</proto>
<ssrc>345212</ssrc>
</media-stream>
</user>
<conf-uri>tel:+18882934234</conf-uri>
</conference-info>
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@example.com>;tag=a3343df32
Call-ID: 8820450524545
CSeq: 998 NOTIFY
Contact: <sip:3402934234@example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
Johnston & Levin Expires January 16, 2005 [Page 13]
Internet-Draft SIP CC Conferencing for UAs July 2004
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="0" state="partial"
entity="sip:3402934234@example.com">
<user uri="sip:carol@chicago.example.com"
display-name="Carol">
<status>connected</status>
<joining-mode>dialed-out</joining-mode>
<media-stream media-type="audio">
<proto>RTP/AVP</proto>
<ssrc>583398</ssrc>
</media-stream>
<media-stream media-type="video">
<proto>RTP/AVP</proto>
<ssrc>345212</ssrc>
</media-stream>
</user>
<conf-uri>tel:+18882934234</conf-uri>
</conference-info>
4.3 Manually Creating a Conference by Dialing into a Conferencing
Application
In this section, a user sends an INVITE to a conference server
application. The application (such as an IVR system or a web page)
is implemented because the system requires additional input from the
user before it is able to create a conference. After a normal dialog
is established, additional information is received and the conference
together with its focus are created. At this point the conference
server MUST re-INVITE the user with the conference URI in Contact
with the "isfocus" feature parameter.
Alternatively, the additional information MAY be provided by the user
during an early dialog established. This could be accomplished by a
183 Session Progress response sent by the conferencing application.
After the conference is created, the conference URI MUST then be
returned in a Contact in the 200 OK.
An example call flow is shown in Figure 3. In this example, Alice
Johnston & Levin Expires January 16, 2005 [Page 14]
Internet-Draft SIP CC Conferencing for UAs July 2004
uses a conference application which is triggered when Alice sends an
INVITE to the conference application. In this example, Conf-App is
used to represent the conference application URI. Alice's
conference-aware UA learns of the existence of the conference from
the "isfocus" feature parameter and subscribes to the conference
package to receive notifications of 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.
4.4 Creating a Conference using Ad-Hoc SIP Methods
This section addresses creating a conference by using ad-hoc SIP
Johnston & Levin Expires January 16, 2005 [Page 15]
Internet-Draft SIP CC Conferencing for UAs July 2004
means. The conference factory URI (as defined in Section 2.4) is
used to automatically create the conference in this example.
The benefit of this approach is that the conference URI need not be
known to the user - instead it is created by a focus and used by the
participants' UAs. The main difference between this scenario and
Section 4.3 is that no user intervention (IVR, web page form, etc.)
is required to create the conference.
The SIP URI of the conference factory can be provisioned in the UA
(as in a "create new conference" button on a SIP phone) or can be
discovered using other means.
A SIP entity (such as conferencing server) can distinguish this
INVITE request as a request to create a new ad-hoc conference from a
request to join an existing conference by the Request-URI.
Assuming that all security and policy requirements have been met, a
new conference will be created with the Contact URI returned in the
200 OK being the conference URI. The Contact header field MUST
contain the "isfocus" feature parameter to indicate that this URI is
for a conference.
An example call flow is shown in Figure 4. Note that Conf-Factory is
shorthand for the conference factory URI and Conf-ID Is short for the
conference URI. In this flow, Alice has a conference-aware UA and
creates a conference by sending an INVITE to the conference factory
URI. The conference factory application creates the conference and
redirects using a 302 Moved Temporarily response to the focus. Note
that with proxy recursion, Alice may never see the redirect but may
just receive the responses from the focus starting with message F5.
Once the media session is established, Alice subscribes to the
conference URI obtained through the Contact in the 200 OK response
from the focus.
Johnston & Levin Expires January 16, 2005 [Page 16]
Internet-Draft SIP CC Conferencing for UAs July 2004
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.
4.5 Requesting the Focus Add a New Resource to a Conference
A SIP conference URI can be used to inject different kinds of
information into the conference. Examples include new participants,
new real-time media sources, new IM messages, and pointers to passive
information references (such as HTTP URIs).
To request the focus add a new information resource to the specified
conference, any SIP UA can send a REFER to the conference URI with a
Refer-To containing the URI of the new resource. Since this REFER is
sent to the conference URI and not the conference factory URI, the
semantics to the focus are to bring the resource into the conference
and make it visible to the conference participants. The resultant
Johnston & Levin Expires January 16, 2005 [Page 17]
Internet-Draft SIP CC Conferencing for UAs July 2004
focus procedures are dependant both on the nature of the new resource
(as expressed by its URI) and the own focus policies regarding IM,
central vs. distributed real time media processing, etc.
The scenario for adding a new UA participant is important to support
because it works even if the new participant does not support REFER
and transfer call control - only the requesting participant and the
focus need to support the REFER and transfer call control.
Upon receipt of the REFER containing a Refer-To header with a SIP
URI, the focus SHOULD send an INVITE to the new participant
identified by the Refer-To SIP URI containing a Contact header field
with the conference URI and the "isfocus" feature parameter.
A conference-unaware UA would simply ignore the conferencing
information and treat the session (from a SIP perspective) as a point
to point session.
An example call flow is shown in Figure 5. It is assumed that Alice
is already a participant of the conference. Alice sends a REFER to
the conference URI. The focus invites Carol to the conference by
sending an INVITE. After the session is established, Carol
subscribes to the conference URI. It is important to note that there
is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to Alice
(F15) - they occur asynchronously and independently.
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 |
| |---------------------------------------->|
Johnston & Levin Expires January 16, 2005 [Page 18]
Internet-Draft SIP CC Conferencing for UAs July 2004
| | 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 Focus add a Participant to the Conference.
F1 REFER sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344
Max-Forwards: 70
To: <sip:3402934234@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: conf, replaces
Content-Length: 0
4.6 Adding a 3rd Party Using Conference URI
A participant wishing to add a new participant will request this
participant to send an INVITE to the conference URI. This can be
done using a non-SIP means (such as passing or publishing the
conference URI in an email, IM, or web page). If a non-SIP means is
used, then the flow and requirements are identical to Section 4.1.
The SIP mechanism to do this utilizes the REFER method.
Johnston & Levin Expires January 16, 2005 [Page 19]
Internet-Draft SIP CC Conferencing for UAs July 2004
A UA wishing to add a new participant SHOULD send a REFER request to
the participant with a Refer-To header containing the conference URI.
The requirements are then identical to the "dial in" case of Section
4.1. The inviting participant MAY receive notification through the
REFER action that the new participant has been added in addition to
the notification received through the conference package.
An example is shown in Figure 7. In this call flow, it is assumed
that Alice is already a participant of the conference. Alice sends
Bob an "out of band" REFER - that is, a REFER outside of an
established dialog. Should Bob reject the REFER, Alice might try
sending an INVITE to Bob to establish a session first, then send a
REFER within the dialog, effectively transferring 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 | | |
|------------------->| | |
Johnston & Levin Expires January 16, 2005 [Page 20]
Internet-Draft SIP CC Conferencing for UAs July 2004
| | SUBSCRIBE sip:Conf-ID F13 |
| |<-------------------| |
| | 200 OK F14 | |
| |------------------->| |
| | NOTIFY F15 | |
| |------------------->| |
| | 200 OK F16 | |
| |<-------------------| |
Figure 6. Adding a Participant to an Existing Conference.
4.7 Requesting Focus Refer a Participant into the Conference
A participant may request the focus refer a participant into the
conference by sending a REFER method. The Refer-To header field will
have the method set to REFER and an escaped Refer-To header field
containing the conference URI.
Note that in Message F1 below, the Refer-To header field is shown as
continuing across two lines - this would not be the case in an actual
message, the URI would have continued beyond the formatting
limitations of this document.
This scenario is shown 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 | |
Johnston & Levin Expires January 16, 2005 [Page 21]
Internet-Draft SIP CC Conferencing for UAs July 2004
| 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 a Focus Refer a Participant to a Conference.
F1 REFER sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344
Max-Forwards: 70
To: <sip:3402934234@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: conf, replaces
Content-Length: 0
F5 REFER sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
Johnston & Levin Expires January 16, 2005 [Page 22]
Internet-Draft SIP CC Conferencing for UAs July 2004
Max-Forwards: 70
To: <sip:bob@biloxi.example.com>
From: <sip:3402934234@example.com>;tag=345621412
Call-ID: 5494204
CSeq: 4524323 REFER
Contact: <sip:3402934234@example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:3402934234@example.com>
Supported: join, gruu, replaces
Content-Length: 0
F11 INVITE sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
Max-Forwards: 70
To: <sip:3402934234@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: conf, replaces, join
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
4.8 Adding a 3rd Party Using a Dialog Identifier
Under some circumstances, a participant wanting to join a conference
may only know a dialog identifier of one of the legs of the
conference. The information may have been learned using the dialog
package [18] or some non-SIP means to retrieve this information from
a conference participant.
A UA can request to be added to a conference by sending a request to
the focus containing a Join [6] header field containing a dialog ID
of one leg of the conference (a dialog between a participant and the
focus).
There are other scenarios in which a UA can use the Join header for
Johnston & Levin Expires January 16, 2005 [Page 23]
Internet-Draft SIP CC Conferencing for UAs July 2004
certain conferencing call control scenarios. See [6] for further
examples and details.
An example is shown in Figure 8. It is assumed that Alice is a
participant of the conference. The dialog identifier between Alice
and the focus is abbreviated as A-F and is known by Bob. Bob
requests to be added to the conference by sending an INVITE message
F1 to the focus containing a Join header which contains the dialog
identifier A-F. Bob is added into the conference by the focus.
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.
Johnston & Levin Expires January 16, 2005 [Page 24]
Internet-Draft SIP CC Conferencing for UAs July 2004
F1 INVITE sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
Max-Forwards: 70
To: <sip:3402934234@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: conf, replaces, join
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
4.9 Changing User Agents within a Conference
A participant in a conference may want to change the user agent with
which they participate in the conference. While this could be done
by simply sending a BYE from one user agent to leave the conference
and an INVITE from the other user agent to rejoin. However, the SIP
Replaces [6] primitive is perfectly suited to this operation.
An example is shown in Figure 9. It is assumed that Alice is a
participant of the conference using user agent #1. The dialog
identifier between Alice's user agent #1 and the focus is abbreviated
as A-F. Alice switches to user agent #2 and sends an INVITE message
F1 to the focus containing a Replaces header which contains the
dialog identifier A-F. Note that this dialog identifier could be
learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY
and the dialog event package [18]. Alice's user agent #2 is added
into the conference by the focus. The focus sends a BYE to user
agent #1. User agent #1 then automatically terminates the
subscription by sending a SUBSCRIBE with Expires:0 to terminate the
subscription. Note that as the participant list (roster) has not
changed during this scenario, no NOTIFYs are sent by the focus to
subscribers to the participant list.
Johnston & Levin Expires January 16, 2005 [Page 25]
Internet-Draft SIP CC Conferencing for UAs July 2004
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. Adding a Participant to an Existing Conference using Join.
4.10 Bringing a Point-to-Point Session into a Conference
This call flow shows how a point to point call can be switched to a
conference call involving an external focus.
Alice and Bob have an established session with a dialog identifier
A-B. Alice joins the conference with the focus by sending an INVITE
to the Conference URI. Alice then sends a REFER to the focus and
includes an escaped Replaces header field in the Refer-To header
field. Bob receives the INVITE from the focus, matches the dialog in
Johnston & Levin Expires January 16, 2005 [Page 26]
Internet-Draft SIP CC Conferencing for UAs July 2004
the Replaces header field with the dialog with Alice. As a result,
Bob accepts the INVITE, joins the conference, and sends a BYE to
Alice to tear down their point to point dialog.
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 F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
|<==================>| | |
| | | |
| Alice asks focus to REFER Bob into conference |
| | | |
| REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F4 |
|------------------->| | |
| 202 Accepted F5 | | |
|<-------------------| | |
| NOTIFY (Trying) F6| | |
|<-------------------| | |
| 200 OK F7 | | |
|------------------->| | |
| | | |
| Focus invites Bob to the conference |
| | | |
| | INVITE sip:Conf-ID Replaces:A-B F8 |
| |------------------->| |
| | 200 OK F9 | |
| |<-------------------| |
| | ACK F10 | |
| |------------------->| |
| | RTP | |
| |<==================>| |
| BYE F11 | |
|<----------------------------------------| |
| 200 OK F12 | |
|---------------------------------------->| |
| NOTIFY (200) F13 | | |
|<-------------------| | |
| 200 OK F14 | | |
|------------------->| | |
Johnston & Levin Expires January 16, 2005 [Page 27]
Internet-Draft SIP CC Conferencing for UAs July 2004
| NOTIFY F15 | | |
|<-------------------| | |
| 200 OK F16 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F17 |
| |<-------------------| |
| | 200 OK F18 | |
| |------------------->| |
| | NOTIFY F19 | |
| |------------------->| |
| | 200 OK F20 | |
| |<-------------------| |
| | | |
Figure 10. Transitioning a Point to Point Session into a Conference.
4.11 Requesting the Focus Remove a Participant from a Conference
To request the focus remove a participant from the specified
conference, a properly authorized SIP UA (typically the conference
owner) can send a REFER to the conference URI with a Refer-To
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>.
Johnston & Levin Expires January 16, 2005 [Page 28]
Internet-Draft SIP CC Conferencing for UAs July 2004
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 Focus Remove a Participant from the Conference.
Johnston & Levin Expires January 16, 2005 [Page 29]
Internet-Draft SIP CC Conferencing for UAs July 2004
F1 REFER sip:3402934234@example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344
Max-Forwards: 70
To: <sip:3402934234@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: conf, 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@example.com>;tag=5393k2312
To: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 78654 BYE
Content-Length: 0
4.12 Deleting a conference
A conference created using the Conference Factory URI is
automatically deleted when the creator of the conference leaves the
conference by sending a BYE.
If the focus allows the conference policy to be manipulated, it is
possible for the conference to continue after the creator departs if
the policy is changed. However, 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.
Johnston & Levin Expires January 16, 2005 [Page 30]
Internet-Draft SIP CC Conferencing for UAs July 2004
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
4.13 Discovery of Conferencing Capabilities 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 which resolves to a focus.
Johnston & Levin Expires January 16, 2005 [Page 31]
Internet-Draft SIP CC Conferencing for UAs July 2004
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
Figure 13. Participant Queries Capabilities of URI which resolves to a Focus.
Following is an example 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=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:3402934234@example.com>;tag=93810874
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:3402934234@example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: refer, conference
Accept: application/sdp, application/conference-info+xml,
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=Example Subject
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 49170 RTP/AVP 0 1 3 5 7
m=video 51372 RTP/AVP 31 32
Useful information from each of these headers is detailed in the next
Johnston & Levin Expires January 16, 2005 [Page 32]
Internet-Draft SIP CC Conferencing for UAs July 2004
sections.
Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY
indicate that the user agent supports call control and SIP Events.
Accept. The support of bodies such as message/sipfrag [14],
application/conference-info+xml [5] also indicates support of call
control and conferencing.
Allow-Events. The support of event packages such as refer [3],
conference [5].
Supported. The 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.
5. Appendix - Creating a Conference by a Conference-Unaware UA
This section discussed 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 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
Johnston & Levin Expires January 16, 2005 [Page 33]
Internet-Draft SIP CC Conferencing for UAs July 2004
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 | | |
|<-------------------| | |
| 200 OK Contact:Conf-ID;isfocus F3 | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
Figure 14. A Conferencing Unaware Participant Creates a Conference
Johnston & Levin Expires January 16, 2005 [Page 34]
Internet-Draft SIP CC Conferencing for UAs July 2004
6. IANA Considerations
This specification registers a single SIP option tag, conf.
6.1 SIP Option Tag
The required information for this registration, as specified in RFC
3261 [2], is:
Name: conf
Description: This option tag is used in a Supported header field of a
request or response to indicate that the User Agent is
conference-aware and supports the extensions and scenarios
described in this specification.
7. Security Considerations
This document discusses call control for SIP conferencing. Both call
control and conferencing have specific security requirements which
will be summarized here. Conferences generally have authorization
rules about who may or may not join a conference, what type of media
may or may not be used, etc. This information is used by the focus
to admit or deny participation in a conference. It is recommended
that these types of authorization rules be used to provide security
for a SIP conference. For this authorization information to be used,
the focus needs to be able to authenticate potential participants.
Normal SIP mechanisms including Digest authentication and
certificates can be used. These conference specific security
requirements are discussed further in the requirements and framework
documents.
For call control security, a user agent must maintain local policy on
who is permitted to perform call control operations, initiate REFERs,
and replace dialogs. Normal SIP authentication mechanisms are also
appropriate here. The specific authentication and authorization
schemes are described in the multiparty call control framework
document.
8. 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.
Johnston & Levin Expires January 16, 2005 [Page 35]
Internet-Draft SIP CC Conferencing for UAs July 2004
9. Changes since -03
- Added definition and IANA registration for conf option tag for UAs
- Added requirement and flow for deletion of conference
- Added scenario of participant requesting focus refer a participant
to the conference
- Added scenario of moving a point to point call to a conference with
a separate focus
10. Changes since -02
- Added reference and text about use of GRUUs.
- Updated for latest version of conference package.
- Clarified that conference package subscription should use a
separate dialog from INVITE dialog.
11. Changes since -01
- Added messages details of selected INVITE, 200 OK, SUBSCRIBE,
REFER, and NOTIFY messages.
12. Changes since -00
- Showed separation between conference factory application and focus
by having the application redirect to the newly created focus in the
ad-hoc creation scenario.
- Removed inclusion of "isfocus" parameter in Refer-To header field -
this may be a useful extension to the REFER mechanism in the future,
however.
- Updated reference from Caller Prefs document to the new
Capabilities of User Agents document.
- Added scenario of participant changing user agents during a
conference.
- Added requirement on focus to support Replaces header field.
- Added discussion about termination of dialog using BYE and
subscription using SUBSCRIBE/NOTIFY to flows involving termination of
session with the focus.
Johnston & Levin Expires January 16, 2005 [Page 36]
Internet-Draft SIP CC Conferencing for UAs July 2004
13. References
13.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] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol
(SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-04 (work in progress), May
2004.
[6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP)
'Join' Header", draft-ietf-sip-join-03 (work in progress),
February 2004.
[7] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.
[8] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-05
(work in progress), February 2004.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-02 (work in progress), July 2004.
13.2 Informative References
[10] Levin, O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing",
draft-ietf-sipping-conferencing-requirements-00 (work in
progress), April 2003.
[11] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02 (work in
Johnston & Levin Expires January 16, 2005 [Page 37]
Internet-Draft SIP CC Conferencing for UAs July 2004
progress), June 2004.
[12] Mahy, R., "A Call Control and Multi-party usage framework for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-cc-framework-03 (work in progress), October
2003.
[13] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[14] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
[15] 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.
[16] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", draft-ietf-sipping-service-examples-06 (work
in progress), February 2004.
[17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in
progress), February 2004.
[18] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-04 (work in progress),
February 2004.
Authors' Addresses
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63102
EMail: alan.johnston@mci.com
Orit Levin
Microsoft
One Microsoft Way
Redmond, WA 75024
EMail: oritl@microsoft.com
Johnston & Levin Expires January 16, 2005 [Page 38]
Internet-Draft SIP CC Conferencing for UAs July 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Johnston & Levin Expires January 16, 2005 [Page 39]
