SIPPING [-WG Internet Draft-] {+Working Group+} A. Johnston [-Document:-] {+Internet-Draft+} WorldCom [-draft-johnston-sipping-cc-conferencing-00.txt-] {+Expires: August 8, 2003+} O. Levin RADVISION [-Expires: April-] {+February 7,+} 2003 [-October 2002-] Session Initiation Protocol Call Control - Conferencing for User Agents {+draft-johnston-sipping-cc-conferencing-01+} Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [-RFC2026 [1].-] {+RFC2026.+} Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as [-Internet- Drafts.-] {+Internet-Drafts.+} Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at [-http://www.ietf.org/ietf/1id-abstracts.txt-] {+http:// www.ietf.org/ietf/1id-abstracts.txt.+} The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. {+This Internet-Draft will expire on August 8, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.+} Abstract This document [-describes providing Conferencing-] {+defines conferencing+} call control [-capabilities in-] {+features for+} the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to [-show-] {+define+} how a tightly coupled SIP conference [-will work.-] {+works.+} The approach is explored from [-a-] {+different+} user agent (UA) [-perspective. Three-] types [-of UAs are described: a conferencing unaware UA, one capable of being a full member of a conference,-] {+perspective: conference-unaware, conference-aware+} and [-one also capable of hosting a conference.-] {+focus UAs.+} The use of URIs in conferencing, OPTIONS for [-capability-] {+capabilities+} discovery, and call control using REFER are covered in detail with example call flow diagrams. Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page 1] {+Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2].-] {+February 2003+} Table of Contents 1. [-Introduction...................................................2-] {+Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3+} 2. [-SIP Conferencing Vocabulary....................................3-] {+Usage of the 'isfocus' Feature Parameter . . . . . . . . . . 3 2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Session Establishment Usage . . . . . . . . . . . . . . . . 4 2.3 OPTIONS Usage . . . . . . . . . . . . . . . . . . . . . . . 4+} 3. {+SIP User Agent+} Conferencing [-URIs..............................................3-] {+Capability Types . . . . . . . . 4+} 3.1 [-Use of a General URI in Conferencing.......................3 3.2-] Focus [-SIP URI..............................................4 3.3-] {+UA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2+} Conference [-SIP URI.........................................4-] {+Factory URI . . . . . . . . . . . . . . . . . . . 5 3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . . . 5+} 3.4 [-Globally Routable Contact Requirements.....................4-] {+Conference-Aware UA . . . . . . . . . . . . . . . . . . . . 6+} 4. SIP [-User Agent-] Conferencing [-Capability Types...................5-] {+Primitives . . . . . . . . . . . . . . . . 6+} 4.1 [-Type I --] {+Joining a+} Conference [-Unaware UA.............................5 4.2 Type II --] {+using the+} Conference [-Member Capable UA.....................5 4.3 Type III-] {+URI+} - [-Conference Member and/or Focus Capable UA.......6 5. Discovery of Conferencing Capabilities using OPTIONS...........6 5.1 Requirements Review........................................6 5.2 Definitions................................................7 5.3 Examples...................................................8 6. SIP Conferencing Implementation................................9 6.1 SIP Conferencing Building Blocks...........................9 6.2 Creating-] {+Dial In . . 6 4.2 Adding+} a [-Conference......................................9 6.3-] {+Participant by the Focus - Dial Out . . . . . . . . 7 4.3 Manually+} Creating a Conference by [-a Type I UA......................11 6.4-] Dialing into a {+Conferencing Application . . . . . . . . . . . . . . . . . . 8 4.4 Creating a+} Conference by {+a Conference-Unaware UA . . . . . . 10 4.5 Creating a+} Conference [-URI...............12 6.5 Dial out - Added by the Focus.............................13 6.6-] {+using Ad-Hoc SIP Methods . . . . . . . 11 4.6+} Requesting the Focus Add a New Resource to a [-Conference...15 6.7-] {+Conference . . 12 4.7+} Adding a 3rd Party Using Conference [-ID....................16 6.8-] {+URI . . . . . . . . . . 14 4.8+} Adding a 3rd Party Using [-Call ID..........................18 6.9-] {+a Dialog Identifier . . . . . . . . 16 4.9+} Bringing a Point-to-Point Dialog into a [-Conference........19-] {+Conference . . . . . 17 4.10 Requesting the Focus Remove a Participant from a Conference . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.11 Discovery of Conferencing Capabilities using OPTIONS . . . . 18 5.+} Security [-Considerations..........................................20 References.......................................................20 Acknowledgments..................................................21 Author's Addresses...............................................21-] {+Considerations . . . . . . . . . . . . . . . . . . 20 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 Normative References . . . . . . . . . . . . . . . . . . . . 21 Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 23 Johnston & Levin Expires August 8, 2003 [Page 2] Internet-Draft SIP CC Conferencing for UAs February 2003+} 1. Introduction This document uses the concepts and definitions [-in-] {+from+} the [-Session Initiation Protocol(SIP) [3]-] {+high level requirements [8] and the SIP+} conferencing framework {+[9] documents. The approach described in this+} document [-[4] and-] {+implements key functions in+} the [-requirements-] {+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 [-[5].-] {+the scope of this document. This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. Possible applications include ad-hoc conferences and scheduled conferences. Note that a single conference can bridge participants having different capabilities and who potentially have joined the conference by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc).+} The call control and dialog manipulation approach is based on [-that outlined in-] the [-Multiparty Framework document [6].-] {+multiparty framework [10] document.+} That document defines the basic approach of service design adopted for SIP which includes: - Definition of primitives, not services [-Johnston & Levin Expires - April 2003 [Page 2] SIP Call Control - Conferencing for UAs October 2002 - Participant oriented-] - Signaling model independent - Invoker oriented - Primitives make full use of URIs - Include authentication, authorization, logging, etc. policies - Define graceful fallback to baseline SIP. The use of opaque URIs and the ability to communicate call control context information within a URI (as opposed to service-related header fields), as discussed in RFC 3087 [-[7],-] {+[11],+} is fundamental to this [-document. All cases begin with an assumption that a URI is known to a user agent. Some-] {+approach. 2. Usage of the 'isfocus' Feature Parameter 2.1 General The main design guidelines for the development of+} SIP [-mechanisms-] {+extensions and conventions+} for [-URI discovery-] {+conferencing+} are [-described here, including-] {+to define+} the [-use-] {+minimum number+} of [-OPTIONS and extracting URIs from Contact header fields. However, other methods can be used-] {+extensions+} and [-may be developed. For example, current work in the ENUM working group described in RFC 2916bis [8] to include service tags in addition-] to [-protocols to map-] {+have seamless backwards compatibility with conference-unaware SIP UAs. The minimal requirement for SIP is being able+} to {+express that+} a [-URI. For further study-] {+dialog+} is [-the idea to use-] a [-DNS SRV-like process to discover URIs relating-] {+part of a certain conference referenced+} to [-conferencing services. Another idea-] {+by a URI. As a result of these extensions, it+} is {+possible+} to [-use Service Location Protocol RFC 2608 [9] for this purpose. 2.-] {+do the following using SIP: Johnston & Levin Expires August 8, 2003 [Page 3] Internet-Draft+} SIP {+CC+} Conferencing [-Vocabulary For the terminology and assumptions used in this document, refer-] {+for UAs February 2003 - Create a conference - Join a conference - Invite a user+} to [-the conferencing requirements [5] and framework [4] documents. This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. For illustration of the possible applications we refer to the application vocabulary of ad-hoc, scheduled, server and end user. 3. Conferencing URIs A user agent that hosts conferences can have three types of URIs that resolve to it:-] a [-general URI,-] {+conference - Expel a user by third party - Discover if+} a [-focus-] URI [-and-] {+is a+} conference [-URIs. All three types assist in supporting different conferencing scenarios.-] {+URI+} The [-latter two are dedicated-] {+approach taken is+} to [-conferencing. The general URI and focus URI are likely-] {+use the feature parameter "isfocus"+} to [-be well known URIs in-] {+express+} that [-they would be published 3.1 Use of-] a [-General URI in Conferencing Using-] {+SIP dialog belongs to+} a [-general URI (typically referred as the userÆs address-] {+conference. The use+} of [-record), a focus can support creation, control,-] {+feature parameters in Contact header fields to describe the characteristics+} and [-manipulation-] {+capabilities+} of a [-conference in a similar manner to that common-] {+UA is described+} in [-PSTN today. Johnston & Levin Expires - April 2003 [Page 3] SIP Call Control - Conferencing for UAs October 2002 In this kind of scenario, inclusion-] {+the Caller Preferences and Callee Capabilities [7] document which includes the definition+} of the [-general URI-] {+"isfocus" feature parameter. 2.2 Session Establishment Usage In session establishment, a focus MUST include the "isfocus" feature parameter+} in the [-Request-URI would lead to a human user (in an end point) or-] {+Contact header field unless the focus wishes+} to [-an IVR service (in-] {+hide the fact that it is+} a [-conferencing server) for INVITEs generated from-] {+focus. To+} a [-conferencing unware UA as-] {+participant, the feature parameter+} will be [-shown in-] {+associated with+} the [-following sections. 3.2 Focus SIP-] {+remote target+} URI [-Another type-] of [-URI-] {+the dialog. It+} is [-what we will call-] {+an indication to a conference-aware UA that+} the [-focus URI. An INVITE sent-] {+resulting dialog belongs+} to {+a conference identified by+} the [-focus-] URI [-is a request to setup an ad-hoc conference, as will be shown-] in the [-following sections. 3.3 Conference SIP URI As specified in-] {+Contact header field and that+} the [-conferencing framework-] {+call control conventions defined in this+} document [-[4],-] {+can be applied. 2.3 OPTIONS Usage Currently+} the [-conference ID is a SIP URI. A URI which represents-] {+only met requirement is: given an opaque URI, being able to recognize whether it belongs to+} a [-particular-] {+certain+} conference [-instance-] {+(i.e. meaning that it+} is [-referred to as-] a conference [-URI. A request sent to this URI will result in a member being added (or removed, depending on the method) to (or from) a particular conference.-] {+URI) or not.+} As [-will be shown later,-] {+with any other OPTIONS request,+} it can be [-discovered from Contact header field in-] {+done either inside+} an [-INVITE or 200 OK in the-] {+active+} dialog [-establishment with-] {+or outside+} a [-focus. It can then be used-] {+dialog. A focus MUST include the "isfocus" feature parameter+} in a [-Request-URI or Refer-To header field to add members-] {+200 OK response+} to {+an OPTIONS unless+} the [-conference. 3.4 Globally Routable Contact Requirements As was specified before, the Conference URI MUST be globally routable. Since, according-] {+focus wishes+} to [-this document,-] {+hide+} the [-Contact header field is used to convey this URI, this requires-] {+fact+} that [-Contact URIs from a focus be globally routable URIs. This requirement-] {+it+} is [-identical to that in Section 8.1.1.8 in RFC 3261 [3]. However, the specified use in conferencing of the Contact URI outside of-] a [-dialog makes satisfying this requirement critical. If the focus requires that all requests be routed through-] {+focus. 3. SIP User Agent Conferencing Capability Types From+} a [-proxy server, then special care MUST be taken with-] {+conferencing perspective,+} the [-creation-] {+framework document outlines a number+} of [-this Contact URI. To satisfy this requirement, the Contact URI MUST either route to-] {+possible different SIP components such as conference-unaware participant, conference-aware participant, and focus. This document applies+} the [-proxy server or resolve-] {+concepts above+} to the [-proxy server, with an additional-] SIP [-registration step being required to further resolve this URI to-] {+call control part of+} the [-specific device. For example, consider a focus with a hostname server51.chicago.com which creates a conference URI. A normal Contact could be-] {+conferencing components. It defines normative behavior+} of the [-form: Contact: ;isFocus-] {+SIP UAs in various conferencing situations (referred later as "scenarios").+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page 4] {+Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 (The "isFocus" parameter is described-] {+February 2003 3.1 Focus UA A focus, as defined+} in [-Section 5.2 below.) However, if this-] {+the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A+} focus [-requires that all requests come through-] {+contains+} a [-proxy server at p1.chicago.com then this Contact will not work-] {+conference-aware user agent that supports the conferencing call control conventions+} as {+defined in this document. A focus SHOULD support+} the [-proxy will be bypassed. One approach is to include an escaped loose Route-] {+conference package [5] and indicate so in Allow-Events+} header [-field-] {+fields+} in {+requests and responses. A focus MAY include information about+} the [-Contact URI: Contact: ;isFocus This would result-] {+conference+} in [-a request being sent to sip:389390542457@serv51.chicago.com-] {+SDP message bodies sent. A user agent+} with [-a loose Route header forcing routing to sip:p1.chicago.com first. EditorÆs Note: Open Issue: This syntax, while allowed-] {+focus capabilities could be implemented+} in [-a redirection,-] {+end user equipment and would be used for the creation of ad-hoc conferences. A dedicated conferencing server, whose primary task+} is [-not permitted-] {+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 [-INVITE or 200 OK response per Table 1 in RFC 3261. Another approach would involve a Contact-] {+arbitrary number+} of {+ad-hoc conferences (and subsequently their focuses) using SIP call control means. 3.2 Conference Factory URI According to+} the [-form: Contact: ;isFocus-] {+framework, there are many ways+} in which [-this sip:389390542457@chicago.com URI would be registered by the focus against-] a [-Contact: Contact: which resolves directly to the focus. Other approaches may also-] {+conference can+} be [-used-] {+created. These are open+} to [-generate this globally routable Contact URI. 4. SIP User Agent Conferencing Capability Types We can identify three different SIP user agent (UA) applications regarding their-] {+the+} conferencing [-capabilities. 4.1 Type I --] {+server implementation policy and include non-automated means (such as IVR), SIP, and the conference policy control protocol. In order to automatically create an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means, a globally routable+} Conference [-Unaware-] {+Factory URI can be allocated and published. A successful attempt to establish a call to this URI would result in the automatic creation a new conference and its focus. As a result, note that the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices. A scenario showing the use of the conference factory URI is shown in Section 4.5. 3.3 Conference-Unaware+} UA The simplest user agent can participate in a conference ignoring all SIP conferencing-related information. The simplest user agent is able to dial into a conference and to be invited to a conference. [-All-] {+Any+} conferencing information [-(if any)-] is {+potentially+} conveyed to it using non-SIP {+Johnston & Levin Expires August 8, 2003 [Page 5] Internet-Draft SIP CC Conferencing for UAs February 2003+} means. Such [-s-] {+a+} user agent would not usually host a conference (at least, not using SIP explicitly). A [-Type I-] {+conference-unaware+} UA [-need-] {+needs+} only {+to+} support RFC 3261 [-[3].-] {+[2].+} Call flows for [-Type I-] {+conference-unaware+} UAs are not shown in general in this document as they would be identical to those in the SIP [-Call Flows document [10]. 4.2 Type II - Conference Member Capable-] {+call flows [13] document. 3.4 Conference-Aware+} UA [-Johnston & Levin Expires - April 2003 [Page 5] SIP Call Control - Conferencing for UAs October 2002-] A [-Type II-] {+conference-aware+} user agent [-can support SIP conferencing conventions and extensions merely as a conference member. Such user agents do not have focus capabilities. From a SIP requirements perspective, a Type II UA would support REFER [11],-] {+supports+} SIP [-Events [12], the conferencing package [13], and the conventions of-] conferencing call control {+conventions+} defined in this [-document,-] {+document as a conference participant,+} in addition to support of RFC 3261. [-4.3 Type III - Conference Member and/or Focus Capable-] {+A conference-aware+} UA [-The next level of user agents-] {+MUST recognize the "isfocus" feature parameter. A conference-aware UA SHOULD support REFER [3], SIP events [4], and the conferencing package [5]. A conference-aware UA SHOULD subscribe to the conference package if the "isfocus" parameter+} is [-capable-] {+in the remote target URI+} of [-both being-] a [-conference member-] {+dialog+} and [-a-] {+if the+} conference [-focus. This-] {+package+} is {+listed by+} a [-special capability and can be discovered using the techniques described-] {+focus+} in [-Section 5. A user agent of this type could be implemented in end user equipment and would be used for ad-hoc creation of small to middle size conferences. Alternatively, a type III-] {+an Allow-Events header field. A conference-aware+} UA [-could be a dedicated conferencing server whose primary task is-] {+MAY render+} to [-host conferences of-] {+the user+} any [-type and size. Note that a certain conference instance can bridge members having different capabilities who have joined-] {+information about+} the conference [-by different means (i.e. dial-in, dial-out, scheduled-] {+obtained from the SIP header fields+} and [-ad-hoc). A conference server typically will not be a single device but a function decomposed into media servers, IVR systems, etc-] {+SDP fields from the focus. 4. SIP Conferencing Primitives The SIP conferencing call control flows presented in this section are the call control building blocks for various SIP tight conferencing applications+} as described in the [-Application Components document [14]. In this document, however, it will be discussed as if it were a UA with certain focus capabilities. A conference server will likely have all three types of URIs (as specified above) that resolve to it: a general URI, a focus URI,-] {+conferencing requirements [8]+} and [-conference URIs. 5. Discovery of Conferencing Capabilities using OPTIONS-] {+framework [9] documents.+} The [-general means of capability discovery in SIP-] {+major design goal+} is {+that+} the [-OPTIONS method as detailed in Section 11 of RFC 3261 [3]. This-] same [-method can-] {+SIP conferencing primitives would+} be used by {+user agents having different conferencing capabilities and comprising different applications. 4.1 Joining a Conference using the Conference URI - Dial In In this section+} a user [-agent-] {+knows the conference URI and "dials in"+} to [-discover conferencing capabilities. 5.1 Requirements Review Currently-] {+join this conference. If+} the [-only requirement-] {+UA+} is {+the first participant of the conference+} to [-distinguish between Type I/II vs. Type III user agents. Should additional conferencing extensions defined in future, means-] {+dial in, it is likely that this INVITE will create the focus and hence the conference. However, the conference URI must have been reserved prior+} to [-distinguish between Type I vs. Type II user agents may be required.-] {+its use. If the conference is up and running already, the dialing-in participant is joined to the conference by its focus. To join an existing specific conference a UA SHOULD send an INVITE+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page 6] {+Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 5.2 Definitions A UA MAY send an OPTIONS request to discover the conferencing capabilities of another UA. If the UA responding to the query has conferencing-related capabilities and wants to share this information, it can do so in the reply to the OPTIONS request. If the UA identified by the general URI in-] {+February 2003 with+} the [-OPTIONS request has an ability-] {+Request-URI set+} to [-act as a focus, the OPTIONS response SHOULD indicate this by the inclusion of-] the {+conference URI. The+} focus [-URI with "isFocus" caller prefs-] {+MUST include the "isfocus" feature+} parameter [-[15]-] in [-a Contact header field. EditorÆs Note: This-] {+the+} Contact header field [-"isFocus" parameter is currently not defined in the base caller prefs [Error! Bookmark not defined.] document, but needs be added as an extension. This OPTIONS request can be sent outside a dialog (pre-call) or within an established dialog (mid-call). In both cases, inclusion-] of the [-"isFocus" parameter in a Contact header in the reply-] {+200 OK response+} to the [-OPTIONS request expresses the ability of-] {+INVITE. An example call flow is shown in Figure 1. Alice Focus Bob Carol | | | | | Carol joins+} the [-UA to host a-] conference [-(i.e. having focus capabilities) as opposite to having a focus active for this call. A UA receiving an OPTIONS request SHOULD generate a well-formed response containing Allow, Accept, Allow-Events, and Supported, and Contact header fields. An OPTIONS query sent to either-] {+| | | | | | 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 [-general or focus URIs would likely return Contact URIs listing both the general URI and-] {+Conference using+} the [-focus-] {+Conference+} URI. [-An OPTIONS query to the general or focus URI would not return-] {+4.2 Adding+} a [-list of active conference URIs hosted-] {+Participant+} by the [-server. This information can be retrieved using-] {+Focus - Dial Out To directly add+} a [-method TBD. OPEN ISSUE: In general, nothing in this specification prohibits conference URIs discovery using the OPTIONS method. That being said, currently, there is no way-] {+participant+} to [-distinguish between-] {+a conference, a+} focus [-URI and conference URI:-] {+SHOULD send+} an [-OPTIONS sent-] {+INVITE+} to [-a particular conference URI would return a response-] {+the participant+} containing [-that conference URI in-] a Contact [-containing-] {+header field with+} the [-"isFocus" parameter, same as for a focus URI. OPEN ISSUE: Should an OPTIONS request sent to a-] conference URI [-not return the focus URI? Or-] {+and+} the [-general URI?-] {+"isfocus" feature parameter.+} Note that {+a conference-unaware UA would simply ignore+} the [-Allow, Accept, Allow-Events,-] {+conferencing information+} and [-Supported header fields should be present in an INVITE from-] {+treat the session (from+} a [-focus or-] {+SIP perspective) as+} a [-200 OK answer from-] {+point to point session. An example call flow is shown in Figure 2. It is assumed that Alice is already a participant of+} the {+conference. The+} focus {+invites Carol+} to {+the conference by sending+} an [-INVITE as a part of a normal dialog establishment process. Inclusion of the Contact header with "isFocus" Johnston & Levin Expires - April 2003 [Page 7] SIP Call Control - Conferencing for UAs October 2002 parameter by the focus signals to a UA that the dialog is a part of a conference identified by the URI in the Contact header. 5.3 Examples This section contains an example response to an OPTIONS request sent by Alice to Carol (sent to Carol's address of record, i.e. general URI). Based on the response, Alice's UA learns that Carol's UA has conferencing and focus capabilities (Type III UA), and learns the focus URI which could be used later to invoke conferencing services. The response details are as follows: SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Contact: ;isFocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: refer, conference Accept: application/sdp, application/conference-info+xml, message/sipfrag Accept-Language: en Supported: pref, replaces Content-Type: application/sdp Content-Length: 274 (SDP not shown) Useful information from each of these headers is detailed in the next sections. Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicate that the user agent supports call control and SIP Events. Accept. The support of bodies such as message/sipfrag, application/conference-info+xml also indicates support of call control and conferencing. Allow-Events. The support of event packages such as refer, conference. Supported. The support of extensions such as caller prefs [Error! Bookmark not defined.] and replaces [16]. Johnston & Levin Expires - April 2003 [Page 8] SIP Call Control - Conferencing for UAs October 2002 Editor's Note: If an extension tag for some TBD conferencing related extensions is defined, it would be present here. Contact. This OPTIONS response contains two Contact header fields. The first one is just Carol's address of record (i.e.-] {+INVITE. After+} the [-general URI) for-] session [-establishment, etc. The second Contact URI is the URI of Carol's focus. This can be determined by the presence of the "isFocus" caller preferences [Error! Bookmark not defined.] parameter. The presence of a Contact with this parameter confirms that Carol's UA is a Type III UA. 6. SIP Conferencing Implementation Note that most the scenarios described below apply equally for ad-hoc or reserved conference, with the exception of Sections 6.2 and 6.3 on creating a conference which does not apply to a reserved conference. 6.1 SIP Conferencing Building Blocks The scenarios presented below are the call control building blocks for various SIP tight conferencing applications as described in the conferencing requirements [5] and framework documents [4]. In the sections below we present typical SIP conferencing call control flows and discuss the applicability of each for different conferencing situations. The major design goal-] is [-that the same SIP conferencing building blocks would be used by user agents having different conferencing capabilities and comprising different applications. 6.2 Creating a Conference This section addresses creating an ad-hoc conference by interaction with a focus URI with the focus being responsible for the conference ID generation. This approach requires awareness of conferencing information from the members. Only a Type II UA will know-] {+established, Carol subscribes+} to [-retrieve-] the conference [-information (from the Contact header) and use it for adding new members. The benefit of this approach is that the details and conventions of the deployed conferencing infrastructure are transparent to the members (and the participating users), since they treat the Conference ID merely as an opaque-] URI. [-That allows for building automated end user applications in a play-and-plug manner. To create a conference, a UA SHOULD send an INVITE (with the Request- URI set to the focus URI)-] {+It is important+} to [-the focus-] {+note+} that [-will host-] {+there is no dependency on Carol's SUBSCRIBE (F5) and+} the [-conference.-] {+NOTIFY to Alice (F9) - they occur asynchronously and independently.+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page [-9]-] {+7] Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 The SIP URI of the focus can be provisioned in the UA or can be discovered using any of-] {+February 2003 Alice Focus Bob Carol | | | | |<==================>| | | | | | | Focus "dials out" to add Carol to+} the [-means described earlier in this document. The focus can distinguish this-] {+conference | | | | | |+} INVITE [-request as-] {+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 [-request-] {+Participant+} to [-create-] {+the Conference. 4.3 Manually Creating+} a [-new ad-hoc conference from-] {+Conference by Dialing into+} a [-request to join-] {+Conferencing Application In this section, a user sends+} an [-existing-] {+INVITE to a+} conference [-by-] {+server application. The application (such as an IVR system or a web page) is implemented because+} the [-Request-URI. In this flow,-] {+system requires additional input from+} the [-focus-] {+user before it+} is {+able to create+} a [-Type III UA, so it maintains different types of URIs as discussed in the previous sections. Assuming that all security-] {+conference. After a normal dialog is established, additional information is received+} and [-policy requirements have been met,-] the {+conference together with its+} focus [-SHOULD create-] {+are created. At this point+} the conference {+server MUST re-INVITE the user+} with the [-Contact-] {+conference+} URI [-returned-] in {+Contact with+} the [-200 OK being-] {+"isfocus" feature parameter. Alternatively,+} the [-conference URI. The Contact header field SHOULD contain-] {+additional information MAY be provided by+} the [-"isFocus" parameter to indicate that this URI is for-] {+user during an early dialog established. This could be accomplished by+} a [-conference. The UA creating-] {+183 Session Progress response sent by the conferencing application. After+} the conference [-SHOULD send a SUBSCRIBE to-] {+is created,+} the conference URI [-with-] {+MUST then be Johnston & Levin Expires August 8, 2003 [Page 8] Internet-Draft SIP CC Conferencing for UAs February 2003 returned in a Contact in+} the [-conference event package.-] {+200 OK.+} An example call flow is shown in Figure [-1. Note that Focus is shorthand for the focus URI and Conf-ID Is short for the conference URI.-] {+3.+} In this [-flow,-] {+example,+} Alice [-creates-] {+uses+} a conference [-by sending-] {+application which is triggered when Alice sends+} an INVITE to the [-focus URI. Once the media session-] {+conference application. In this example, Conf-App+} is [-established, Alice subscribes-] {+used+} to {+represent+} the conference [-URI obtained through-] {+application URI. Alice's conference-aware UA learns of+} the [-Contact in-] {+existence of+} the [-200 OK response-] {+conference+} from the [-focus.-] {+"isfocus" feature parameter and subscribes to the conference package to receive notifications of the conference state.+} Alice Focus Bob Carol | | | | | Alice [-creates the conference. |-] {+establishes session with conference application.+} | | | | | | INVITE [-sip:Focus F1|-] {+sip:Conf-App F1+} | | |------------------->| | | | 180 Ringing F2 | | | |<-------------------| | | | 200 OK [-Contact:Conf-ID;isFocus-] F3 | | {+|+} |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | | | | | | Alice [-subscribes-] {+uses the application+} to {+create+} the [-conference URI.-] {+conference. | | | | | | INVITE Contact:Conf-ID;isfocus F5 | | |<-------------------| | | | 200 OK F6 | | | |------------------->| | | | ACK F7 | | | |<-------------------| | | | RTP | | | |<==================>|+} | | | | | | | SUBSCRIBE sip:Conf-ID [-F5-] {+F8+} | | |------------------->| | | | 200 OK [-F6-] {+F9+} | | | |<-------------------| | | | NOTIFY [-F7-] {+F10+} | | | |<-------------------| | [-| Johnston & Levin Expires - April 2003 [Page 10] SIP Call Control - Conferencing for UAs October 2002 |-] {+| |+} 200 OK [-F8-] {+F11+} | | | |------------------->| | | Figure [-1. Creation of-] {+3. A Participant Creates+} a [-Conference. 6.3-] {+Conference using an Application. Johnston & Levin Expires August 8, 2003 [Page 9] Internet-Draft SIP CC Conferencing for UAs February 2003 4.4+} Creating a Conference by a [-Type I-] {+Conference-Unaware+} UA It is a requirement that a [-Type I UA-] {+user (human)+} be able to {+use a conference-unaware UA to+} create and add participants to a [-conference without understanding any of the conferencing conventions or extensions (such as in Section 6.2 above). The only way to accomplish this is for the participant (human) to choose the conference URI in the domain of the focus URI. The disadvantages of this approach are discussed later in the section.-] {+conference.+} 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 [-members-] {+participants+} could be added by non-SIP means (publication of the chosen conference URI using web pages, email, IM, etc.). Alternatively, the [-Type I-] {+conference-unaware+} UA could then add other participants to the conference using SIP call control by establishing a session with them, then transferring {+[16]+} them to the conference [-URI [17].-] {+URI.+} Note that {+in this scenario+} only the [-participant-] {+user+} (human) is aware of the conferencing application, and the [-Type I-] {+conference-unaware+} UA only need support RFC 3261 and optionally call transfer. Making this work does impose certain [-requirements-] {+addressing conventions+} on a [-focus.-] {+system.+} As a service/implementation choice, a [-focus-] {+system+} could allow the creator of the conference to choose the user portion of the conference URI. However, this requires {+the+} URI [-and behavior conventions-] {+format+} to be [-used by both members-] {+agreed upon between a user+} and the [-focus.-] {+system.+} For example, a service {+provider+} might reserve the domain conf.example.com for all conference URIs. [-The focus-] {+Any+} URI [-could be sip:focus@conf.example.com.-] {+in the domain of conf.example.com would resolve to the focus.+} The focus could be configured to interpret an unknown [-Request-URI-] {+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 [-who-] {+that+} would then create [-a-] {+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: [-;isFocus.-] {+Contact: ;isfocus+} Note, however, that this approach relies on conventions adopted between the [-participant-] {+user+} (human) and the focus. [-Johnston & Levin Expires - April 2003 [Page 11] SIP Call Control - Conferencing for UAs October 2002-] {+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, [-the method-] {+methods+} of {+conference creation in which+} the conference URI [-as-] {+is+} an opaque URI [-being-] generated by the focus [-(as per Section 6.2) is-] {+are+} preferred. [-To join an existing specific conference a UA SHOULD send an INVITE to the conference URI chosen by the first participant. The rest of this scenario is shown in Section 6.4.-] {+Johnston & Levin Expires August 8, 2003 [Page 10] Internet-Draft SIP CC Conferencing for UAs February 2003+} An example call flow is shown in Figure [-2.-] {+4.+} The participant Alice creates the conference URI (using some convention agreed to with the focus domain) and sends an INVITE to that URI which [-reaches-] {+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 [-Type I-] {+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-] {+Contact:Conf-ID;isfocus+} F3 | | |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | Figure [-2.-] {+4.+} A Conferencing Unaware [-(Type I) UA-] {+Participant+} Creates a Conference [-6.4 Dialing into-] {+4.5 Creating+} a Conference [-by Conference URI In this-] {+using Ad-Hoc SIP Methods This+} section {+addresses creating+} a [-UA knows the-] conference [-URI and "dials in" to join this conference.-] {+by using ad-hoc SIP means.+} The conference {+factory+} URI [-can be reserved using non-SIP mechanisms, or generated using the methods of Sections 6.2 or 6.3. If the UA-] {+(as defined in Section 2.4)+} is [-the first member of-] {+used to automatically create+} the conference [-to dial in, it-] {+in this example. The benefit of this approach+} is [-likely-] that [-this INVITE will "create" the conference. However,-] the conference URI [-must have been created prior-] {+need not be known+} to [-its use. When-] the [-conference-] {+user - instead it+} is [-up-] {+created by a focus+} and [-running already,-] {+used by+} the [-dialing-in member-] {+participants’ UAs. The main difference between this scenario and Section 4.3+} is [-joined-] {+that no user intervention (IVR, web page form, etc.) is required+} to {+create the conference. The SIP URI of+} the conference [-by-] {+factory can be provisioned in the UA (as in+} a [-focus. To-] {+"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 [-specific-] conference [-a UA SHOULD send an INVITE to-] {+by+} the [-conference URI. Johnston & Levin Expires - April 2003 [Page 12] SIP Call Control - Conferencing for UAs October 2002-] {+Request-URI.+} Assuming that all security and policy requirements have been met, [-the focus SHOULD establish the session-] {+a new conference will be created+} with the [-UA and "mix"-] {+Contact URI returned in+} the [-media appropriately with existing conference members. The UA SHOULD subscribe to-] {+200 OK being+} the conference [-URI with-] {+URI. The Contact header field MUST Johnston & Levin Expires August 8, 2003 [Page 11] Internet-Draft SIP CC Conferencing for UAs February 2003 contain+} the [-conference event package. The focus SHOULD notify other members-] {+"isfocus" feature parameter to indicate+} that {+this URI is for+} a [-new member has been added.-] {+conference.+} An example call flow is shown in Figure [-3. It is assumed-] {+5. Note+} that [-Alice-] {+Conf-Factory+} is [-already in-] {+shorthand for the conference factory URI and Conf-ID Is short for+} the conference [-(has-] {+URI. In this flow, Alice has a conference-aware UA and creates+} a {+conference by sending an INVITE to the conference factory URI. Once the media+} session [-established with-] {+is established, Alice subscribes to+} the [-focus).-] {+conference URI obtained through the Contact in the 200 OK response from the focus.+} Alice Focus Bob Carol | | | [-|<==================>| |-] | | [-Carol "dials in" to-] {+Alice creates+} the [-conference-] {+conference. |+} | | | | | | INVITE [-sip:Conf-ID-] {+sip:Conf-Factory+} F1 | | [-|<----------------------------------------|-] {+|------------------->| |+} | | 180 Ringing F2 | | [-|---------------------------------------->|-] {+| |<-------------------| |+} | | 200 OK [-Contact:Conf-ID;isFocus-] {+Contact:Conf-ID;isfocus+} F3 | | [-|---------------------------------------->|-] {+|<-------------------| |+} | | ACK F4 | | [-|<----------------------------------------|-] {+| |------------------->| |+} | | RTP | | [-|<=======================================>|-] | {+|<==================>|+} | [-SUBSCRIBE sip:Conf-ID F5-] | | [-|<----------------------------------------|-] | | [-200 OK F6-] | | [-|---------------------------------------->|-] {+Alice subscribes to the conference URI.+} | | [-NOTIFY F7-] | | [-|---------------------------------------->|-] {+| | | SUBSCRIBE sip:Conf-ID F5 | | |------------------->| |+} | | 200 OK [-F8-] {+F6 | | | |<-------------------|+} | | [-|<----------------------------------------|-] | NOTIFY [-F9-] {+F7 |+} | | |<-------------------| | | {+|+} 200 OK [-F10-] {+F8 |+} | | |------------------->| | {+|+} Figure [-3.-] {+5. Creation of a Conference using SIP Ad-Hoc Methods. 4.6 Requesting the Focus Add a New Resource to a Conference+} A [-member "dials in"-] {+SIP conference URI can be used to inject different kinds of information into the conference. Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs). To request the focus add a new information resource to the specified Johnston & Levin Expires August 8, 2003 [Page 12] Internet-Draft SIP CC Conferencing for UAs February 2003 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 [-an existing conference. 6.5 Dial out - Added-] {+the conference URI and not the conference factory URI, the semantics to the focus are to bring the resource into the conference and make it visible to the conference participants. The resultant focus procedures are dependant both on the nature of the new resource (as expressed+} by {+its URI) and+} the [-Focus Johnston & Levin Expires - April 2003 [Page 13] SIP Call Control - Conferencing-] {+own focus policies regarding IM, central vs. distributed real time media processing, etc. The scenario+} for [-UAs October 2002 This section-] {+adding a new UA participant+} is [-equally applicable for both ad-hoc-] {+important to support because it works even if the new participant does not support REFER+} and [-reserved conferences. To directly add a member-] {+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 [-conference,-] {+Refer-To header with+} a {+SIP URI, the+} focus SHOULD send an INVITE to the [-member-] {+new participant identified by the Refer-To SIP URI+} containing a Contact header field with the conference URI and the [-ôisFocusö header-] {+"isfocus" feature+} parameter. [-The resulting media session SHOULD be appropriately mixed with the media from the other members. The new member SHOULD subscribe to the conference ID from the Contact from the INVITE. The simplest-] {+A conference-unaware+} UA [-(as in Type I)-] would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point to point session. [-The focus SHOULD notify other participants that a new member has been added.-] An example call flow is shown in Figure [-4.-] {+6.+} It is assumed that Alice is already a [-member-] {+participant+} of the conference. {+Alice sends a REFER to the conference URI.+} The focus invites Carol to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. {+It is important to note that there is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to Alice (F15) - they occur asynchronously and independently.+} Alice Focus Bob Carol | | | | [-|<==================>|-] {+|<==================>| | | | REFER sip:Conf-ID Refer-To:Carol F1 | | |------------------->| | | 202 Accepted F2 | | |<-------------------| | | NOTIFY (Trying) F3 | |<-------------------| | | 200 OK F4 |+} | {+|------------------->|+} | | | | | Focus "dials out" to [-add-] {+join+} Carol to the conference | | | | | | INVITE [-Contact:Conf-ID;isFocus F1-] {+Contact:Conf-ID;isfocus F5+} | | |---------------------------------------->| | | 180 Ringing [-F2-] {+F6+} | {+Johnston & Levin Expires August 8, 2003 [Page 13] Internet-Draft SIP CC Conferencing for UAs February 2003+} | |<----------------------------------------| | | 200 OK [-F3-] {+F7+} | | |<----------------------------------------| | | ACK [-F4-] {+F8+} | | |---------------------------------------->| | | RTP | | |<=======================================>| | {+NOTIFY (OK) F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | |+} | SUBSCRIBE sip:Conf-ID [-F5-] {+F11+} | | |<----------------------------------------| | | 200 OK [-F6-] {+F12+} | | |---------------------------------------->| | | NOTIFY [-F7-] {+F13+} | | |---------------------------------------->| | | 200 OK [-F8-] {+F14+} | | |<----------------------------------------| | NOTIFY [-F9-] {+F15+} | | [-Johnston & Levin Expires - April 2003 [Page 14] SIP Call Control - Conferencing for UAs October 2002-] |<-------------------| | | 200 OK [-F10-] {+F16+} | | |------------------->| | Figure [-4.-] {+6. Participant Requests+} Focus [-"dials out" to-] add [-Carol to the conference. 6.6 Requesting the Focus Add-] a [-New Resource-] {+Participant+} to [-a-] {+the+} Conference. [-A SIP conference-] {+4.7 Adding a 3rd Party Using Conference+} URI [-can be used to inject different kinds of information into the conference. Examples include new members, new real-time media sources, new IM messages, and pointers-] {+A participant wishing+} to [-passive information references (such as HTTP URIs). To request the focus-] add a new [-information resource-] {+participant will request this participant+} to [-the specified conference, any SIP UA can-] send [-a REFER-] {+an INVITE+} to the conference [-URI with-] {+URI. This can be done using+} a [-Refer-To containing the URI of the new resource. Since this REFER is sent to the conference URI and not the focus URI, the semantics to the focus are to bring the resource into the conference and make it visible to the conference members. The resultant focus procedures are dependant both on the nature of the new resource (as expressed by its URI) and the own focus abilities regarding IM, central real time media processing, etc. The flow for adding-] {+non-SIP means (such as passing or publishing the conference URI in an email, IM, or web page). If+} a [-new UA member-] {+non-SIP means+} is [-important to consider because it works even if the new member does not support REFER and transfer call control - only-] {+used, then+} the [-requesting member-] {+flow+} and [-the focus need-] {+requirements are identical+} to [-support the call control. Upon receipt of-] {+Section 4.1. The SIP mechanism to do this utilizes+} the REFER [-containing a Refer-To header with-] {+method. A UA wishing to add+} a [-SIP URI, the focus-] {+new participant+} SHOULD send [-an INVITE-] {+a REFER request+} to the [-new member identified by the Refer-To SIP URI containing-] {+participant with+} a [-Contact-] {+Refer-To+} header [-field with-] {+containing+} the conference URI and the [-"isFocus" header-] {+"isfocus" feature+} parameter. The [-resulting media session SHOULD be appropriately mixed with the media from the other members. The new member SHOULD subscribe-] {+requirements are then identical+} to the [-conference ID from the Contact from the INVITE.-] {+"dial in" case of Section 4.1.+} The [-simplest UA (as in Type I) would simply ignore the conferencing information and treat-] {+inviting participant MAY receive notification through+} the [-session (from a SIP perspective) as a point to point session. The focus SHOULD notify other participants-] {+REFER action+} that [-a-] {+the+} new [-member-] {+participant+} has been [-added.-] {+added in addition to the notification received through the conference package.+} An example [-call flow-] is shown in Figure [-5. It-] {+7. In this call flow, it+} is assumed that Alice is already a [-member-] {+participant+} of the conference. Alice sends [-a REFER to the conference URI. The focus invites Carol to the conference by sending-] Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page [-15]-] {+14] Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002-] {+February 2003 Bob+} an [-INVITE. After-] {+"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 [-session is established, Carol subscribes to-] {+dialog, effectively transferring Bob into+} the conference [-URI.-] {+[16].+} Alice Focus Bob Carol | | | | |<==================>| | | | {+| | | | Alice adds Bob into conference | | | | | | |+} REFER [-sip:Conf-ID Refer-To:Carol-] {+Refer-To:Conf-ID+} F1 | | [-|------------------->|-] {+|---------------------------------------->|+} | | 202 Accepted F2 | | [-|<-------------------|-] | {+|<----------------------------------------|+} | | {+NOTIFY (Trying) F3|+} | | [-Focus "dials out" to add Carol to the conference-] {+|<----------------------------------------| | | 200 OK F4+} | | | {+|---------------------------------------->|+} | | | INVITE [-Contact:Conf-ID;isFocus F3-] {+sip:Conf-ID F5+} | | [-|---------------------------------------->|-] {+|<-------------------| |+} | | 180 Ringing [-F4 | | |<----------------------------------------| |-] {+F6+} | [-200 OK F5-] | | [-|<----------------------------------------|-] {+|------------------->|+} | | [-ACK F6-] | {+200 OK Contact:Conf-ID;isfocus F7+} | [-|---------------------------------------->|-] | {+|------------------->|+} | [-RTP-] | | [-|<=======================================>|-] {+ACK F8+} | [-NOTIFY F7-] | | |<-------------------| | | [-200 OK F8-] | {+RTP+} | [-|------------------->|-] | | {+|<==================>|+} | [-SUBSCRIBE sip:Conf-ID-] {+| NOTIFY (OK)+} F9 | | {+|+} |<----------------------------------------| | | 200 OK F10 | | {+|+} |---------------------------------------->| | | NOTIFY F11 | | [-|---------------------------------------->|-] {+| |<-------------------| |+} | | 200 OK F12 | | [-|<----------------------------------------|-] | [-NOTIFY-] {+|------------------->| | | | | SUBSCRIBE sip:Conf-ID+} F13 | | |<-------------------| | | {+|+} 200 OK F14 | | {+|+} |------------------->| | [-Figure 5. Member Requests Focus add member to the conference. 6.7 Adding a 3rd Party Using Conference ID This section is equally applicable for both ad-hoc and reserved conferences.-] {+| | NOTIFY F15 | | | |------------------->| | | | 200 OK F16 | | | |<-------------------| |+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page [-16]-] {+15] Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 A member wishing to add-] {+February 2003 Figure 7. Adding+} a [-new member simply requests another participant-] {+Participant+} to [-send-] an [-INVITE-] {+Existing Conference. 4.8 Adding a 3rd Party Using a Dialog Identifier Under some circumstances, a participant wanting+} to [-the conference URI. This can be done using-] {+join+} a [-non-SIP means (such as passing or publishing the-] conference [-URI in an email, IM, or web page). If-] {+may only know+} a [-non-SIP means is used, then-] {+dialog identifier of one of+} the [-flow-] {+legs of the conference+} and [-requirements are identical to Section 6.4.-] {+the conference factory URI, instead of the conference URI.+} The [-SIP mechanism-] {+information may have been learned using the dialog package [17] or some non-SIP means+} to [-do-] {+retrieve+} this [-utilizes the REFER method.-] {+information from a conference participant.+} A UA [-wishing-] {+can request to be added+} to [-add-] a [-new member SHOULD send-] {+conference by sending+} a [-REFER-] request to the [-member with-] {+focus containing+} a [-Refer-To-] {+Join [6]+} header {+field+} containing [-the conference URI. The requirements are then identical to the "dial in" case-] {+a dialog ID of one leg+} of [-Section 6.4. The UA MAY receive notification through-] the [-REFER action that-] {+conference (a dialog between a participant and+} the [-new member has been added-] {+focus). There are other scenarios+} in [-addition to the notification received through-] {+which a UA can use+} the [-conference package.-] {+Join header for certain conferencing call control scenarios. See [6] for further examples and details.+} An example is shown in Figure [-6. In this call flow, it-] {+8. It+} is assumed that Alice is [-already-] a [-member-] {+participant+} of the conference. {+The dialog identifier between+} Alice [-sends Bob an "out of band" REFER - that is, a REFER outside of an established dialog. Should-] {+and the focus is abbreviated as A-F and is known by Bob.+} Bob [-reject-] {+requests to be added to+} the [-REFER, Alice might try-] {+conference by+} sending an INVITE {+message F1+} to [-Bob to establish a session first, then send-] {+the focus containing+} a [-REFER within-] {+Join header which contains+} the [-dialog, effectively transferring Bob into-] {+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 [-conference-] {+dialog event package+} [17]. [-Alice Focus Bob Carol | | | | |<==================>| | | | | | | | Alice adds-] Bob {+is added+} into {+the+} conference {+by the focus. Johnston & Levin Expires August 8, 2003 [Page 16] Internet-Draft SIP CC Conferencing for UAs February 2003 Alice Focus Bob Carol+} | | | | {+|<==================>|+} | | | [-REFER Refer-To:Conf-ID F1 | | |---------------------------------------->| | | 202 Accepted F2 | | | |<----------------------------------------| | | NOTIFY F3-] | | | [-|<----------------------------------------|-] | {+Bob requests to be added to the conference.+} | [-200 OK F4-] | | | [-|---------------------------------------->|-] | | | INVITE [-sip:Conf-ID F5-] {+Join:A-F F1|+} | | |<-------------------| | | | 180 Ringing [-F6-] {+F2+} | | | |------------------->| | | | 200 OK [-Contact:Conf-ID;isFocus F7-] {+Contact:Conf-ID;isfocus F3+} | | |------------------->| | | | ACK [-F8-] {+F4+} | | | |<-------------------| | | | RTP | | | |<==================>| | | | [-NOTIFY F9 | | Johnston & Levin Expires - April 2003 [Page 17] SIP Call Control - Conferencing for UAs October 2002 |<----------------------------------------| | | | 200 OK F10 | | |---------------------------------------->| | | NOTIFY F11 | | | |<-------------------| | | | 200 OK F12 | | | |------------------->| | | | |-] SUBSCRIBE sip:Conf-ID [-F13-] {+F5+} | | |<-------------------| | | | 200 OK [-F14-] {+F6+} | | | |------------------->| | | | NOTIFY [-F15-] {+F7+} | | | |------------------->| | | | 200 OK [-F16-] {+F8+} | | | |<-------------------| | Figure [-6.-] {+8.+} Adding a [-member-] {+Participant+} to an [-existing conference. 6.8 Adding a 3rd Party Using Call ID Under some circumstances, a member wanting to join-] {+Existing Conference using Join. 4.9 Bringing+} a [-conference may only know-] {+Point-to-Point Dialog into+} a [-dialog ID of one of the legs of the conference and the-] {+Conference A+} focus [-URI, instead-] {+is capable+} of [-the conference URI. The information may have been learned using the-] {+bringing an existing point-to-point+} dialog [-package [18] or some non-SIP means. If A-] {+with another+} UA [-can request to be added-] to a conference {+that the focus hosts. The focus would do it+} by sending [-a request-] {+re-INVITE changing the Contact URI+} to the {+conference URI with the "isfocus" feature parameter. By doing this, the+} focus [-containing a Join [19] header field containing-] {+signals to the UA that it becomes+} a [-dialog ID of one leg-] {+participant+} of the [-conference (a-] {+conference, specified in the Contact header. Currently, there is no way for a UA, being in an active point-to-point call with a focus, to express by SIP call control means a request to bridge its+} dialog [-between-] {+with a specific conference or to create+} a [-member-] {+new conference+} and {+include+} the [-focus). There are other scenarios-] {+dialog+} in [-which-] {+this conference. Instead,+} a [-Type III or even Type II-] {+new dialog will need to be created. Even if the+} UA [-which is capable of creating-] {+discovers that the other side has focus capabilities, the UA needs to close the old session and to establish+} a [-conference can use-] {+new session/dialog with+} the [-Join header for certain conferencing call control scenarios. The Join header field is also useful in-] {+focus. 4.10 Requesting+} the [-transition of-] {+Focus Remove+} a [-two party call to-] {+Participant from+} a [-conference call, as described in [20].-] {+Conference Johnston & Levin Expires August 8, 2003 [Page 17] Internet-Draft SIP CC Conferencing for UAs February 2003+} To request [-a conference member to be added to-] the [-conference without knowing-] {+focus remove a participant from+} the [-conference URI,-] {+specified conference,+} a {+properly authorized SIP+} UA [-SHOULD-] {+(typically the conference owner) can+} send [-an INVITE request-] {+a REFER+} to the [-focus-] {+conference+} URI [-containing-] {+with+} a [-Join header field. The Join header field MUST contain-] {+Refer-To containing+} the [-dialog identifier-] {+URI+} of [-a valid dialog between-] the [-focus-] {+participant+} and {+with+} the [-member. An example is shown in Figure 7. It is assumed that Alice is a member of the conference.-] {+method set to BYE.+} The {+requestor does not need to know the dialog information about 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-] {+participant who will be removed -+} the focus [-containing a Join header which contains-] {+knows this information and fills it when it generates+} the [-dialog identifier Johnston & Levin Expires - April 2003 [Page 18] SIP Call Control - Conferencing for UAs October 2002 A-F. Note-] {+BYE request. An example call flow is shown in Figure 9. It is assumed+} that [-this dialog identifier could be learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY-] {+Alice+} and {+Carol are already participants of+} the [-dialog event package [21]. Bob-] {+conference and that Alice+} is [-added into-] {+authorized to remove members from the conference. Alice sends a REFER to+} the conference [-by-] {+URI with a Refer-To header containing a URI of+} the [-focus.-] {+form <sip:carol@chicago.example.com&method=BYE>.+} Alice Focus Bob Carol | | | | |<==================>| | | | {+REFER sip:Conf-ID Refer-To:Carol?method=BYE F1+} | {+|------------------->|+} | | {+202 Accepted F2+} | [-Bob requests to be added to the conference.-] {+| |<-------------------|+} | | {+NOTIFY (Trying) F3+} | {+|<-------------------|+} | | {+200 OK F4+} | | [-INVITE sip:Focus Join:A-F F1-] {+|------------------->|+} | | [-|<-------------------|-] | | | [-180 Ringing F2-] {+Focus removes Carol from the conference+} | | | [-|------------------->|-] | | | {+BYE sip:Carol F5 | | |---------------------------------------->| | |+} 200 OK [-Contact:Conf-ID;isFocus F3-] {+F6+} | | [-|------------------->|-] {+|<----------------------------------------| | NOTIFY (OK) F7+} | | {+|<-------------------|+} | [-ACK F4-] {+| 200 OK F8 | | |------------------->|+} | | {+NOTIFY F9 |+} | |<-------------------| | | {+200 OK F10 |+} | [-RTP-] {+|------------------->|+} | {+Figure 9. Participant Requests Focus Remove a Participant from the Conference. 4.11 Discovery of Conferencing Capabilities using OPTIONS A UA MAY send an OPTIONS request to discover if an opaque URI is a Johnston & Levin Expires August 8, 2003 [Page 18] Internet-Draft SIP CC Conferencing for UAs February 2003 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 10 where Alice sends an OPTIONS to a URI which resolves to a focus. Alice Focus Bob Carol+} | | [-|<==================>|-] | | | [-SUBSCRIBE-] {+OPTIONS+} sip:Conf-ID [-F5 | | |<-------------------| | | | 200 OK F6 | | | |------------------->| | | | NOTIFY F7 |-] {+F1+} | | |------------------->| | | | 200 OK [-F8 |-] {+Contact:Conf-ID;isfocus F2+} | | |<-------------------| | {+|+} Figure [-7. Adding a member-] {+10. Participant Queries Capabilities of URI which resolves+} to [-an existing conference using Join. 6.9 Bringing a Point-to-Point Dialog into-] a [-Conference A focus-] {+Focus. Following+} is [-capable of bringing-] an [-existing point-to-point dialog with another-] {+example message detail of message F2 in Figure 10. Based on the response, Alice's+} UA [-to a conference-] {+learns+} that the [-focus hosts. The focus would do it by sending re-INVITE changing the Contact-] URI [-to the-] {+is a+} conference URI [-with the ôisFocusö parameter. By doing this, the focus signals to-] {+and that+} the {+responding+} UA {+is focus+} that [-it becomes-] {+supports+} a [-member-] {+number of SIP call control extensions. The response details are as follows: SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: refer, conference Accept: application/sdp, application/conference-info+xml, message/sipfrag Accept-Language: en Supported: replaces Content-Type: application/sdp Content-Length: 274 (SDP not shown) Johnston & Levin Expires August 8, 2003 [Page 19] Internet-Draft SIP CC Conferencing for UAs February 2003 Useful information from each of these headers is detailed in the next sections. Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicate that the user agent supports call control and SIP Events. Accept. The support of bodies such as message/sipfrag [12], application/conference-info+xml [5] also indicates support of call control and conferencing. Allow-Events. The support of event packages such as refer [3], conference [5]. Supported. The support of extensions such as replaces [15]. Contact. The presence+} of the [-conference, specified-] {+"isfocus" feature parameter+} in the Contact [-header. Currently, there-] {+header indicates that the URI+} is [-no way for-] a [-UA, being in an active point-to- point call with-] {+conference URI and that the UA is+} a [-focus, to express by-] {+focus. 5. Security Considerations This document discusses call control for+} SIP {+conferencing. Both+} call control [-means a request to bridge its dialog with a-] {+and conferencing have+} specific [-conference-] {+security requirements which will be summarized here. Conferences generally have authorization rules about who may+} or [-to create-] {+may not join+} a [-new conference and include-] {+conference, what type of media may or may not be used, etc. This information is used by+} the [-dialog-] {+Focus to admit or deny participation+} in [-this-] {+a+} conference. [-Instead,-] {+It is recommended that these types of authorization rules be used to provide security for+} a [-new dialog will need-] {+SIP conference. For this authorization information+} to be [-created. Even if the UA discovers that-] {+used,+} the [-other side has-] focus [-capabilities, the UA-] needs to [-close-] {+be able to authenticate potential participants. Normal SIP mechanisms including Digest authentication and certificates can be used. These conference specific security requirements are discussed further in+} the [-old session-] {+requirements+} and [-to establish-] {+framework documents. For call control security,+} a [-new session/dialog with-] {+user agent must maintain local policy on who is permitted to perform call control operations, initiate REFERs, and replace dialogs. Normal SIP authentication mechanisms are also appropriate here. The specific authentication and authorization schemes are described in+} the [-focus.-] {+multiparty call control framework document. 6. Contributors We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions.+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page [-19]-] {+20] Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs [-October 2002 Editor's Note: Is this an issue? Security Considerations TBD-] {+February 2003 Normative+} References [-1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2-] {+[1]+} Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March [-1997 3 J.-] {+1997. [2]+} Rosenberg, [-H.-] {+J.,+} Schulzrinne, [-G.-] {+H.,+} Camarillo, [-A.-] {+G.,+} Johnston, [-J.-] {+A.,+} Peterson, [-R.-] {+J.,+} Sparks, [-M.-] {+R.,+} Handley, {+M.+} and E. Schooler, "SIP: Session Initiation [-Protocol",-] {+Protocol", RFC 3261, June 2002. [3] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 (work in progress), December 2002. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification",+} RFC [-3261,-] {+3265,+} June 2002. [-4 J.-] {+[5]+} Rosenberg, {+J. and H. Schulzrinne,+} "A [-Framework for Conferencing with the-] Session Initiation [-Protocol,"-] {+Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-00 (work in progress), June 2002. [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 'Join' Header", draft-ietf-sip-join-00 (work in progress),+} October [-2002, Work-] {+2002. [7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", draft-ietf-sip-callerprefs-07 (work+} in [-Progress. 5 O.-] {+progress), November 2002. Informative References [8]+} Levin, [-R. Even, P. Koskelainen, S. Sen,-] {+O.,+} "Requirements for Tightly Coupled SIP [-Conferencing," Internet Engineering Task Force,-] {+Conferencing", draft-levin-sipping-conferencing-requirements-02 (work in progress),+} November [-2002, Work-] {+2002. [9] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing-framework-00 (work+} in [-progress. 6 R.-] {+progress), November 2002. [10]+} Mahy, [-B. Campbell, A. Johnston, D. Petrie, J. Rosenberg, and R. Sparks,-] {+R.,+} "A Multi-party Application Framework for [-SIP," Internet Engineering Task Force, February 2002, Work-] {+SIP", draft-ietf-sipping-cc-framework-01 (work+} in [-progress. 7-] {+progress), July 2002. [11] Campbell,+} B. [-Campbell-] and R. Sparks, "Control of Service Context using SIP [-Request-URI,"-] {+Request-URI",+} RFC 3087, April 2001. [-8 P. Faltstrom and M. Mealing, "The E.164 to URI DDDS Application," Internet Engineering Task Force, June 2002, Work in progress. 9 E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol, Version 2," RFC 2608, June 1999. 10 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Basic Call Flow Examples", Internet Draft, Internet Engineering Task Force, October 2002, Work in Progress. 11 R.-] {+[12]+} Sparks, [-"The Refer Method", Internet Draft, Internet Engineering Task Force, July 2002, Work in Progress.-] {+R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.+} Johnston & Levin Expires [-- April-] {+August 8,+} 2003 [Page [-20]-] {+21] Internet-Draft+} SIP [-Call Control --] {+CC+} Conferencing for UAs {+February 2003 [13] Johnston, A., "Session Initiation Protocol Basic Call Flow Examples", draft-ietf-sipping-basic-call-flows-01 (work in progress),+} October [-2002 12 A. Roach, "SIP-Specific Event Notification," RFC 3265, June-] 2002. [-13 J. Rosenberg-] {+[14] Johnston, A.+} and [-H. Schulzrinne, "A Session-] {+S. Donovan, "Session+} Initiation Protocol [-(SIP) Event Package for Conference State," Internet Engineering Task Force, June 2002, Work in progress. 14 J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application server component architecture for SIP," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. 15 H. Schulzrinne and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities," Internet Engineering Task Force, June 2001, Work-] {+Service Examples", draft-ietf-sipping-service-examples-03 (work+} in [-Progress. 16 R. Mahy , B. Biggs, and R.-] {+progress), November 2002. [15]+} Dean, [-"The SIP Replaces header," Internet Draft, Internet Engineering Task Force, April 2002, Work in Progress. 17 R. Sparks and A. Johnston, "SIP Call Control û Transfer," Internet Engineering Task Force, October 2002, Work in progress. 18 J. Rosenberg-] {+R., Biggs, B.+} and [-H. Schulzrinne, "A-] {+R. Mahy, "The+} Session [-Initiation-] {+Inititation+} Protocol (SIP) [-Event Package for Dialog State," Internet Engineering Task Force, June 2002, Work-] {+'Replaces' Header", draft-ietf-sip-replaces-02 (work+} in [-progress. 19-] {+progress), May 2002. [16] Sparks,+} R. [-Mahy-] and [-D. Petrie, "The Session-] {+A. Johnston, "Session+} Initiation Protocol [-(SIP) 'Join' Header," Internet Engineering Task Force, June 2002, Work-] {+Call Control - Transfer", draft-ietf-sipping-cc-transfer-00 (work+} in [-progress. 20 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Service Examples", Internet Draft, Internet Engineering Task Force,-] {+progress),+} October [-2002, Work in Progress. 21-] {+2002. [17] Rosenberg,+} J. [-Rosenberg-] and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Dialog [-State," Internet Engineering Task Force, June 2002, Work-] {+State", draft-ietf-sipping-dialog-package-00 (work+} in [-progress. Acknowledgments The authors would like to thank all the members of the SIPPING Conferencing design team for their input and discussions. Author's-] {+progress), June 2002. Authors'+} Addresses [-Johnston & Levin Expires - April 2003 [Page 21] SIP Call Control - Conferencing for UAs October 2002-] Alan Johnston WorldCom 100 South 4th Street St. Louis, MO [-63102 USA-] {+63104+} EMail: alan.johnston@wcom.com Orit Levin RADVISION 266 Harristown Road Glen Rock, NJ [-USA Email:-] {+75024 EMail:+} orit@radvision.com [-Phone: +1-201-689-6330-] {+Johnston & Levin Expires August 8, 2003 [Page 22] Internet-Draft SIP CC Conferencing for UAs February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement+} Copyright [-Notice "Copyright-] (C) The Internet Society [-2002.-] {+(2003).+} All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet