summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4579.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4579.txt')
-rw-r--r--doc/rfc/rfc4579.txt2411
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc4579.txt b/doc/rfc/rfc4579.txt
new file mode 100644
index 0000000..aa5186c
--- /dev/null
+++ b/doc/rfc/rfc4579.txt
@@ -0,0 +1,2411 @@
+
+
+
+
+
+
+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
+
+
+
+Johnston & Levin Best Current Practice [Page 1]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+Johnston & Levin Best Current Practice [Page 2]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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").
+
+
+
+
+Johnston & Levin Best Current Practice [Page 3]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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.
+
+
+
+Johnston & Levin Best Current Practice [Page 4]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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.
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 5]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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.
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 6]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 7]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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)
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 8]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 9]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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>
+
+
+
+Johnston & Levin Best Current Practice [Page 10]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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
+ 'isfocus'.
+
+ 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 11]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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@conf.example.com>;tag=a3343df32
+ Call-ID: k3l43id034ksereree
+ CSeq: 34321 NOTIFY
+ Contact: <sip:3402934234@conf.example.com>;isfocus
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Event: conference
+ Accept: application/sdp, message/sipfrag
+ Subscription-State: active;expires=3600
+ Supported: replaces, gruu
+ Content-Type: application/conference-info+xml
+ Content-Length: ...
+
+
+
+Johnston & Levin Best Current Practice [Page 12]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ <conference-info version="0" state="full"
+ entity="sip:3402934234@conf.example.com">
+ <conference-description>
+ <conf-uris>
+ <entry>
+ <uri>tel:+18882934234</uri>
+ </entry>
+ </conf-uris>
+ </conference-description>
+ <users>
+ <user entity="sip:alice@atlanta.example.com" state="full">
+ <display-text>Alice</display-text>
+ <endpoint entity="sip:alice@client.atlanta.example.com">
+ <status>connected</status>
+ <joining-method>dialed-in</joining-method>
+ <media id="3">
+ <display-text>Main Audio</display-text>
+ <type>audio</type>
+ <src-id>647231</src-id>
+ <status>sendrecv</status>
+ </media>
+ <media id="4">
+ <type>video</type>
+ <src-id>21345</src-id>
+ <status>sendrecv</status>
+ </media>
+ </endpoint>
+ </user>
+ <user entity="sip:carol@chicago.example.com" state="full">
+ <display-text>Carol</display-text>
+ <endpoint entity="sip:carol@client.chicago.example.com">
+ <status>connected</status>
+ <joining-method>dialed-out</joining-method>
+ <media id="1">
+ <display-text>Main Audio</display-text>
+ <type>audio</type>
+ <src-id>583398</src-id>
+ <status>sendrecv</status>
+ </media>
+ <media id="2">
+ <type>video</type>
+ <src-id>345212</src-id>
+ <status>sendrecv</status>
+ </media>
+ </endpoint>
+ </user>
+ </users>
+ </conference-info>
+
+
+
+Johnston & Levin Best Current Practice [Page 13]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0
+ Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432
+ Max-Forwards: 70
+ To: Alice <sip:alice@atlanta.example.com>;tag=43524545
+ From: <sip:3402934234@conf.example.com>;tag=a3343df32
+ Call-ID: 8820450524545
+ CSeq: 998 NOTIFY
+ Contact: <sip:3402934234@conf.example.com>;isfocus
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Event: conference
+ Accept: application/sdp, message/sipfrag
+ Subscription-State: active;expires=2450
+ Supported: replaces, gruu
+ Content-Type: application/conference-info+xml
+ Content-Length: ...
+
+ <conference-info version="1" state="partial"
+ entity="sip:3402934234@conf.example.com">
+ <users>
+ <user entity="sip:carol@chicago.example.com" state="full">
+ <display-text>Carol</display-text>
+ <endpoint entity="sip:carol@client.chicago.example.com">
+ <status>connected</status>
+ <joining-method>dialed-out</joining-method>
+ <media id="1">
+ <display-text>Main Audio</display-text>
+ <type>audio</type>
+ <src-id>583398</src-id>
+ <status>sendrecv</status>
+ </media>
+ <media id="2">
+ <type>video</type>
+ <src-id>345212</src-id>
+ <status>sendrecv</status>
+ </media>
+ </endpoint>
+ </user>
+ </users>
+ </conference-info>
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 14]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+5.3. INVITE: Manually Creating a Conference by Dialing in to a
+ Conferencing Application
+
+ In this section, a user sends an INVITE to a conference server
+ application. The 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. Since the UA is now in a dialog
+ with a focus, the focus will re-INVITE the user with the conference
+ URI in Contact with the 'isfocus' feature parameter.
+
+ Alternatively, the additional information can be provided by the user
+ during an early dialog (see RFC 3261 [2] for a discussion of early
+ dialogs in SIP). This could be accomplished by a 183 Session
+ Progress response sent by the conferencing application. After the
+ conference is created, the conference URI would then be returned in a
+ Contact in the 200 OK.
+
+ Note that since this flow is all about human interaction with a
+ conferencing application, any errors and failures will be returned to
+ the human (recorded announcements, error tones, etc.).
+
+ As discussed in the conferencing framework, the conference URI must
+ be unique across all distinct conferences within the same domain. In
+ general, the user part of a conference URI will contain a pseudo
+ random string.
+
+ An example call flow is shown in Figure 3. In this example, Alice
+ uses a conference application that 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 15]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Focus Bob Carol
+ | | | |
+ | Alice establishes session with conference application. |
+ | | | |
+ | INVITE sip:Conf-App F1 | |
+ |------------------->| | |
+ | 180 Ringing F2 | | |
+ |<-------------------| | |
+ | 200 OK F3 | | |
+ |<-------------------| | |
+ | ACK F4 | | |
+ |------------------->| | |
+ | RTP | | |
+ |<==================>| | |
+ | | | |
+ | Alice uses the application to create the conference. |
+ | | | |
+ | INVITE Contact:Conf-ID;isfocus F5 | |
+ |<-------------------| | |
+ | 200 OK F6 | | |
+ |------------------->| | |
+ | ACK F7 | | |
+ |<-------------------| | |
+ | RTP | | |
+ |<==================>| | |
+ | | | |
+ | SUBSCRIBE sip:Conf-ID F8 | |
+ |------------------->| | |
+ | 200 OK F9 | | |
+ |<-------------------| | |
+ | NOTIFY F10 | | |
+ |<-------------------| | |
+ | 200 OK F11 | | |
+ |------------------->| | |
+
+ Figure 3. A Participant Creates a Conference Using an Application.
+
+5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods
+
+ This section addresses creating a conference by using ad-hoc SIP
+ means. The conference factory URI (as defined in Section 3.2) is
+ used to automatically create the conference in this example. This is
+ different from the previous scenario in that no human intervention is
+ required -- an automaton can create the conference and add
+ participants. Since the conference does not need to be scheduled or
+ reserved, but is created "on the fly", it is an "ad-hoc" conference
+ creation.
+
+
+
+
+Johnston & Levin Best Current Practice [Page 16]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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 5.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. That is,
+ although both requests may route to the same application, the
+ differing services requested can be identified by the differing URIs
+ in the request itself.
+
+ 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 Alice to the focus using a 302 Moved Temporarily response.
+ Note that with proxy recursion as part of normal RFC 3261 [2]
+ behavior, 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 Best Current Practice [Page 17]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Conf-Factory App Focus Bob
+ | | | |
+ | Alice creates the conference. | |
+ | | | |
+ | INVITE sip:Conf-Factory F1 | |
+ |------------------->| | |
+ | 302 Moved Contact:Conf-ID;isfocus F2 | |
+ |<-------------------| | |
+ | ACK F3 | | |
+ |------------------->| | |
+ | INVITE sip:Conf-ID F4 | |
+ |---------------------------------------->| |
+ | 180 Ringing F5 | |
+ |<----------------------------------------| |
+ | 200 OK Contact:Conf-ID;isfocus F6 | |
+ |<----------------------------------------| |
+ | ACK F7 | |
+ |---------------------------------------->| |
+ | RTP | |
+ |<=======================================>| |
+ | | |
+ | Alice subscribes to the conference URI. | |
+ | | |
+ | SUBSCRIBE sip:Conf-ID F8 | |
+ |---------------------------------------->| |
+ | 200 OK F9 | |
+ |<----------------------------------------| |
+ | NOTIFY F10 | |
+ |<----------------------------------------| |
+ | 200 OK F11 | |
+ |---------------------------------------->| |
+
+ Figure 4. Creation of a Conference Using SIP Ad-Hoc Methods.
+
+5.5. REFER: Requesting a Focus to Add a New Resource to a Conference
+ (Dial Out to a New Participant)
+
+ A SIP conference URI 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 that 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
+
+
+
+Johnston & Levin Best Current Practice [Page 18]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ participants. The resultant focus procedures are dependent both on
+ the nature of the new resource (as expressed by its URI) and the
+ policy of the focus regarding IM, central vs. distributed real-time
+ media processing, and so on.
+
+ 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. While this flow shows the
+ use of REFER to add a new participant to the conference, the
+ mechanism can generally add a resource as identified by a URI to the
+ conference. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 19]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Focus Bob Carol
+ | | | |
+ |<==================>| | |
+ | REFER sip:Conf-ID Refer-To:Carol F1 | |
+ |------------------->| |
+ | 202 Accepted F2 | |
+ |<-------------------| |
+ | NOTIFY (Trying) F3 |
+ |<-------------------| |
+ | 200 OK F4 | |
+ |------------------->| |
+ | | |
+ | Focus "dials out" to join Carol to the conference |
+ | | |
+ | | INVITE Contact:Conf-ID;isfocus F5 |
+ | |---------------------------------------->|
+ | | 180 Ringing F6 |
+ | |<----------------------------------------|
+ | | 200 OK F7 |
+ | |<----------------------------------------|
+ | | ACK F8 |
+ | |---------------------------------------->|
+ | | RTP |
+ | |<=======================================>|
+ | NOTIFY (OK) F9 | |
+ |<-------------------| |
+ | 200 OK F10 | |
+ |------------------->| |
+ | | SUBSCRIBE sip:Conf-ID F11 |
+ | |<----------------------------------------|
+ | | 200 OK F12 |
+ | |---------------------------------------->|
+ | | NOTIFY F13 |
+ | |---------------------------------------->|
+ | | 200 OK F14 |
+ | |<----------------------------------------|
+ | NOTIFY F15 | |
+ |<-------------------| |
+ | 200 OK F16 | |
+ |------------------->| |
+
+ Figure 5. Participant Requests That the Focus Add a Participant to
+ the Conference.
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 20]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ F1 REFER sip:3402934234@conf.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
+ Max-Forwards: 70
+ To: <sip:3402934234@conf.example.com>
+ From: Alice <sip:alice@atlanta.example.com>;tag=5534562
+ Call-ID: 849392fklgl43
+ CSeq: 476 REFER
+ Contact: <sip:alice@alice.example.com>
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Accept: application/sdp, message/sipfrag
+ Refer-To: <sip:carol@chicago.example.com>
+ Supported: replaces
+ Content-Length: 0
+
+5.6. REFER: Requesting a User to Dial in to a Conference Using a
+ 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 5.1.
+
+ The SIP mechanism to do this utilizes the REFER method.
+
+ 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
+ 5.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 6. 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].
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 21]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Focus Bob Carol
+ | | | |
+ |<==================>| | |
+ | | | |
+ | Alice adds Bob into conference | |
+ | | | |
+ | REFER Refer-To:Conf-ID F1 | |
+ |---------------------------------------->| |
+ | 202 Accepted F2 | | |
+ |<----------------------------------------| |
+ | NOTIFY (Trying) F3| | |
+ |<----------------------------------------| |
+ | 200 OK F4 | | |
+ |---------------------------------------->| |
+ | | INVITE sip:Conf-ID F5 |
+ | |<-------------------| |
+ | | 180 Ringing F6 | |
+ | |------------------->| |
+ | | 200 OK Contact:Conf-ID;isfocus F7 |
+ | |------------------->| |
+ | | ACK F8 | |
+ | |<-------------------| |
+ | | RTP | |
+ | |<==================>| |
+ | NOTIFY (OK) F9 | | |
+ |<----------------------------------------| |
+ | 200 OK F10 | | |
+ |---------------------------------------->| |
+ | NOTIFY F11 | | |
+ |<-------------------| | |
+ | 200 OK F12 | | |
+ |------------------->| | |
+ | | SUBSCRIBE sip:Conf-ID F13 |
+ | |<-------------------| |
+ | | 200 OK F14 | |
+ | |------------------->| |
+ | | NOTIFY F15 | |
+ | |------------------->| |
+ | | 200 OK F16 | |
+ | |<-------------------| |
+
+ Figure 6. Adding a Participant to an Existing Conference.
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 22]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+5.7. REFER with REFER: Requesting a Focus to Refer a Participant to
+ Dial in to the Conference
+
+ A participant may request that 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 23]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Focus Bob Carol
+ | | | |
+ |<==================>| | |
+ | Alice asks focus to REFER Bob into conference |
+ | | | |
+ |REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1
+ |------------------->| | |
+ | 202 Accepted F2 | | |
+ |<-------------------| | |
+ | NOTIFY (Trying) F3| | |
+ |<-------------------| | |
+ | 200 OK F4 | | |
+ |------------------->| | |
+ | Focus REFERs Bob to the conference |
+ | | | |
+ | | REFER Refer-To:Conf-ID F5 |
+ | |------------------->| |
+ | | 202 Accepted F6 | |
+ | NOTIFY (202) F7 |<-------------------| |
+ |<-------------------| NOTIFY (Trying) F8 | |
+ | 200 OK F9 |<-------------------| |
+ |------------------->| 200 OK F10 | |
+ | |------------------->| |
+ | | INVITE sip:Conf-ID F11 |
+ | |<-------------------| |
+ | | 180 Ringing F12 | |
+ | |------------------->| |
+ | | 200 OK Contact:Conf-ID;isfocus F13 |
+ | |------------------->| |
+ | | ACK F14 | |
+ | NOTIFY F15 |<-------------------| |
+ |<-------------------| RTP | |
+ | 200 OK F16 |<==================>| |
+ |------------------->| NOTIFY (200) F17 | |
+ | |<-------------------| |
+ | | 200 OK F18 | |
+ | |------------------->| |
+ | | SUBSCRIBE sip:Conf-ID F17 |
+ | |<-------------------| |
+ | | 200 OK F19 | |
+ | |------------------->| |
+ | | NOTIFY F20 | |
+ | |------------------->| |
+ | | 200 OK F21 | |
+ | |<-------------------| |
+
+ Figure 7. Requesting That the Focus Refer a Participant to a
+ Conference.
+
+
+
+Johnston & Levin Best Current Practice [Page 24]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ F1 REFER sip:3402934234@conf.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
+ Max-Forwards: 70
+ To: <sip:3402934234@conf.example.com>
+ From: Alice <sip:alice@atlanta.example.com>;tag=5534562
+ Call-ID: 849392fklgl43
+ CSeq: 476 REFER
+ Contact: <sip:alice@alice.example.com>
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Accept: application/sdp, message/sipfrag
+ Refer-To: <sip:bob@biloxi.example.com;method=REFER
+ ?Refer-To=sip:3402934234%40example.com>
+ Supported: replaces
+ Content-Length: 0
+
+
+ F5 REFER sip:3402934234@conf.example.com SIP/2.0
+ Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
+ Max-Forwards: 70
+ To: <sip:bob@biloxi.example.com>
+ From: <sip:3402934234@conf.example.com>;tag=345621412
+ Call-ID: 5494204
+ CSeq: 4524323 REFER
+ Contact: <sip:3402934234@conf.example.com>;isfocus
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Accept: application/sdp, message/sipfrag
+ Refer-To: <sip:3402934234@conf.example.com>
+ Supported: join, gruu, replaces
+ Content-Length: 0
+
+
+ F11 INVITE sip:3402934234@conf.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
+ Max-Forwards: 70
+ To: <sip:3402934234@conf.example.com>
+ From: Bob <sip:bob@biloxi.example.com>;tag=32411
+ Call-ID: 5d4324fa84b4c76e66710
+ CSeq: 764 INVITE
+ Contact: <sip:bob@client.biloxi.example.com>
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Allow-Events: dialog
+ Accept: application/sdp, message/sipfrag
+ Supported: replaces, join
+ Content-Type: application/sdp
+ Content-Length: ...
+
+
+
+Johnston & Levin Best Current Practice [Page 25]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ (SDP not shown)
+
+5.8. Join Header Field: Dialing in to a Conference Using a (3rd Party)
+ 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
+ another conference participant.
+
+ A UA can request to be added to a conference by sending a request to
+ the focus containing a Join [7] header field containing a dialog ID
+ of one leg of the conference (a dialog between another participant
+ and the focus).
+
+ There are other scenarios in which a UA can use the Join header for
+ certain conferencing call control scenarios. See [7] 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 that contains the dialog
+ identifier A-F. Bob is added into the conference by the focus.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 26]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice Focus Bob Carol
+ | | | |
+ |<==================>| | |
+ | | | |
+ | Bob requests to be added to the conference. |
+ | | | |
+ | | INVITE Join:A-F F1| |
+ | |<-------------------| |
+ | | 180 Ringing F2 | |
+ | |------------------->| |
+ | | 200 OK Contact:Conf-ID;isfocus F3 |
+ | |------------------->| |
+ | | ACK F4 | |
+ | |<-------------------| |
+ | | RTP | |
+ | NOTIFY F5 |<==================>| |
+ |<-------------------| SUBSCRIBE sip:Conf-ID F6 |
+ | 200 OK F7 |<-------------------| |
+ |------------------->| 200 OK F8 | |
+ | |------------------->| |
+ | | NOTIFY F9 | |
+ | |------------------->| |
+ | | 200 OK F10 | |
+ | |<-------------------| |
+
+ Figure 8. Adding a Participant to an Existing Conference using Join.
+
+
+ F1 INVITE sip:3402934234@conf.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
+ Max-Forwards: 70
+ To: <sip:3402934234@conf.example.com>
+ From: Bob <sip:bob@biloxi.example.com>;tag=32411
+ Call-ID: d432fa84b4c76e66710
+ CSeq: 8 INVITE
+ Contact: <sip:bob@client.biloxi.example.com>
+ Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
+ SUBSCRIBE, NOTIFY
+ Allow-Events: dialog
+ Accept: application/sdp, message/sipfrag
+ Supported: replaces, join
+ Content-Type: application/sdp
+ Content-Length: ...
+
+ (SDP not shown)
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 27]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+5.9. Replaces Header Field: Switching User Agents within a Conference
+
+ Participants in a conference may want to change the user agent (i.e.,
+ the endpoint or the device) with which they participate in the
+ conference. 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 that 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 the participant list (roster) has not necessarily changed
+ during this scenario, unless detailed information about Alice user
+ agents (i.e. endpoints) is included in the conference state
+ notifications. For a full discussion of conference package
+ notifications, refer to [9].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 28]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ Alice UA#1 Focus Alice UA#2 Carol
+ | | | |
+ |<==================>| | |
+ | | | |
+ | Alice switches user agents during the conference. |
+ | | | |
+ | | INVITE sip:Conf-ID Replaces:A-F F1 |
+ | |<-------------------| |
+ | | 200 OK Contact:Conf-ID;isfocus F2 |
+ | |------------------->| |
+ | | ACK F3 | |
+ | |<-------------------| |
+ | | RTP | |
+ | |<==================>| |
+ | BYE F4 | | |
+ |<-------------------| | |
+ | 200 OK F5 | | |
+ |------------------->| | |
+ | SUBSCRIBE Expires:0 F6 | |
+ |------------------->| | |
+ | 200 OK F7 | | |
+ |<-------------------| | |
+ | NOTIFY Subscription-State:terminated F8 | |
+ |<-------------------| | |
+ | 200 OK F9 | | |
+ |------------------->| | |
+ | | SUBSCRIBE sip:Conf-ID F10 |
+ | |<-------------------| |
+ | | 200 OK F11 | |
+ | |------------------->| |
+ | | NOTIFY F12 | |
+ | |------------------->| |
+ | | 200 OK F13 | |
+ | |<-------------------| |
+
+ Figure 9. Switching a User Agent within a Conference.
+
+5.10. Replaces Header Field: Transferring a Point-to-Point Session into
+ a Conference
+
+ This call flow shows how a point-to-point call can be transferred 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 request to the focus
+ to send an INVITE request to the other participant. Alice includes
+ an escaped Replaces header field in the URI included in the Refer-To
+
+
+
+Johnston & Levin Best Current Practice [Page 29]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ header field. Bob receives the INVITE from the focus and matches the
+ dialog in 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;isfocus F2 | |
+ |<-------------------| | |
+ | ACK F3 | | |
+ |------------------->| | |
+ | SUBSCRIBE F4 | | |
+ |------------------->| | |
+ | 200 OK F5 | | |
+ |<-------------------| | |
+ | NOTIFY F6 | | |
+ |<-------------------| | |
+ | 200 OK F7 | | |
+ |------------------->| | |
+ |<==================>| | |
+ | | | |
+ | Alice asks focus to REFER Bob into conference |
+ | | | |
+ | REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 |
+ |------------------->| | |
+ | 202 Accepted F9 | | |
+ |<-------------------| | |
+ | NOTIFY (Trying) F10| | |
+ |<-------------------| | |
+ | 200 OK F11 | | |
+ |------------------->| | |
+ | | | |
+ | Focus invites Bob to the conference |
+ | | | |
+ | | INVITE sip:Conf-ID Replaces:A-B F12 |
+ | |------------------->| |
+ | | 200 OK F13 | |
+ | |<-------------------| |
+ | | ACK F14 | |
+ | |------------------->| |
+ | | RTP | |
+
+
+
+Johnston & Levin Best Current Practice [Page 30]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ | |<==================>| |
+ | BYE F15 | |
+ |<----------------------------------------| |
+ | 200 OK F16 | |
+ |---------------------------------------->| |
+ | NOTIFY (200) F17 | | |
+ |<-------------------| | |
+ | 200 OK F18 | | |
+ |------------------->| | |
+ | NOTIFY F19 | | |
+ |<-------------------| | |
+ | 200 OK F20 | | |
+ |------------------->| | |
+ | | SUBSCRIBE sip:Conf-ID F21 |
+ | |<-------------------| |
+ | | 200 OK F22 | |
+ | |------------------->| |
+ | | NOTIFY F23 | |
+ | |------------------->| |
+ | | 200 OK F24 | |
+ | |<-------------------| |
+ | | | |
+
+ Figure 10. Transitioning a Point to Point Session into a Conference.
+
+5.11. REFER with BYE: Requesting That the Focus Remove a Participant
+ from a Conference
+
+ To request that 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 Best Current Practice [Page 31]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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
+
+
+
+Johnston & Levin Best Current Practice [Page 32]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 33]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 34]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+
+Johnston & Levin Best Current Practice [Page 35]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+Johnston & Levin Best Current Practice [Page 36]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 37]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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.
+
+
+
+Johnston & Levin Best Current Practice [Page 38]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 39]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 40]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+ 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. Not Recommended: Conferencing Unaware Participant
+ Creates a Conference
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 41]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+Authors' Addresses
+
+ Alan Johnston
+ Avaya
+ St. Louis, MO 63102
+
+ EMail: alan@sipstation.com
+
+
+ Orit Levin
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: oritl@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 42]
+
+RFC 4579 SIP CC Conferencing for UAs August 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Johnston & Levin Best Current Practice [Page 43]
+