Network Working Group A. Johnston
Request for Comments: 4579 Avaya
BCP: 119 O. Levin
Category: Best Current Practice Microsoft Corporation
August 2006
Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
the perspective of different user agent (UA) types: conference-
unaware, conference-aware, and focus UAs. The use of Uniform
Resource Identifiers (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.
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.......40
1. Introduction
This specification uses the concepts and definitions from the high
level requirements [14] and the SIP conferencing framework [8]
documents. This approach is applicable to tightly coupled SIP
conferences. In this architecture, 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 the operation of a
focus and participant UAs. Note that only the signalling (SIP) needs
to be centralized in this model; 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 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 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].
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 to 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 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.
In order 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 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. 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.
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.
A successful attempt to establish a call to this URI would result in
the automatic creation of 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 5.4.
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 in to 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 need
only 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 document [13].
Note that the presence of an ’isfocus’ feature tag in a Contact
header field will not cause interoperability issues between a focus
and a conference-unaware UA since it will be treated as an unknown
header parameter and ignored, as per standard SIP behavior.
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 [2]. 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.
A conference-aware UA 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
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.
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
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 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. 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 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 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.
By their nature, the conferences supported by this specification are
centralized. Therefore, 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
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. This is because standard
RFC 3261 [2] behavior is to ignore unknown header parameters such as