view Side-By-Side changes
SIPPING Working Group A. Johnston Internet-Draft MCI Expires:August 15, 2004January 16, 2005 O. Levin MicrosoftFebruary 15,July 18, 2004 Session Initiation Protocol Call Control - Conferencing for User Agentsdraft-ietf-sipping-cc-conferencing-03draft-ietf-sipping-cc-conferencing-04 Status of this Memo This document is an Internet-Draft and isin full conformance withsubject to all provisions ofSection 10section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any ofRFC2026.which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onAugust 15, 2004.January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Thisdocumentspecification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, Johnston & Levin Expires January 16, 2005 [Page 1] Internet-Draft SIP CC Conferencing for UAs July 2004 conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams.Johnston & Levin Expires August 15, 2004 [Page 1] Internet-DraftThe usage of the isfocus feature tag is defined. A SIPCC Conferencingoption tag for conference-aware UAsFebruary 2004is defined. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .34 2. Usage of the 'isfocus' Feature Parameter . . . . . . . . . .34 2.1 General . . . . . . . . . . . . . . . . . . . . . . . . .. 35 2.2 Session Establishment . . . . . . . . . . . . . . . . . .. 45 2.3 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . .. 45 3. SIP User Agent Conferencing Capability Types . . . . . . . .46 3.1 Focus UA . . . . . . . . . . . . . . . . . . . . . . . . .. 56 3.2 Conference Factory URI . . . . . . . . . . . . . . . . . .. 56 3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . .. 57 3.4 Conference-Aware UA . . . . . . . . . . . . . . . . . . .. 67 4. SIP Conferencing Primitives . . . . . . . . . . . . . . . .68 4.1 Joining a Conference using the Conference URI - Dial In .. 68 4.2 Adding a Participant by the Focus - Dial Out . . . . . . .. 1011 4.3 Manually Creating a Conference by Dialing into a Conferencing Application . . . . . . . . . . . . . . . . .. 12 4.4 Creating a Conference by a Conference-Unaware UA . . . . . .144.54.4 Creating a Conference using Ad-Hoc SIP Methods . . . . . .. 16 4.615 4.5 Requesting the Focus Add a New Resource to a Conference ..174.74.6 Adding a 3rd Party Using Conference URI . . . . . . . . . 19 4.7 Requesting Focus Refer a Participant into the Conference .2021 4.8 Adding a 3rd Party Using a Dialog Identifier . . . . . . .. 2123 4.9 Changing User Agents within a Conference . . . . . . . . .. 2325 4.10 Bringing a Point-to-PointDialogSession into a Conference . .. . . 2426 4.11 Requesting the Focus Remove a Participant from a Conference . . . . . . . . . . . . . . . . . . . . . . . 28 4.12 Deleting a conference . . .25 4.12. . . . . . . . . . . . . . 30 4.13 Discovery of Conferencing Capabilities using OPTIONS . . 31 5. Appendix - Creating a Conference by a Conference-Unaware UA . . . . . .27 5. Security Considerations. . . . . . . . . . . . . . . . . .29. . . . . 33 6.ContributorsIANA Considerations . . . . . . . . . . . . . . . . . . . . 35 6.1 SIP Option Tag . . . .29 7. Changes since -02. . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . .29 8. Changes since -01. . . . . . . . . . . . . . . 35 8. Contributors . . . . . .30 9. Changes since -00. . . . . . . . . . . . . . . . . . 35 9. Changes since -03 . . .30 Normative References. . . . . . . . . . . . . . . . . . 36 10. Changes since -02 . .30 Informative References. . . . . . . . . . . . . . . . . . .31 Authors' Addresses36 11. Changes since -01 . . . . . . . . . . . . . . . . . . . . .32 Intellectual Property and Copyright Statements36 12. Changes since -00 . . . . . . .33. . . . . . . . . . . . . . 36 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1 Normative References . . . . . . . . . . . . . . . . . . . 37 13.2 Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page 2] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004 Intellectual Property and Copyright Statements . . . . . . . 39 Johnston & Levin Expires January 16, 2005 [Page 3] Internet-Draft SIP CC Conferencing for UAs July 2004 1. Introduction Thisdocumentspecification uses the concepts and definitions from the high level requirements [10] and the SIP conferencing framework [11] documents. The approach described in this document implements key functions in the conferencing framework using SIP primitives only. This allows for conducting simple conferences with defined functionalities using SIP mechanisms and conventions. Many other advanced functions can be implemented using additional means but they are not in the scope of this document. This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. Possible applications include ad-hoc conferences and scheduled conferences. Note that a single conference can bridge participants having different capabilities and who potentially have joined the conference by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc). The call control and dialog manipulation approach is based on the multiparty framework [12] document. That document defines the basic approach of service design adopted for SIP which includes: - Definition of primitives, not services - Signaling model independent - Invoker oriented - Primitives make full use of URIs - Include authentication, authorization, logging, etc. policies - Define graceful fallback to baseline SIP. The use of opaque URIs and the ability to communicate call control context information within a URI (as opposed to service-related header fields), as discussed in RFC 3087 [13], is fundamental to this approach. Capabilities discovery is an important feature of SIP systems, and conferencing systems can make use of such features. For a UA acting as a focus in a conference, this specification defines the usage of the 'isfocus' feature parameter. For a UA which supports the extensions and scenarios described in this document, the 'conf' option tag is defined. 2. Usage of the 'isfocus' Feature Parameter Johnston & Levin Expires January 16, 2005 [Page 4] Internet-Draft SIP CC Conferencing for UAs July 2004 2.1 General The main design guidelines for the development of SIP extensions and conventions for conferencing are to define the minimum number of extensions and to have seamless backwards compatibility with conference-unaware SIP UAs. The minimal requirement for SIP is being able to express that a dialog is a part of a certain conference referenced to by a URI. As a result of these extensions, it is possible to do the following using SIP:Johnston & Levin Expires August 15, 2004 [Page 3] Internet-Draft SIP CC Conferencing for UAs February 2004- Create a conference - Join a conference - Invite a user to a conference - Expel a user by third party - Discover if a URI is a conference URI - Delete a conference The approach taken is to use the feature parameter "isfocus" to express that a SIP dialog belongs to a conference. The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities [7] document which includes the definition of the "isfocus" feature parameter. 2.2 Session Establishment In session establishment, a focus MUST include the "isfocus" feature parameter in the Contact header field unless the focus wishes to hide the fact that it is a focus. To a participant, the feature parameter will be associated with the remote target URI of the dialog. It is an indication to a conference-aware UA that the resulting dialog belongs to a conference identified by the URI in the Contact header field and that the call control conventions defined in this document can be applied. The Conference URI MUST meet the requirements to be a GRUU (Globally Routable User Agent URI) as detailed in [9] 2.3 OPTIONS Currently the only met requirement is: given an opaque URI, being able to recognize whether it belongs to a certain conference (i.e. meaning that it is a conference URI) or not. As with any other OPTIONS request, it can be done either inside an active dialog or outside a dialog. A focus MUST include the "isfocus" feature parameter in a 200 OK response to an OPTIONS unless the focus wishes to hide the fact that it is a focus. Johnston & Levin Expires January 16, 2005 [Page 5] Internet-Draft SIP CC Conferencing for UAs July 2004 3. SIP User Agent Conferencing Capability Types From a conferencing perspective, the framework document outlines a number of possible different SIP components such as conference-unaware participant, conference-aware participant, and focus. This document applies the concepts above to the SIP call control part of the conferencing components. It defines normative behavior of the SIP UAs in various conferencing situations (referred later as "scenarios").Johnston & Levin Expires August 15, 2004 [Page 4] Internet-Draft SIP CC Conferencing for UAs February 20043.1 Focus UA A focus, as defined in the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A focus contains a conference-aware user agent that supports the conferencing call control conventions as defined in this document. A focus SHOULD support the conference package [5] and indicate so in Allow-Events header fields in requests and responses. A focus MAY include information about the conference in SDP message bodies sent. A focus SHOULD support the Replaces [8] header field. A user agent with focus capabilities could be implemented in end user equipment and would be used for the creation of ad-hoc conferences. A dedicated conferencing server, whose primary task is to simultaneously host conferences of arbitrary type and size, may allocate and publish a conference factory URI (as defined in the next section) for creating an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means. 3.2 Conference Factory URI According to the framework, there are many ways in which a conference can be created. These are open to the conferencing server implementation policy and include non-automated means (such as IVR), SIP, and a conference policy control protocol. In order to automatically create an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means, a globally routable Conference Factory URI can be allocated and published.A successful attempt to establish a call toJohnston & Levin Expires January 16, 2005 [Page 6] Internet-Draft SIP CC Conferencing for UAs July 2004 A successful attempt to establish a call to this URI would result in the automatic creation a new conference and its focus. As a result, note that the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices. A scenario showing the use of the conference factory URI is shown in Section 4.5. 3.3 Conference-Unaware UA The simplest user agent can participate in a conference ignoring all SIP conferencing-related information. The simplest user agent is ableJohnston & Levin Expires August 15, 2004 [Page 5] Internet-Draft SIP CC Conferencing for UAs February 2004to dial into a conference and to be invited to a conference. Any conferencing information is optionally conveyed to/from it using non-SIP means. Such a user agent would not usually host a conference (at least, not using SIP explicitly). A conference-unaware UA needs only to support RFC 3261 [2]. Call flows for conference-unaware UAs are not shown in general in this document as they would be identical to those in the SIP call flows [15] document. 3.4 Conference-Aware UA A conference-aware user agent supports SIP conferencing call control conventions defined in this document as a conference participant, in addition to support of RFC 3261. A conference-aware UA MUST recognize the "isfocus" feature parameter. A conference-aware UA SHOULD support REFER [3], SIP events [4], and the conferencing package [5]. A conference-aware UA SHOULD subscribe to the conference package if the "isfocus" parameter is in the remote target URI of a dialog and if the conference package is listed by a focus in an Allow-Events header field. The SUBSCRIBE to the conference package should be sent outside any INVITE-initiated dialog. A termination of the INVITE dialog with a BYE does not necessarily terminate the SUBSCRIBE dialog. A conference-aware UA MAY render to the user any information about the conference obtained from the SIP header fields and SDP fields from the focus. This specification defines a new SIP option tag, "conf" for use by UAs. A conference-aware UA SHOULD include the "conf" option tag in a Supported header field in requests and responses. A conference-aware UA discovering support for the "conf" option tag MAY make use the scenarios described in this specification. Note that a UA which is only acting as a focus (i.e. is not acting as a combined focus/ Johnston & Levin Expires January 16, 2005 [Page 7] Internet-Draft SIP CC Conferencing for UAs July 2004 participant) in a dialog SHOULD NOT indicates support for this specification using the "conf" option tag. Instead, the "isfocus" feature tag should be used. 4. SIP Conferencing Primitives The SIP conferencing call control flows presented in this section are the call control building blocks for various SIP tight conferencing applications as described in the conferencing requirements [10] and framework [11] documents. The major design goal is that the same SIP conferencing primitives would be used by user agents having different conferencing capabilities and comprising different applications. 4.1 Joining a Conference using the Conference URI - Dial In In this section a user knows the conference URI and "dials in" to join this conference. If the UA is the first participant of the conference to dial in, it is likely that this INVITE will create the focus and hence the conference. However, the conference URI must have been reserved prior to its use. If the conference is up and running already, the dialing-in participant is joined to the conference by its focus.Johnston & Levin Expires August 15, 2004 [Page 6] Internet-Draft SIP CC Conferencing for UAs February 2004To join an existing specific conference a UA SHOULD send an INVITE with the Request-URI set to the conference URI. The focus MUST include the "isfocus" feature parameter in the Contact header field of the 200 OK response to the INVITE.The SUBSCRIBE should be sent outside the INVITE-initiated dialog. Participants leaving the conference send a BYE to the focus. If they have a current subscription to the conference package, they also must send a SUBSCRIBE with an Expires:0 header field to terminate both dialogs.An example call flow for joining a conference is shown in Figure 1. Johnston & Levin Expires January 16, 2005 [Page 8] Internet-Draft SIP CC Conferencing for UAs July 2004 Alice Focus Bob Carol | | | | | Carol joins the conference | | | | | | INVITE sip:Conf-ID F1 | | |<----------------------------------------| | | 180 Ringing F2 | | |---------------------------------------->| | | 200 OK Contact:Conf-ID;isfocus F3 | | |---------------------------------------->| | | ACK F4 | | |<----------------------------------------| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Conf-ID F5 | | |<----------------------------------------| | | 200 OK F6 | | |---------------------------------------->| | | NOTIFY F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| Figure 1. A Participant Joins a Conference using the Conference URI. F1 INVITE sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 45 INVITEJohnston & Levin Expires August 15, 2004 [Page 7] Internet-Draft SIP CC Conferencing for UAs February 2004Contact: <sip:carol@client.chicago.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: conf, replaces Content-Type: application/sdp Content-Length: 274 (SDP not shown) F3 SIP/2.0 200 OK Johnston & Levin Expires January 16, 2005 [Page 9] Internet-Draft SIP CC Conferencing for UAs July 2004 Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 To: <sip:3402934234@example.com>;tag=733413 From: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 45 INVITE Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog, conference Accept: application/sdp, application/conference-info+xml, message/sipfrag Supported: replaces, join, gruu Content-Type: application/sdp Content-Length: 274 v=0 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com s=Example Subject i=Example Conference Hosted by Example.com u=http://conf.example.com/3402934234 e=3402934234@conf-help.example.com p=+1-888-2934234 c=IN IP4 ms5.conf.example.com t=0 0 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 F5 SUBSCRIBE sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKdf334 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Carol <sip:carol@chicago.example.com>;tag=43524545Johnston & Levin Expires August 15, 2004 [Page 8] Internet-Draft SIP CC Conferencing for UAs February 2004Call-ID: k3l43id034ksereree CSeq: 22 SUBSCRIBE Contact: <sip:carol@chicago.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Supported: conf, replaces Content-Length: 0 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 Johnston & Levin Expires January 16, 2005 [Page 10] Internet-Draft SIP CC Conferencing for UAs July 2004 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 Max-Forwards: 70 To: Carol <sip:carol@chicago.example.com>;tag=43524545 From: <sip:3402934234@example.com>;tag=a3343df32 Call-ID: k3l43id034ksereree CSeq: 34321 NOTIFY Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Supported: replaces, join, gruu Content-Type: application/conference-info+xml Content-Length: ... <conference-info version="0" state="full" entity="sip:3402934234@example.com"> <user uri="sip:carol@chicago.example.com" display-name="Carol"> <status>connected</status> <joining-mode>dialed-in</joining-mode> <media-stream media-type="audio"> <proto>RTP/AVP</proto> <ssrc>583398</ssrc> </media-stream> <media-stream media-type="video"> <proto>RTP/AVP</proto> <ssrc>345212</ssrc> </media-stream> </user> <conf-uri>tel:+18882934234</conf-uri> </conference-info>Johnston & Levin Expires August 15, 2004 [Page 9] Internet-Draft SIP CC Conferencing for UAs February 20044.2 Adding a Participant by the Focus - Dial Out To directly add a participant to a conference, a focus SHOULD send an INVITE to the participant containing a Contact header field with the conference URI and the "isfocus" feature parameter. Note that a conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point to point session. An example call flow is shown in Figure 2. It is assumed that Alice is already a participant of the conference. The focus invites Carol Johnston & Levin Expires January 16, 2005 [Page 11] Internet-Draft SIP CC Conferencing for UAs July 2004 to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F5) and the NOTIFY to Alice (F9) - they occur asynchronously and independently. Alice Focus Bob Carol | | | | |<==================>| | | | | | | Focus "dials out" to add Carol to the conference | | | | | | INVITE Contact:Conf-ID;isfocus F1 | | |---------------------------------------->| | | 180 Ringing F2 | | |<----------------------------------------| | | 200 OK F3 | | |<----------------------------------------| | | ACK F4 | | |---------------------------------------->| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Conf-ID F5 | | |<----------------------------------------| | | 200 OK F6 | | |---------------------------------------->| | | NOTIFY F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| | NOTIFY F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | Figure 2. A Focus "dials out" to Add a Participant to the Conference.Johnston & Levin Expires August 15, 2004 [Page 10] Internet-Draft SIP CC Conferencing for UAs February 2004F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 Max-Forwards: 70 To: Carol <sip:carol@chicago.example.com>;tag=43524545 From: <sip:3402934234@example.com>;tag=a3343df32 Call-ID: k3l43id034ksereree CSeq: 34321 NOTIFY Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Johnston & Levin Expires January 16, 2005 [Page 12] Internet-Draft SIP CC Conferencing for UAs July 2004 Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ... <conference-info version="0" state="full" entity="sip:3402934234@example.com"> <user uri="sip:alice@atlanta.example.com" display-name="Alice"> <status>connected</status> <joining-mode>dialed-in</joining-mode> <media-stream media-type="audio"> <proto>RTP/AVP</proto> <ssrc>674231</ssrc> </media-stream> <media-stream media-type="video"> <proto>RTP/AVP</proto> <ssrc>213563</ssrc> </media-stream> </user> <user uri="sip:carol@chicago.example.com" display-name="Carol"> <status>connected</status> <joining-mode>dialed-out</joining-mode> <media-stream media-type="audio"> <proto>RTP/AVP</proto> <ssrc>583398</ssrc> </media-stream> <media-stream media-type="video"> <proto>RTP/AVP</proto> <ssrc>345212</ssrc> </media-stream> </user> <conf-uri>tel:+18882934234</conf-uri> </conference-info>Johnston & Levin Expires August 15, 2004 [Page 11] Internet-Draft SIP CC Conferencing for UAs February 2004F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 Max-Forwards: 70 To: Alice <sip:alice@atlanta.example.com>;tag=43524545 From: <sip:3402934234@example.com>;tag=a3343df32 Call-ID: 8820450524545 CSeq: 998 NOTIFY Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, Johnston & Levin Expires January 16, 2005 [Page 13] Internet-Draft SIP CC Conferencing for UAs July 2004 SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=2450 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ... <conference-info version="0" state="partial" entity="sip:3402934234@example.com"> <user uri="sip:carol@chicago.example.com" display-name="Carol"> <status>connected</status> <joining-mode>dialed-out</joining-mode> <media-stream media-type="audio"> <proto>RTP/AVP</proto> <ssrc>583398</ssrc> </media-stream> <media-stream media-type="video"> <proto>RTP/AVP</proto> <ssrc>345212</ssrc> </media-stream> </user> <conf-uri>tel:+18882934234</conf-uri> </conference-info> 4.3 Manually Creating a Conference by Dialing into a Conferencing Application In this section, a user sends an INVITE to a conference server application. The application (such as an IVR system or a web page) is implemented because the system requires additional input from the user before it is able to create a conference. After a normal dialog is established, additional information is received and the conference together with its focus are created. At this point the conference server MUST re-INVITE the user with the conference URI in ContactJohnston & Levin Expires August 15, 2004 [Page 12] Internet-Draft SIP CC Conferencing for UAs February 2004with the "isfocus" feature parameter. Alternatively, the additional information MAY be provided by the user during an early dialog established. This could be accomplished by a 183 Session Progress response sent by the conferencing application. After the conference is created, the conference URI MUST then be returned in a Contact in the 200 OK. An example call flow is shown in Figure 3. In this example, Alice Johnston & Levin Expires January 16, 2005 [Page 14] Internet-Draft SIP CC Conferencing for UAs July 2004 uses a conference application which is triggered when Alice sends an INVITE to the conference application. In this example, Conf-App is used to represent the conference application URI. Alice's conference-aware UA learns of the existence of the conference from the "isfocus" feature parameter and subscribes to the conference package to receive notifications of the conference state.Johnston & Levin Expires August 15, 2004 [Page 13] Internet-Draft SIP CC Conferencing for UAs February 2004Alice Focus Bob Carol | | | | | Alice establishes session with conference application. | | | | | | INVITE sip:Conf-App F1 | | |------------------->| | | | 180 Ringing F2 | | | |<-------------------| | | | 200 OK F3 | | | |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | | | | | | Alice uses the application to create the conference. | | | | | | INVITE Contact:Conf-ID;isfocus F5 | | |<-------------------| | | | 200 OK F6 | | | |------------------->| | | | ACK F7 | | | |<-------------------| | | | RTP | | | |<==================>| | | | | | | | SUBSCRIBE sip:Conf-ID F8 | | |------------------->| | | | 200 OK F9 | | | |<-------------------| | | | NOTIFY F10 | | | |<-------------------| | | | 200 OK F11 | | | |------------------->| | | Figure 3. A Participant Creates a Conference using an Application. 4.4 Creating a Conferenceby a Conference-Unaware UA It is a requirement that a user (human) be able to use a conference-unaware UA to create and add participants to a conference. A user (human) would choose a conference URI according to system rules and insert it into the Request-URI of the INVITE.using Ad-Hoc SIP Methods Thissame URI is echoed bysection addresses creating afocus adhering to certain addressing conventions (discussed below) in the Contact header by the focus. Additional participants could be addedconference bynon-SIP means (publication of theusing ad-hoc SIP Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page14]15] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004chosenmeans. The conference factory URIusing 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(as defined in Section 2.4) is used to automatically create the conferenceURI. Note thatin thisscenario only the user (human) is awareexample. The benefit ofthe conferencing application, and the conference-unaware UA only need support RFC 3261 and optionally call transfer. Makingthiswork does impose certain addressing conventions on a system. As a service/implementation choice, a system could allow the creator ofapproach is that the conference URI need not be known tochoosethe userportion of the conference URI. However, this requires the URI format to be agreed upon between- instead it is created by auserfocus and used by thesystem. For example, a service provider might reserveparticipants' UAs. The main difference between this scenario and Section 4.3 is that no user intervention (IVR, web page form, etc.) is required to create thedomain conf.example.com for all conference URIs. Anyconference. The SIP URIin the domainofconf.example.com would resolve tothefocus. The focus couldconference factory can beconfigured to interpret an unknown user partprovisioned in theconf.example.com domainUA (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 requestforto create a new ad-hoc conference from a request tobe created with thejoin an existing conferenceURI asby the Request-URI.For example, an INVITE sent with a Request-URI of sip:k32934208ds72@conf.example.com could be routed to the focusAssuming thatwould then create the conference. Thisall security and policy requirements have been met, a new conferenceURI shouldwill beregistered by the newlycreatedfocus to become routable as a conference URI withinwith theconf.example.com domain. The returnedContactwould look as follows: Contact: <sip:k32934208ds72@conf.example.com>;isfocus Note, however, that this approach relies on conventions adopted between the user (human) and the focus. Also, the approach is not robust against collisionsURI returned in theconference 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 into200 OK being theexisting conference instead of creating a new one. As a result, methods ofconferencecreation in whichURI. The Contact header field MUST contain theconference"isfocus" feature parameter to indicate that this URI isan opaque URI generated by the focus are preferred.for a conference. An example call flow is shown in Figure 4.The participant Alice createsNote that Conf-Factory is shorthand for the conference factory URI(using some convention agreed to withand Conf-ID Is short for thefocus domain)conference URI. In this flow, Alice has a conference-aware UA andsendscreates a conference by sending an INVITE tothat URI which createsthefocus.conference factory URI. Thefocusconference factory application creates the conference andreturnsredirects using a 302 Moved Temporarily response to thesame conference URI infocus. Note that with proxy recursion, Alice may never see the200 OK answer toredirect but may just receive theINVITE (which is ignored byresponses from theconference-unaware UA). Johnston & Levinfocus 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 ExpiresAugust 15, 2004January 16, 2005 [Page15]16] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004 Alice Conf-Factory App Focus BobCarol| | | | | Alice creates theconference and chooses the conference URI.conference. | | | | | | | INVITEsip:Conf-IDsip:Conf-Factory F1 | | |------------------->| | | |180 Ringing302 Moved Contact:Conf-ID;isfocus F2 | |||<-------------------| | | |200 OK Contact:Conf-ID;isfocusACK F3 | ||<-------------------|| |------------------->| | |ACK| 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.A Conferencing Unaware Participant Creates a Conference 4.5 CreatingCreation of a Conference usingAd-HocSIPMethods This section addresses creatingAd-Hoc Methods. 4.5 Requesting the Focus Add aconference by using ad-hocNew Resource to a Conference A SIPmeans. TheconferencefactoryURI(as defined in Section 2.4) iscan be used toautomatically createinject different kinds of information into the conference. Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs). To request the focus add a new information resource to the specified conference, any SIP UA can send a REFER to the conferencein this example. The benefitURI with a Refer-To containing the URI of the new resource. Since thisapproachREFER isthatsent to the conference URIneedand notbe knownthe conference factory URI, the semantics to theuser - instead it is created by afocusand used byare to bring theparticipants' UAs. The main difference between this scenarioresource into the conference andSection 4.3 is that no user intervention (IVR, web page form, etc.) is requiredmake it visible tocreatetheconference.conference participants. The resultant Johnston & Levin Expires January 16, 2005 [Page 17] Internet-Draft SIPURI ofCC Conferencing for UAs July 2004 focus procedures are dependant both on theconference factory can be provisioned innature of theUAnew resource (asinexpressed by its URI) and the own focus policies regarding IM, central vs. distributed real time media processing, etc. The scenario for adding a"createnewconference" 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 requestUA participant is important tocreate asupport because it works even if the newad-hoc conference from a requestparticipant does not support REFER and transfer call control - only the requesting participant and the focus need tojoin an existing conference bysupport theRequest-URI. Assuming that all securityREFER andpolicy requirements have been met,transfer call control. Upon receipt of the REFER containing anew conference will be createdRefer-To header with a SIP URI, theContact URI returned infocus SHOULD send an INVITE to the200 OK beingnew participant identified by theconference URI. TheRefer-To SIP URI containing a Contact header fieldMUST containwith the conference URI and the "isfocus" featureparameter to indicate that this URI is for a conference.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.NoteIt is assumed thatConf-FactoryAlice isshorthand for the conference factory URI and Conf-ID Is short foralready a participant of theconference URI. In this flow,conference. Alicehas a conference-aware UA and createssends aconference by sending an INVITEREFER to the conferencefactory Johnston & Levin Expires August 15, 2004 [Page 16] Internet-Draft SIP CC Conferencing for UAs February 2004URI. Theconference factory application creates the conference and redirects using a 302 Moved Temporarily responsefocus invites Carol to thefocus. Note that with proxy recursion, Alice may never see the redirect but may just receive the responses from the focus starting with message F5. Onceconference by sending an INVITE. After themediasession is established,AliceCarol subscribes to the conferenceURI obtained through the Contact in the 200 OK response fromURI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F11) and thefocus.NOTIFY to Alice (F15) - they occur asynchronously and independently. AliceConf-Factory AppFocus Bob Carol | | | | |<==================>| |Alice creates the conference.| | REFER sip:Conf-ID Refer-To:Carol F1 | | |------------------->| | | 202 Accepted F2 |INVITE sip:Conf-Factory F1| |<-------------------| ||------------------->|| NOTIFY (Trying) F3 | |<-------------------| |302 Moved Contact:Conf-ID;isfocus F2| 200 OK F4 ||<-------------------|| |------------------->| | |ACK F3| | ||------------------->|Focus "dials out" to join Carol to the conference | | | | | | INVITEsip:Conf-ID F4Contact:Conf-ID;isfocus F5 | | |---------------------------------------->| | | 180 RingingF5F6 | | |<----------------------------------------| | | 200 OKContact:Conf-ID;isfocus F6F7 | | |<----------------------------------------| | | ACKF7F8 | | |---------------------------------------->| Johnston & Levin Expires January 16, 2005 [Page 18] Internet-Draft SIP CC Conferencing for UAs July 2004 | | RTP | | |<=======================================>| | NOTIFY (OK) F9 | | |<-------------------| | |Alice subscribes to the conference URI. |200 OK F10 | | |------------------->| | | | SUBSCRIBE sip:Conf-IDF8F11 | ||---------------------------------------->||<----------------------------------------| | | 200 OKF9F12 | ||<----------------------------------------||---------------------------------------->| | | NOTIFYF10F13 | | |---------------------------------------->| | | 200 OK F14 | | |<----------------------------------------| | NOTIFY F15 | | |<-------------------| | | 200 OKF11F16 | ||---------------------------------------->||------------------->| | Figure 5.Creation of a Conference using SIP Ad-Hoc Methods. 4.6 Requesting theParticipant Requests FocusAddadd aNew ResourceParticipant to the Conference. F1 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Alice <sip:alice@atlanta.example.com>;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: <sip:alice@alice.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: <sip:carol@chicago.example.com> Supported: conf, replaces Content-Length: 0 4.6 Adding a 3rd Party Using Conference URI ASIPparticipant wishing to add a new participant will request this participant to send an INVITE to the conferenceURIURI. This can beused to inject different kinds of information intodone using a non-SIP means (such as passing or publishing theconference. Examples include new participants, new real-time media sources, new IM messages,conference URI in an email, IM, or web page). If a non-SIP means is used, then the flow andpointersrequirements are identical topassiveSection 4.1. The SIP mechanism to do this utilizes the REFER method. Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page17]19] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004information references (such as HTTP URIs). To request the focusA UA wishing to add a newinformation resource to the specified conference, any SIP UA canparticipant SHOULD send a REFER request to theconference URIparticipant with a Refer-To header containing theURI of the new resource. Since this REFER is sent to the conference URI and not theconferencefactory URI, the semantics to the focusURI. The requirements are then identical tobring the resource intotheconference and make it visible to the conference participants. The resultant focus procedures are dependant both on the nature"dial in" case ofthe new resource (as expressed by its URI) and the own focus policies regarding IM, central vs. distributed real time media processing, etc.Section 4.1. Thescenario 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 requestinginviting participantand the focus need to support the REFER and transfer call control. Upon receipt ofMAY receive notification through the REFERcontaining a Refer-To header with a SIP URI, the focus SHOULD send an INVITE toaction that the new participantidentified byhas been added in addition to theRefer-To SIP URI containing a Contact header field withnotification received through the conferenceURI 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.package. An examplecall flowis shown in Figure6. It7. 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 REFERto the conference URI. The focus invites Carol tooutside of an established dialog. Should Bob reject theconference byREFER, Alice might try sending anINVITE. After the session is established, Carol subscribesINVITE tothe conference URI. It is importantBob tonote that there is no dependency on Carol's SUBSCRIBE (F11) andestablish a session first, then send a REFER within theNOTIFY to Alice (F15) - they occur asynchronously and independently. Alice Focusdialog, effectively transferring Bob into the conference [17]. Alice Focus Bob Carol | | | | |<==================>| | | | | | | | Alice adds Bob into conference | | | | | | | REFERsip:Conf-ID Refer-To:CarolRefer-To:Conf-ID F1 | ||------------------->||---------------------------------------->| | | 202 Accepted F2 | ||<-------------------|| |<----------------------------------------| | | NOTIFY (Trying)F3F3| ||<-------------------|| |<----------------------------------------| | | 200 OK F4 | ||------------------->| | | | | | Focus "dials out" to join Carol to the conference | || |---------------------------------------->| |Johnston & Levin Expires August 15, 2004 [Page 18] Internet-Draft SIP CC Conferencing for UAs February 2004| | INVITEContact:Conf-ID;isfocussip:Conf-ID F5 | ||---------------------------------------->||<-------------------| | | | 180 Ringing F6 | ||<----------------------------------------|| |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F7 | ||<----------------------------------------||------------------->| | | | ACK F8 | ||---------------------------------------->|| |<-------------------| | | | RTP | ||<=======================================>|| |<==================>| | | NOTIFY (OK) F9 | ||<-------------------|| |<----------------------------------------| | | 200 OK F10 | ||------------------->|| |---------------------------------------->| | |SUBSCRIBE sip:Conf-IDNOTIFY F11 | ||<----------------------------------------|| |<-------------------| | | | 200 OK F12 | ||---------------------------------------->|| |------------------->| | |NOTIFYJohnston & Levin Expires January 16, 2005 [Page 20] Internet-Draft SIP CC Conferencing for UAs July 2004 | | SUBSCRIBE sip:Conf-ID F13 | ||---------------------------------------->||<-------------------| | | | 200 OK F14 | ||<----------------------------------------|| |------------------->| | | | NOTIFY F15 | ||<-------------------|| |------------------->| | | | 200 OK F16 | ||------------------->|| |<-------------------| | Figure 6.Participant Requests Focus addAdding a Participant tothean Existing Conference.F1 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Alice <sip:alice@atlanta.example.com>;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: <sip:alice@alice.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: <sip:carol@chicago.example.com> Supported: replaces Content-Length: 0 Johnston & Levin Expires August 15, 2004 [Page 19] Internet-Draft SIP CC Conferencing for UAs February 20044.7AddingRequesting Focus Refer a3rd Party UsingParticipant into the ConferenceURIA participantwishing to addmay request the focus refer anewparticipant into the conference by sending a REFER method. The Refer-To header field willrequest this participanthave the method set tosendREFER and anINVITE toescaped Refer-To header field containing the conference URI.This can be done using a non-SIP means (such as passing or publishing the conference URINote that inan email, IM, or web page). If a non-SIP means is used, then the flow and requirements are identical to Section 4.1. The SIP mechanism to do this utilizes the REFER method. A UA wishing to add a new participant SHOULD send a REFER request toMessage F1 below, theparticipant with aRefer-To headercontaining the conference URI. The requirements are then identical tofield is shown as continuing across two lines - this would not be the"dial in"caseof Section 4.1. The inviting participant MAY receive notification through the REFER action that the new participant has been addedinaddition toan actual message, thenotification received throughURI would have continued beyond theconference package. An exampleformatting limitations of this document. This scenario is shown in Figure 7.In this call flow, it is assumed that Alice is already a participant of the conference. Alice sends Bob an "out of band" REFER - that is, a REFER outside of an established dialog. Should Bob reject the REFER, Alice might try sending an INVITE to Bob to establish a session first, then send a REFER within the dialog, effectively transferring Bob into the conference [17].Alice Focus Bob Carol | | | | |<==================>| | | | | | | | Aliceaddsasks focus to REFER Bob into conference | | | | | ||REFERRefer-To:Conf-IDsip:Conf-ID Refer-To:Bob?method=REFER&Refer-To=Conf-ID F1 |------------------->| | ||---------------------------------------->| || 202 Accepted F2 | | ||<----------------------------------------||<-------------------| | | | NOTIFY (Trying) F3| | ||<----------------------------------------||<-------------------| | | | 200 OK F4 | | ||---------------------------------------->||------------------->| | | |INVITE sip:Conf-ID F5| ||<-------------------|| | Focus REFERs Bob to the conference |180 Ringing F6| | ||------------------->|| | |200 OK Contact:Conf-ID;isfocus F7REFER Refer-To:Conf-ID F5 | | |------------------->| | | |ACK F8202 Accepted F6 | | | NOTIFY (202) F7 |<-------------------| | |<-------------------| NOTIFY (Trying) F8 | | Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page20]21] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004 | 200 OK F9 |<-------------------| |RTP|------------------->| 200 OK F10 | | ||<==================>||------------------->| | |NOTIFY (OK) F9| INVITE sip:Conf-ID F11 | | |<-------------------| | | | 180 Ringing F12 | | | |------------------->| ||<----------------------------------------|| | 200 OKF10Contact:Conf-ID;isfocus F13 | | |------------------->| | ||---------------------------------------->|| ACK F14 | | | NOTIFYF11F15 |<-------------------| | |<-------------------| RTP | | | 200 OK F16 |<==================>| | |------------------->| NOTIFY (200) F17 | | | |<-------------------| | | | 200 OKF12F18 | | | |------------------->| | | ||SUBSCRIBE sip:Conf-IDF13F17 | | |<-------------------| | | | 200 OKF14F19 | | | |------------------->| | | | NOTIFYF15F20 | | | |------------------->| | | | 200 OKF16F21 | | | |<-------------------| | Figure 7.AddingRequesting a Focus Refer a Participant toan Existinga Conference. F1 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Alice <sip:alice@atlanta.example.com>;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: <sip:alice@alice.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: <sip:bob@biloxi.example.com?method=REFER &Refer-To=sip:3402934234%40example.com> Supported: conf, replaces Content-Length: 0 F5 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243 Johnston & Levin Expires January 16, 2005 [Page 22] Internet-Draft SIP CC Conferencing for UAs July 2004 Max-Forwards: 70 To: <sip:bob@biloxi.example.com> From: <sip:3402934234@example.com>;tag=345621412 Call-ID: 5494204 CSeq: 4524323 REFER Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: <sip:3402934234@example.com> Supported: join, gruu, replaces Content-Length: 0 F11 INVITE sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Bob <sip:bob@biloxi.example.com>;tag=32411 Call-ID: 5d4324fa84b4c76e66710 CSeq: 764 INVITE Contact: <sip:bob@client.biloxi.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: conf, replaces, join Content-Type: application/sdp Content-Length: 274 (SDP not shown) 4.8 Adding a 3rd Party Using a Dialog Identifier Under some circumstances, a participant wanting to join a conference may only know a dialog identifier of one of the legs of the conference. The information may have been learned using the dialog package [18] or some non-SIP means to retrieve this information from a conference participant. A UA can request to be added to a conference by sending a request to the focus containing a Join [6] header field containing a dialog ID of one leg of the conference (a dialog between a participant and the focus). There are other scenarios in which a UA can use the Join header for Johnston & Levin Expires January 16, 2005 [Page 23] Internet-Draft SIP CC Conferencing for UAs July 2004 certain conferencing call control scenarios. See [6] for further examples and details. An example is shown in Figure 8. It is assumed that Alice is a participant of the conference. The dialog identifier between Alice and the focus is abbreviated as A-F and is known by Bob. Bob requests to be added to the conference by sending an INVITE message F1 to the focus containing a Join header which contains the dialog identifier A-F. Bob is added into the conference by the focus.Johnston & Levin Expires August 15, 2004 [Page 21] Internet-Draft SIP CC Conferencing for UAs February 2004Alice 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-IDF5F6 | | 200 OK F7 |<-------------------| || ||------------------->| 200 OKF6F8 | | | |------------------->| | | | NOTIFYF7F9 | | | |------------------->| | | | 200 OKF8F10 | | | |<-------------------| | Figure 8. Adding a Participant to an Existing Conference using Join. Johnston & Levin Expires January 16, 2005 [Page 24] Internet-Draft SIP CC Conferencing for UAs July 2004 F1 INVITE sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Bob <sip:bob@biloxi.example.com>;tag=32411 Call-ID: d432fa84b4c76e66710 CSeq: 8 INVITE Contact: <sip:bob@client.biloxi.example.com> Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: conf, replaces, join Content-Type: application/sdp Content-Length: 274 (SDP not shown)Johnston & Levin Expires August 15, 2004 [Page 22] Internet-Draft SIP CC Conferencing for UAs February 20044.9 Changing User Agents within a Conference A participant in a conference may want to change the user agent with which they participate in the conference. While this could be done by simply sending a BYE from one user agent to leave the conference and an INVITE from the other user agent to rejoin. However, the SIP Replaces [6] primitive is perfectly suited to this operation. An example is shown in Figure 9. It is assumed that Alice is a participant of the conference using user agent #1. The dialog identifier between Alice's user agent #1 and the focus is abbreviated as A-F. Alice switches to user agent #2 and sends an INVITE message F1 to the focus containing a Replaces header which contains the dialog identifier A-F. Note that this dialog identifier could be learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the dialog event package [18]. Alice's user agent #2 is added into the conference by the focus. The focus sends a BYE to user agent #1. User agent #1 then automatically terminates the subscription by sending a SUBSCRIBE with Expires:0 to terminate the subscription. Note that as the participant list (roster) has not changed during this scenario, no NOTIFYs are sent by the focus to subscribers to the participant list. Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page23]25] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004 Alice UA#1 Focus Alice UA#2 Carol | | | | |<==================>| | | | | | | | Alice switches user agents during the conference. | | | | | | | INVITE sip:Conf-ID Replaces:A-F F1 | | |<-------------------| | | | 200 OK Contact:Conf-ID;isfocus F2 | | |------------------->| | | | ACK F3 | | | |<-------------------| | | | RTP | | | |<==================>| | | BYE F4 | | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | SUBSCRIBE Expires:0 F6 | | |------------------->| | | | 200 OK F7 | | | |<-------------------| | | | NOTIFY Subscription-State:terminated F8 | | |<-------------------| | | | 200 OK F9 | | | |------------------->| | | | | SUBSCRIBE sip:Conf-ID F10 | | |<-------------------| | | | 200 OK F11 | | | |------------------->| | | | NOTIFY F12 | | | |------------------->| | | | 200 OK F13 | | | |<-------------------| | Figure 9. Adding a Participant to an Existing Conference using Join. 4.10 Bringing a Point-to-PointDialogSession into a ConferenceA focus is capable of bringingThis call flow shows how a point to point call can be switched to a conference call involving anexisting point-to-point dialogexternal focus. Alice and Bob have an established session withanother UA toa dialog identifier A-B. Alice joins the conferencethatwith the focushosts. The focus would do itby sendingre-INVITE changing the Contact URIan INVITE to theconference URI with the "isfocus" feature parameter. By doing this,Conference URI. Alice then sends a REFER to the focussignals toand includes an escaped Replaces header field in theUA that it becomes a participant ofRefer-To header field. Bob receives theconference, specified inINVITE from theContact header. Currently, there is no way for a UA, beingfocus, matches the dialog inan activeJohnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page24]26] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004point-to-point callthe Replaces header field witha focus, to express by SIP call control means a request to bridge itsthe dialog with Alice. As aspecific conference or to create a new conference and includeresult, Bob accepts thedialog in this conference. Instead,INVITE, joins the conference, and sends anew dialog will needBYE tobe created. Even if the UA discovers that the other side has focus capabilities, the UA needsAlice toclose the old session andtear down their point toestablish a new session/dialog with the focus. 4.11 Requesting thepoint dialog. Alice FocusRemove a Participant from a Conference To request the focus remove a participant from the specified conference,Bob Carol | | | | | Alice is in aproperly authorized SIP UA (typicallysession with Bob | | |<=======================================>| | | | | | | Alice joins the conferenceowner) 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 10. It is assumed that Alice and Carol are already participants of the conference and that| | | | | | | INVITE sip:Conf-ID F1 | | |------------------->| | | | 200 OK Contact:sip:Conf-ID F2 | | |<-------------------| | | | ACK F3 | | | |------------------->| | | |<==================>| | | | | | | | Aliceis authorizedasks focus toremove members from the conference. Alice sends aREFERto the conference URI with a Refer-To header containing a URI of the form <sip:carol@chicago.example.com&method=BYE>. Johnston & Levin Expires August 15, 2004 [Page 25] Internet-Draft SIP CC Conferencing for UAs February 2004 Alice FocusBobCarolinto conference | | | ||<==================>|| | REFER sip:Conf-IDRefer-To:Carol?method=BYE F1Refer-To:Bob?Replaces=A-B F4 | |------------------->| | | | 202 AcceptedF2F5 | | | |<-------------------| | | | NOTIFY (Trying)F3F6| | | |<-------------------| | | | 200 OKF4F7 | | | |------------------->| | | | | | | | Focusremoves Carol frominvites Bob to the conference | | | | | |BYE sip:Carol F5| INVITE sip:Conf-ID Replaces:A-B F8 | ||---------------------------------------->||------------------->| | | | 200 OKF6F9 | ||<----------------------------------------|| |<-------------------| |NOTIFY Subscription-State:terminated F7| ||---------------------------------------->|ACK F10 | |200 OK F8| |------------------->| | ||<----------------------------------------||NOTIFY (OK) F9RTP | ||<-------------------|| |<==================>| | | BYE F11 | | |<----------------------------------------| | | 200 OKF10F12 | ||------------------->||---------------------------------------->| | | NOTIFYF11(200) F13 | | | |<-------------------| | | | 200 OKF12F14 | | | |------------------->| |Figure 10. Participant Requests Focus Remove a Participant from the Conference.| Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page26]27] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004F1 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Alice <sip:alice@atlanta.example.com>;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: <sip:alice@alice.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,| NOTIFYAccept: application/sdp, message/sipfrag Refer-To: <sip:carol@chicago.example.com;method=BYE> Supported: replaces Content-Length: 0 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 Max-Forwards: 70 From: <sip:3402934234@example.com>;tag=5393k2312 To: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 78654 BYE Content-Length: 0 4.12 Discovery of Conferencing Capabilities using OPTIONS A UA MAY send an OPTIONS request to discover if an opaque URI is a conference URI (resolves to a focus). In addition, the reply to the OPTIONS request can also indicate support for various SIP call control extensions used in this document. Note that the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus or aF15 | | | |<-------------------| | | | 200 OKanswer from the focus to an INVITE as a part of a normal dialog establishment process. An example is shown in Figure 11 where Alice sends an OPTIONS to a URI which resolves to a focus. Alice Focus Bob CarolF16 | | | |------------------->| | |OPTIONS| | SUBSCRIBE sip:Conf-IDF1F17 | | |<-------------------| | | | 200 OK F18 | | | |------------------->| | | | NOTIFY F19 | | | |------------------->| | | | 200 OKContact:Conf-ID;isfocus F2F20 | | | |<-------------------| | |Johnston & Levin Expires August 15, 2004 [Page 27] Internet-Draft SIP CC Conferencing for UAs February 2004| | | Figure11. Participant Queries Capabilities of URI which resolves10. Transitioning a Point to Point Session into aFocus. Following is an example message detail of message F2 in Figure 11. Based on theConference. 4.11 Requesting the Focus Remove a Participant from a Conference To request the focus remove a participant from the specified conference, a properly authorized SIP UA (typically the conference owner) can send a REFER to the conference URI with a Refer-To containing the URI of the participant and with the method set to BYE. The requestor does not need to know the dialog information about the dialog between the focus and the participant who will be removed - the focus knows this information and fills it when it generates the BYE request. An example call flow is shown in Figure 11. It is assumed that Alice and Carol are already participants of the conference and that Alice is authorized to remove members from the conference. Alice sends a REFER to the conference URI with a Refer-To header containing a URI of the form <sip:carol@chicago.example.com?method=BYE>. Johnston & Levin Expires January 16, 2005 [Page 28] Internet-Draft SIP CC Conferencing for UAs July 2004 Alice Focus Bob Carol | | | | |<==================>| | | REFER sip:Conf-ID Refer-To:Carol?method=BYE F1 | |------------------->| | | 202 Accepted F2 | | |<-------------------| | | NOTIFY (Trying) F3 | |<-------------------| | | 200 OK F4 | | |------------------->| | | | | | Focus removes Carol from the conference | | | | | | BYE sip:Carol F5 | | |---------------------------------------->| | | 200 OK F6 | | |<----------------------------------------| | | NOTIFY Subscription-State:terminated F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| | NOTIFY (200) F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | | NOTIFY F11 | | |<-------------------| | | 200 OK F12 | | |------------------->| | Figure 11. Participant Requests Focus Remove a Participant from the Conference. Johnston & Levin Expires January 16, 2005 [Page 29] Internet-Draft SIP CC Conferencing for UAs July 2004 F1 REFER sip:3402934234@example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 Max-Forwards: 70 To: <sip:3402934234@example.com> From: Alice <sip:alice@atlanta.example.com>;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: <sip:alice@alice.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: <sip:carol@chicago.example.com?method=BYE> Supported: conf, replaces Content-Length: 0 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 Max-Forwards: 70 From: <sip:3402934234@example.com>;tag=5393k2312 To: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 78654 BYE Content-Length: 0 4.12 Deleting a conference A conference created using the Conference Factory URI is automatically deleted when the creator of the conference leaves the conference by sending a BYE. If the focus allows the conference policy to be manipulated, it is possible for the conference to continue after the creator departs if the policy is changed. However, the default conference policy for conferences created using the Conference Factory URI is that the conference is deleted when the creator departs. Figure 12 shows this call flow in which the creator Alice departs causing the conference to be deleted. Note that the order of sending BYEs and final NOTIFYs is not important. Johnston & Levin Expires January 16, 2005 [Page 30] Internet-Draft SIP CC Conferencing for UAs July 2004 Alice Focus Bob Carol | | | | |<==================>|<==================>| | | BYE F1 |<=======================================>| |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | BYE F3 | | | |------------------->| | | | 200 OK F4 | | | |------------------->| | | | BYE F5 | | |---------------------------------------->| | | 200 OK F6 | | |<----------------------------------------| | NOTIFY Subscription-State:terminated F7 | |<-------------------| | | | 200 OK F8 | | | |------------------->| NOTIFY Subscription-State:terminated F9 | |------------------->| | | | 200 OK F10 | | | |<-------------------| | | | NOTIFY Subscription-State:terminated F11 | |---------------------------------------->| | | 200 OK F12 | | |<----------------------------------------| Figure 12. Deleting a Conference 4.13 Discovery of Conferencing Capabilities using OPTIONS A UA MAY send an OPTIONS request to discover if an opaque URI is a conference URI (resolves to a focus). In addition, the reply to the OPTIONS request can also indicate support for various SIP call control extensions used in this document. Note that the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus or a 200 OK answer from the focus to an INVITE as a part of a normal dialog establishment process. An example is shown in Figure 13 where Alice sends an OPTIONS to a URI which resolves to a focus. Johnston & Levin Expires January 16, 2005 [Page 31] Internet-Draft SIP CC Conferencing for UAs July 2004 Alice Focus Bob Carol | | | | | OPTIONS sip:Conf-ID F1 | | |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F2 | | |<-------------------| | | Figure 13. Participant Queries Capabilities of URI which resolves to a Focus. Following is an example message detail of message F2 in Figure 13. Based on the response, Alice's UAlearnslearns that the URI is a conference URI and that the responding UA is focus that supports a number of SIP call control extensions. The response details are as follows: F2 SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:3402934234@example.com>;tag=93810874 From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: refer, conference Accept: application/sdp, application/conference-info+xml, message/sipfrag Accept-Language: en Supported: replaces, join, gruu Content-Type: application/sdp Content-Length: ... v=0 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com s=Example Subject i=Example Conference Hosted by Example.com u=http://conf.example.com/3402934234 e=3402934234@conf-help.example.com p=+18882934234 c=IN IP4 ms5.conf.example.com t=0 0 m=audio 49170 RTP/AVP 0 1 3 5 7 m=video 51372 RTP/AVP 31 32 Useful information from each of these headers is detailed in the next Johnston & Levin Expires January 16, 2005 [Page 32] Internet-Draft SIP CC Conferencing for UAs July 2004 sections. Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicate that the user agent supports call control and SIP Events. Accept. The support of bodies such as message/sipfrag [14], application/conference-info+xml [5] also indicates support of call control and conferencing. Allow-Events. The support of event packages such as refer [3], conference [5]. Supported. The support of extensions such as replaces, join, and gruu. Contact. The presence of the "isfocus" feature parameter in the Contact header indicates that the URI is a conference URI and that the UA is a focus. 5. Appendix - Creating a Conference by a Conference-Unaware UA This section discussed how a human user operating a conference-unaware UA can create and add participants to a conference. This method is described as an appendix since it is NOT RECOMMENDED. The scenarios involving creating a conference using ad-hoc or manual means are recommended over this scenario. This scenario is included, however, for completeness. A user (human) would choose a conference URI according to system rules and insert it into the Request-URI of the INVITE. This same URI is echoed by a focus adhering to certain addressing conventions (discussed below) in the Contact header by the focus. Additional participants could be added by non-SIP means (publication of the chosen conference URI using web pages, email, IM, etc.). Alternatively, the conference-unaware UA could then add other participants to the conference using SIP call control by establishing a session with them, then transferring [17] them to the conference URI. Note that in this scenario only the user (human) is aware of the conferencing application, and the conference-unaware UA only need support RFC 3261 and optionally call transfer. Making this work does impose certain addressing conventions on a system. As a service/implementation choice, a system could allow the creator of the conference to choose the user portion of the conference URI. However, this requires the URI format to be agreed upon between a user and the system. For example, a service provider might reserve the domain Johnston & Levin Expires January 16, 2005 [Page 33] Internet-Draft SIP CC Conferencing for UAs July 2004 conf.example.com for all conference URIs. Any URI in the domain of conf.example.com would resolve to the focus. The focus could be configured to interpret an unknown user part in the conf.example.com domain as a request for a conference to be created with the conference URI as the Request-URI. For example, an INVITE sent with a Request-URI of sip:k32934208ds72@conf.example.com could be routed to the focus that would then create the conference. This conference URI should be registered by the newly created focus to become routable as a conference URI within the conf.example.com domain. The returned Contact would look as follows: Contact: <sip:k32934208ds72@conf.example.com>;isfocus Note, however, that this approach relies on conventions adopted between the user (human) and the focus. Also, the approach is not robust against collisions in the conference names. If a second user wishing to create a new conference happened to choose the same user part as an existing conference, the result would be that theURI issecond user would be added into the existing conference instead of creating a new one. As a result, methods of conferenceURI and thatcreation in which theresponding UAconference URI is an opaque URI generated by the focusthat supports a number of SIPare preferred. An example callcontrol extensions.flow is shown in Figure 14. Theresponse details are as follows: F2 SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:3402934234@example.com>;tag=93810874 From:participant Alice<sip:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:3402934234@example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: refer,creates the conferenceAccept: application/sdp, application/conference-info+xml, message/sipfrag Accept-Language: en Supported: replaces, join, gruu Content-Type: application/sdp Content-Length: ... v=0 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com s=Example Subject i=Example Conference Hosted by Example.com u=http://conf.example.com/3402934234 e=3402934234@conf-help.example.com p=+18882934234 c=IN IP4 ms5.conf.example.com t=0 0 m=audio 49170 RTP/AVP 0 1 3 5 7 m=video 51372 RTP/AVP 31 32 Useful information from each of these headers is detailed inURI (using some convention agreed to with thenext sections. Allow. The support of methods such as REFER, SUBSCRIBE,focus domain) andNOTIFY indicatesends an INVITE to that URI which creates theuser agent supports call control and SIP Events. Accept.focus. Thesupport of bodies such as message/sipfrag [14], application/conference-info+xml [5] also indicates support of call controlfocus 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 andconferencing.chooses the conference URI. | | | | | | INVITE sip:Conf-ID F1 | | |------------------->| | | | 180 Ringing F2 | | | |<-------------------| | | | 200 OK Contact:Conf-ID;isfocus F3 | | |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | Figure 14. A Conferencing Unaware Participant Creates a Conference Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page28]34] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004Allow-Events. The support of event packages such as refer [3], conference [5]. Supported.6. IANA Considerations This specification registers a single SIP option tag, conf. 6.1 SIP Option Tag Thesupport of extensions suchrequired information for this registration, asreplaces, join, and gruu. Contact. The presence of the "isfocus" feature parameterspecified inthe ContactRFC 3261 [2], is: Name: conf Description: This option tag is used in a Supported headerindicatesfield of a request or response to indicate that theURIUser Agent isa conference URIconference-aware andthatsupports theUA is a focus. 5.extensions and scenarios described in this specification. 7. Security Considerations This document discusses call control for SIP conferencing. Both call control and conferencing have specific security requirements which will be summarized here. Conferences generally have authorization rules about who may or may not join a conference, what type of media may or may not be used, etc. This information is used by theFocusfocus to admit or deny participation in a conference. It is recommended that these types of authorization rules be used to provide security for a SIP conference. For this authorization information to be used, the focus needs to be able to authenticate potential participants. Normal SIP mechanisms including Digest authentication and certificates can be used. These conference specific security requirements are discussed further in the requirements and framework documents. For call control security, a user agent must maintain local policy on who is permitted to perform call control operations, initiate REFERs, and replace dialogs. Normal SIP authentication mechanisms are also appropriate here. The specific authentication and authorization schemes are described in the multiparty call control framework document.6.8. Contributors We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions.7.Johnston & Levin Expires January 16, 2005 [Page 35] Internet-Draft SIP CC Conferencing for UAs July 2004 9. Changes since -03 - Added definition and IANA registration for conf option tag for UAs - Added requirement and flow for deletion of conference - Added scenario of participant requesting focus refer a participant to the conference - Added scenario of moving a point to point call to a conference with a separate focus 10. Changes since -02 - Added reference and text about use of GRUUs. - Updated for latest version of conference package. - Clarified that conference package subscription should use a separate dialog from INVITE dialog.Johnston & Levin Expires August 15, 2004 [Page 29] Internet-Draft SIP CC Conferencing for UAs February 2004 8.11. Changes since -01 - Added messages details of selected INVITE, 200 OK, SUBSCRIBE, REFER, and NOTIFY messages.9.12. Changes since -00 - Showed separation between conference factory application and focus by having the application redirect to the newly created focus in the ad-hoc creation scenario. - Removed inclusion of "isfocus" parameter in Refer-To header field - this may be a useful extension to the REFER mechanism in the future, however. - Updated reference from Caller Prefs document to the new Capabilities of User Agents document. - Added scenario of participant changing user agents during a conference. - Added requirement on focus to support Replaces header field. - Added discussion about termination of dialog using BYE and subscription using SUBSCRIBE/NOTIFY to flows involving termination of session with the focus. Johnston & Levin Expires January 16, 2005 [Page 36] Internet-Draft SIP CC Conferencing for UAs July 2004 13. References 13.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State",draft-ietf-sipping-conference-package-02draft-ietf-sipping-conference-package-04 (work in progress),October 2003.May 2004. [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP)Johnston & Levin Expires August 15, 2004 [Page 30] Internet-Draft SIP CC Conferencing for UAs February 2004'Join' Header",draft-ietf-sip-join-02draft-ietf-sip-join-03 (work in progress),July 2003.February 2004. [7] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. [8] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation Protocol (SIP) 'Replaces' Header",draft-ietf-sip-replaces-04draft-ietf-sip-replaces-05 (work in progress),August 2003.February 2004. [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",draft-ietf-sip-gruu-00draft-ietf-sip-gruu-02 (work in progress),JanuaryJuly 2004. 13.2 Informative References [10] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", draft-ietf-sipping-conferencing-requirements-00 (work in progress), April 2003. [11] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol",draft-ietf-sipping-conferencing-framework-01draft-ietf-sipping-conferencing-framework-02 (work in Johnston & Levin Expires January 16, 2005 [Page 37] Internet-Draft SIP CC Conferencing for UAs July 2004 progress),October 2003.June 2004. [12] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-03 (work in progress), October 2003. [13] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [14] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [15] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [16] Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples",draft-ietf-sipping-service-examples-05draft-ietf-sipping-service-examples-06 (work in progress),September 2003.February 2004. [17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer",draft-ietf-sipping-cc-transfer-01draft-ietf-sipping-cc-transfer-02 (work inJohnston & Levin Expires August 15, 2004 [Page 31] Internet-Draft SIP CC Conferencing for UAs February 2004progress), February2003.2004. [18] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)",draft-ietf-sipping-dialog-package-03draft-ietf-sipping-dialog-package-04 (work in progress),October 2003.February 2004. Authors' Addresses Alan Johnston MCI 100 South 4th Street St. Louis, MO 63102 EMail: alan.johnston@mci.com Orit Levin Microsoft One Microsoft Way Redmond, WA 75024 EMail: oritl@microsoft.com Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page32]38] Internet-Draft SIP CC Conferencing for UAsFebruaryJuly 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of anyintellectual propertyIntellectual 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;neithernor does it represent that it has made any independent effort to identify any such rights. Information on theIETF'sprocedures with respect to rights instandards-track and standards-related documentationRFC documents can be found inBCP-11.BCP 78 and BCP 79. Copies ofclaims of rightsIPR disclosures madeavailable for publicationto 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 byimplementorsimplementers or users of this specification can be obtained from the IETFSecretariat.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 rightswhichthat may cover technology that may be required topracticeimplement this standard. Please address the information to the IETFExecutive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 purposeat ietf-ipr@ietf.org. Disclaimer ofdeveloping Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.Validity This document and the information contained hereinisare 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 FORCEDISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONJohnston & Levin Expires August 15, 2004 [Page 33] Internet-Draft SIP CC Conferencing for UAs February 2004HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Johnston & Levin ExpiresAugust 15, 2004January 16, 2005 [Page34]39] ----