idnits 2.17.1 draft-johnston-sipping-cc-conferencing-00.txt: -(930): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1009): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 16 looks like a reference -- Missing reference section? '2' on line 52 looks like a reference -- Missing reference section? '3' on line 284 looks like a reference -- Missing reference section? '4' on line 420 looks like a reference -- Missing reference section? '5' on line 420 looks like a reference -- Missing reference section? '6' on line 91 looks like a reference -- Missing reference section? '7' on line 106 looks like a reference -- Missing reference section? '8' on line 114 looks like a reference -- Missing reference section? '9' on line 117 looks like a reference -- Missing reference section? '10' on line 241 looks like a reference -- Missing reference section? '11' on line 251 looks like a reference -- Missing reference section? '12' on line 251 looks like a reference -- Missing reference section? '13' on line 251 looks like a reference -- Missing reference section? '14' on line 273 looks like a reference -- Missing reference section? '15' on line 306 looks like a reference -- Missing reference section? '16' on line 395 looks like a reference -- Missing reference section? '17' on line 815 looks like a reference -- Missing reference section? '18' on line 867 looks like a reference -- Missing reference section? '19' on line 870 looks like a reference -- Missing reference section? '20' on line 879 looks like a reference -- Missing reference section? '21' on line 896 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG 3 Internet Draft A. Johnston 4 Document: WorldCom 5 draft-johnston-sipping-cc-conferencing-00.txt O. Levin 6 RADVISION 7 Expires: April 2003 October 2002 9 Session Initiation Protocol Call Control - 10 Conferencing for User Agents 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes providing Conferencing call control 35 capabilities in the Session Initiation Protocol (SIP). This document 36 builds on the Conferencing Requirements and Framework documents to 37 show how a tightly coupled SIP conference will work. The approach is 38 explored from a user agent (UA) perspective. Three types of UAs are 39 described: a conferencing unaware UA, one capable of being a full 40 member of a conference, and one also capable of hosting a conference. 41 The use of URIs in conferencing, OPTIONS for capability discovery, 42 and call control using REFER are covered in detail with example call 43 flow diagrams. 45 SIP Call Control - Conferencing for UAs October 2002 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [2]. 53 Table of Contents 55 1. Introduction...................................................2 56 2. SIP Conferencing Vocabulary....................................3 57 3. Conferencing URIs..............................................3 58 3.1 Use of a General URI in Conferencing.......................3 59 3.2 Focus SIP URI..............................................4 60 3.3 Conference SIP URI.........................................4 61 3.4 Globally Routable Contact Requirements.....................4 62 4. SIP User Agent Conferencing Capability Types...................5 63 4.1 Type I - Conference Unaware UA.............................5 64 4.2 Type II - Conference Member Capable UA.....................5 65 4.3 Type III - Conference Member and/or Focus Capable UA.......6 66 5. Discovery of Conferencing Capabilities using OPTIONS...........6 67 5.1 Requirements Review........................................6 68 5.2 Definitions................................................7 69 5.3 Examples...................................................8 70 6. SIP Conferencing Implementation................................9 71 6.1 SIP Conferencing Building Blocks...........................9 72 6.2 Creating a Conference......................................9 73 6.3 Creating a Conference by a Type I UA......................11 74 6.4 Dialing into a Conference by Conference URI...............12 75 6.5 Dial out - Added by the Focus.............................13 76 6.6 Requesting the Focus Add a New Resource to a Conference...15 77 6.7 Adding a 3rd Party Using Conference ID....................16 78 6.8 Adding a 3rd Party Using Call ID..........................18 79 6.9 Bringing a Point-to-Point Dialog into a Conference........19 80 Security Considerations..........................................20 81 References.......................................................20 82 Acknowledgments..................................................21 83 Author's Addresses...............................................21 85 1. Introduction 87 This document uses the concepts and definitions in the Session 88 Initiation Protocol(SIP) [3] conferencing framework document [4] and 89 the requirements in [5]. The call control and dialog manipulation 90 approach is based on that outlined in the Multiparty Framework 91 document [6]. That document defines the basic approach of service 92 design adopted for SIP which includes: 94 - Definition of primitives, not services 95 SIP Call Control - Conferencing for UAs October 2002 97 - Participant oriented 98 - Signaling model independent 99 - Invoker oriented 100 - Primitives make full use of URIs 101 - Include authentication, authorization, logging, etc. policies 102 - Define graceful fallback to baseline SIP. 104 The use of opaque URIs and the ability to communicate call control 105 context information within a URI (as opposed to service-related 106 header fields), as discussed in RFC 3087 [7], is fundamental to this 107 document. 109 All cases begin with an assumption that a URI is known to a user 110 agent. Some SIP mechanisms for URI discovery are described here, 111 including the use of OPTIONS and extracting URIs from Contact header 112 fields. However, other methods can be used and may be developed. 113 For example, current work in the ENUM working group described in RFC 114 2916bis [8] to include service tags in addition to protocols to map 115 to a URI. For further study is the idea to use a DNS SRV-like 116 process to discover URIs relating to conferencing services. Another 117 idea is to use Service Location Protocol RFC 2608 [9] for this 118 purpose. 120 2. SIP Conferencing Vocabulary 122 For the terminology and assumptions used in this document, refer to 123 the conferencing requirements [5] and framework [4] documents. 125 This document presents the basic call control (dial-in and dial-out) 126 conferencing building blocks from the UA perspective. For 127 illustration of the possible applications we refer to the application 128 vocabulary of ad-hoc, scheduled, server and end user. 130 3. Conferencing URIs 132 A user agent that hosts conferences can have three types of URIs that 133 resolve to it: a general URI, a focus URI and conference URIs. All 134 three types assist in supporting different conferencing scenarios. 135 The latter two are dedicated to conferencing. 137 The general URI and focus URI are likely to be well known URIs in 138 that they would be published 140 3.1 Use of a General URI in Conferencing 142 Using a general URI (typically referred as the user�s address of 143 record), a focus can support creation, control, and manipulation of a 144 conference in a similar manner to that common in PSTN today. 146 SIP Call Control - Conferencing for UAs October 2002 148 In this kind of scenario, inclusion of the general URI in the 149 Request-URI would lead to a human user (in an end point) or to an IVR 150 service (in a conferencing server) for INVITEs generated from a 151 conferencing unware UA as will be shown in the following sections. 153 3.2 Focus SIP URI 155 Another type of URI is what we will call the focus URI. An INVITE 156 sent to the focus URI is a request to setup an ad-hoc conference, as 157 will be shown in the following sections. 159 3.3 Conference SIP URI 161 As specified in the conferencing framework document [4], the 162 conference ID is a SIP URI. A URI which represents a particular 163 conference instance is referred to as a conference URI. A request 164 sent to this URI will result in a member being added (or removed, 165 depending on the method) to (or from) a particular conference. 167 As will be shown later, it can be discovered from Contact header 168 field in an INVITE or 200 OK in the dialog establishment with a 169 focus. It can then be used in a Request-URI or Refer-To header field 170 to add members to the conference. 172 3.4 Globally Routable Contact Requirements 174 As was specified before, the Conference URI MUST be globally 175 routable. Since, according to this document, the Contact header field 176 is used to convey this URI, this requires that Contact URIs from a 177 focus be globally routable URIs. 179 This requirement is identical to that in Section 8.1.1.8 in RFC 3261 180 [3]. However, the specified use in conferencing of the Contact URI 181 outside of a dialog makes satisfying this requirement critical. 183 If the focus requires that all requests be routed through a proxy 184 server, then special care MUST be taken with the creation of this 185 Contact URI. To satisfy this requirement, the Contact URI MUST 186 either route to the proxy server or resolve to the proxy server, with 187 an additional SIP registration step being required to further resolve 188 this URI to the specific device. 190 For example, consider a focus with a hostname server51.chicago.com 191 which creates a conference URI. A normal Contact could be of the 192 form: 194 Contact: ;isFocus 195 SIP Call Control - Conferencing for UAs October 2002 197 (The "isFocus" parameter is described in Section 5.2 below.) 198 However, if this focus requires that all requests come through a 199 proxy server at p1.chicago.com then this Contact will not work as the 200 proxy will be bypassed. One approach is to include an escaped loose 201 Route header field in the Contact URI: 203 Contact: ;isFocus 206 This would result in a request being sent to 207 sip:389390542457@serv51.chicago.com with a loose Route header forcing 208 routing to sip:p1.chicago.com first. 210 Editor�s Note: Open Issue: This syntax, while allowed in a 211 redirection, is not permitted in an INVITE or 200 OK response per 212 Table 1 in RFC 3261. 214 Another approach would involve a Contact of the form: 216 Contact: ;isFocus 218 in which this sip:389390542457@chicago.com URI would be registered by 219 the focus against a Contact: 221 Contact: 223 which resolves directly to the focus. Other approaches may also be 224 used to generate this globally routable Contact URI. 226 4. SIP User Agent Conferencing Capability Types 228 We can identify three different SIP user agent (UA) applications 229 regarding their conferencing capabilities. 231 4.1 Type I - Conference Unaware UA 233 The simplest user agent can participate in a conference ignoring all 234 SIP conferencing-related information. The simplest user agent is able 235 to dial into a conference and to be invited to a conference. All 236 conferencing information (if any) is conveyed to it using non-SIP 237 means. Such s user agent would not usually host a conference (at 238 least, not using SIP explicitly). A Type I UA need only support RFC 239 3261 [3]. Call flows for Type I UAs are not shown in general in this 240 document as they would be identical to those in the SIP Call Flows 241 document [10]. 243 4.2 Type II - Conference Member Capable UA 244 SIP Call Control - Conferencing for UAs October 2002 246 A Type II user agent can support SIP conferencing conventions and 247 extensions merely as a conference member. Such user agents do not 248 have focus capabilities. 250 From a SIP requirements perspective, a Type II UA would support REFER 251 [11], SIP Events [12], the conferencing package [13], and the 252 conventions of conferencing call control defined in this document, in 253 addition to support of RFC 3261. 255 4.3 Type III - Conference Member and/or Focus Capable UA 257 The next level of user agents is capable of both being a conference 258 member and a conference focus. This is a special capability and can 259 be discovered using the techniques described in Section 5. 261 A user agent of this type could be implemented in end user equipment 262 and would be used for ad-hoc creation of small to middle size 263 conferences. 265 Alternatively, a type III UA could be a dedicated conferencing server 266 whose primary task is to host conferences of any type and size. Note 267 that a certain conference instance can bridge members having 268 different capabilities who have joined the conference by different 269 means (i.e. dial-in, dial-out, scheduled and ad-hoc). 271 A conference server typically will not be a single device but a 272 function decomposed into media servers, IVR systems, etc as described 273 in the Application Components document [14]. In this document, 274 however, it will be discussed as if it were a UA with certain focus 275 capabilities. 277 A conference server will likely have all three types of URIs (as 278 specified above) that resolve to it: a general URI, a focus URI, and 279 conference URIs. 281 5. Discovery of Conferencing Capabilities using OPTIONS 283 The general means of capability discovery in SIP is the OPTIONS 284 method as detailed in Section 11 of RFC 3261 [3]. This same method 285 can be used by a user agent to discover conferencing capabilities. 287 5.1 Requirements Review 289 Currently the only requirement is to distinguish between Type I/II 290 vs. Type III user agents. Should additional conferencing extensions 291 defined in future, means to distinguish between Type I vs. Type II 292 user agents may be required. 294 SIP Call Control - Conferencing for UAs October 2002 296 5.2 Definitions 298 A UA MAY send an OPTIONS request to discover the conferencing 299 capabilities of another UA. If the UA responding to the query has 300 conferencing-related capabilities and wants to share this 301 information, it can do so in the reply to the OPTIONS request. 303 If the UA identified by the general URI in the OPTIONS request has an 304 ability to act as a focus, the OPTIONS response SHOULD indicate this 305 by the inclusion of the focus URI with "isFocus" caller prefs 306 parameter [15] in a Contact header field. 308 Editor�s Note: This Contact header field "isFocus" parameter is 309 currently not defined in the base caller prefs [Error! Bookmark 310 not defined.] document, but needs be added as an extension. 312 This OPTIONS request can be sent outside a dialog (pre-call) or 313 within an established dialog (mid-call). In both cases, inclusion of 314 the "isFocus" parameter in a Contact header in the reply to the 315 OPTIONS request expresses the ability of the UA to host a conference 316 (i.e. having focus capabilities) as opposite to having a focus active 317 for this call. 319 A UA receiving an OPTIONS request SHOULD generate a well-formed 320 response containing Allow, Accept, Allow-Events, and Supported, and 321 Contact header fields. 323 An OPTIONS query sent to either a general or focus URIs would likely 324 return Contact URIs listing both the general URI and the focus URI. 326 An OPTIONS query to the general or focus URI would not return a list 327 of active conference URIs hosted by the server. This information can 328 be retrieved using a method TBD. 330 OPEN ISSUE: In general, nothing in this specification prohibits 331 conference URIs discovery using the OPTIONS method. That being 332 said, currently, there is no way to distinguish between focus URI 333 and conference URI: an OPTIONS sent to a particular conference URI 334 would return a response containing that conference URI in a 335 Contact containing the "isFocus" parameter, same as for a focus 336 URI. 338 OPEN ISSUE: Should an OPTIONS request sent to a conference URI not 339 return the focus URI? Or the general URI? 341 Note that the Allow, Accept, Allow-Events, and Supported header 342 fields should be present in an INVITE from a focus or a 200 OK answer 343 from the focus to an INVITE as a part of a normal dialog 344 establishment process. Inclusion of the Contact header with "isFocus" 345 SIP Call Control - Conferencing for UAs October 2002 347 parameter by the focus signals to a UA that the dialog is a part of a 348 conference identified by the URI in the Contact header. 350 5.3 Examples 352 This section contains an example response to an OPTIONS request sent 353 by Alice to Carol (sent to Carol's address of record, i.e. general 354 URI). Based on the response, Alice's UA learns that Carol's UA has 355 conferencing and focus capabilities (Type III UA), and learns the 356 focus URI which could be used later to invoke conferencing services. 358 The response details are as follows: 360 SIP/2.0 200 OK 361 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 362 ;received=192.0.2.4 363 To: ;tag=93810874 364 From: Alice ;tag=1928301774 365 Call-ID: a84b4c76e66710 366 CSeq: 63104 OPTIONS 367 Contact: 368 Contact: ;isFocus 369 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 370 SUBSCRIBE, NOTIFY 371 Allow-Events: refer, conference 372 Accept: application/sdp, application/conference-info+xml, 373 message/sipfrag 374 Accept-Language: en 375 Supported: pref, replaces 376 Content-Type: application/sdp 377 Content-Length: 274 379 (SDP not shown) 381 Useful information from each of these headers is detailed in the next 382 sections. 384 Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY 385 indicate that the user agent supports call control and SIP Events. 387 Accept. The support of bodies such as message/sipfrag, 388 application/conference-info+xml also indicates support of call 389 control and conferencing. 391 Allow-Events. The support of event packages such as refer, 392 conference. 394 Supported. The support of extensions such as caller prefs [Error! 395 Bookmark not defined.] and replaces [16]. 397 SIP Call Control - Conferencing for UAs October 2002 399 Editor's Note: If an extension tag for some TBD conferencing 400 related extensions is defined, it would be present here. 402 Contact. This OPTIONS response contains two Contact header fields. 403 The first one is just Carol's address of record (i.e. the general 404 URI) for session establishment, etc. The second Contact URI is the 405 URI of Carol's focus. This can be determined by the presence of the 406 "isFocus" caller preferences [Error! Bookmark not defined.] 407 parameter. The presence of a Contact with this parameter confirms 408 that Carol's UA is a Type III UA. 410 6. SIP Conferencing Implementation 412 Note that most the scenarios described below apply equally for ad-hoc 413 or reserved conference, with the exception of Sections 6.2 and 6.3 on 414 creating a conference which does not apply to a reserved conference. 416 6.1 SIP Conferencing Building Blocks 418 The scenarios presented below are the call control building blocks 419 for various SIP tight conferencing applications as described in the 420 conferencing requirements [5] and framework documents [4]. In the 421 sections below we present typical SIP conferencing call control flows 422 and discuss the applicability of each for different conferencing 423 situations. The major design goal is that the same SIP conferencing 424 building blocks would be used by user agents having different 425 conferencing capabilities and comprising different applications. 427 6.2 Creating a Conference 429 This section addresses creating an ad-hoc conference by interaction 430 with a focus URI with the focus being responsible for the conference 431 ID generation. 433 This approach requires awareness of conferencing information from the 434 members. Only a Type II UA will know to retrieve the conference 435 information (from the Contact header) and use it for adding new 436 members. 438 The benefit of this approach is that the details and conventions of 439 the deployed conferencing infrastructure are transparent to the 440 members (and the participating users), since they treat the 441 Conference ID merely as an opaque URI. That allows for building 442 automated end user applications in a play-and-plug manner. 444 To create a conference, a UA SHOULD send an INVITE (with the Request- 445 URI set to the focus URI) to the focus that will host the conference. 447 SIP Call Control - Conferencing for UAs October 2002 449 The SIP URI of the focus can be provisioned in the UA or can be 450 discovered using any of the means described earlier in this document. 452 The focus can distinguish this INVITE request as a request to create 453 a new ad-hoc conference from a request to join an existing conference 454 by the Request-URI. In this flow, the focus is a Type III UA, so it 455 maintains different types of URIs as discussed in the previous 456 sections. 458 Assuming that all security and policy requirements have been met, the 459 focus SHOULD create the conference with the Contact URI returned in 460 the 200 OK being the conference URI. The Contact header field SHOULD 461 contain the "isFocus" parameter to indicate that this URI is for a 462 conference. 464 The UA creating the conference SHOULD send a SUBSCRIBE to the 465 conference URI with the conference event package. 467 An example call flow is shown in Figure 1. Note that Focus is 468 shorthand for the focus URI and Conf-ID Is short for the conference 469 URI. In this flow, Alice creates a conference by sending an INVITE 470 to the focus URI. Once the media session is established, Alice 471 subscribes to the conference URI obtained through the Contact in the 472 200 OK response from the focus. 474 Alice Focus Bob Carol 475 | | | | 476 | Alice creates the conference. | | 477 | | | | 478 | INVITE sip:Focus F1| | | 479 |------------------->| | | 480 | 180 Ringing F2 | | | 481 |<-------------------| | | 482 | 200 OK Contact:Conf-ID;isFocus F3 | | 483 |<-------------------| | | 484 | ACK F4 | | | 485 |------------------->| | | 486 | RTP | | | 487 |<==================>| | | 488 | | | | 489 | Alice subscribes to the conference URI. | | 490 | | | | 491 | SUBSCRIBE sip:Conf-ID F5 | | 492 |------------------->| | | 493 | 200 OK F6 | | | 494 |<-------------------| | | 495 | NOTIFY F7 | | | 496 |<-------------------| | | 497 SIP Call Control - Conferencing for UAs October 2002 499 | 200 OK F8 | | | 500 |------------------->| | | 502 Figure 1. Creation of a Conference. 504 6.3 Creating a Conference by a Type I UA 506 It is a requirement that a Type I UA be able to create and add 507 participants to a conference without understanding any of the 508 conferencing conventions or extensions (such as in Section 6.2 509 above). The only way to accomplish this is for the participant 510 (human) to choose the conference URI in the domain of the focus URI. 511 The disadvantages of this approach are discussed later in the 512 section. 514 A user (human) would choose a conference URI according to system 515 rules and insert it into the Request-URI of the INVITE. This same URI 516 is echoed by a focus adhering to certain conventions (discussed 517 below) in the Contact header by the focus. Additional members could 518 be added by non-SIP means (publication of the chosen conference URI 519 using web pages, email, IM, etc.). Alternatively, the Type I UA 520 could then add other participants to the conference using SIP call 521 control by establishing a session with them, then transferring them 522 to the conference URI [17]. Note that only the participant (human) 523 is aware of the conferencing application, and the Type I UA only need 524 support RFC 3261 and optionally call transfer. 526 Making this work does impose certain requirements on a focus. As a 527 service/implementation choice, a focus could allow the creator of the 528 conference to choose the user portion of the conference URI. However, 529 this requires URI and behavior conventions to be used by both members 530 and the focus. 532 For example, a service might reserve the domain conf.example.com for 533 all conference URIs. The focus URI could be 534 sip:focus@conf.example.com. The focus could be configured to 535 interpret an unknown Request-URI in the conf.example.com domain as a 536 request for a conference to be created with the conference URI as the 537 Request-URI. For example, an INVITE sent with a Request-URI of 538 sip:k32934208ds72@conf.example.com could be routed to the focus who 539 would then create a conference. This conference URI should be 540 registered by the focus to become routable as a conference URI within 541 the conf.example.com domain. The returned Contact would look as 542 follows: ;isFocus. Note, 543 however, that this approach relies on conventions adopted between the 544 participant (human) and the focus. 546 SIP Call Control - Conferencing for UAs October 2002 548 As a result, the method of the conference URI as an opaque URI being 549 generated by the focus (as per Section 6.2) is preferred. 551 To join an existing specific conference a UA SHOULD send an INVITE to 552 the conference URI chosen by the first participant. The rest of this 553 scenario is shown in Section 6.4. 555 An example call flow is shown in Figure 2. The participant Alice 556 creates the conference URI (using some convention agreed to with the 557 focus domain) and sends an INVITE to that URI which reaches the 558 focus. The focus creates the conference and returns the same 559 conference URI in the 200 OK answer to the INVITE (which is ignored 560 by the Type I UA). 562 Alice Focus Bob Carol 563 | | | | 564 | Alice creates the conference and chooses the conference URI. | 565 | | | | 566 | INVITE sip:Conf-ID F1 | | 567 |------------------->| | | 568 | 180 Ringing F2 | | | 569 |<-------------------| | | 570 | 200 OK Contact:Conf-ID;isFocus F3 | | 571 |<-------------------| | | 572 | ACK F4 | | | 573 |------------------->| | | 574 | RTP | | | 575 |<==================>| | | 577 Figure 2. A Conferencing Unaware (Type I) UA Creates a Conference 579 6.4 Dialing into a Conference by Conference URI 581 In this section a UA knows the conference URI and "dials in" to join 582 this conference. The conference URI can be reserved using non-SIP 583 mechanisms, or generated using the methods of Sections 6.2 or 6.3. 585 If the UA is the first member of the conference to dial in, it is 586 likely that this INVITE will "create" the conference. However, the 587 conference URI must have been created prior to its use. 589 When the conference is up and running already, the dialing-in member 590 is joined to the conference by a focus. 592 To join an existing specific conference a UA SHOULD send an INVITE to 593 the conference URI. 595 SIP Call Control - Conferencing for UAs October 2002 597 Assuming that all security and policy requirements have been met, the 598 focus SHOULD establish the session with the UA and "mix" the media 599 appropriately with existing conference members. 601 The UA SHOULD subscribe to the conference URI with the conference 602 event package. 604 The focus SHOULD notify other members that a new member has been 605 added. 607 An example call flow is shown in Figure 3. It is assumed that Alice 608 is already in the conference (has a session established with the 609 focus). 611 Alice Focus Bob Carol 612 | | | 613 |<==================>| | 614 | | Carol "dials in" to the conference | 615 | | | 616 | | INVITE sip:Conf-ID F1 | 617 | |<----------------------------------------| 618 | | 180 Ringing F2 | 619 | |---------------------------------------->| 620 | | 200 OK Contact:Conf-ID;isFocus F3 | 621 | |---------------------------------------->| 622 | | ACK F4 | 623 | |<----------------------------------------| 624 | | RTP | 625 | |<=======================================>| 626 | | SUBSCRIBE sip:Conf-ID F5 | 627 | |<----------------------------------------| 628 | | 200 OK F6 | 629 | |---------------------------------------->| 630 | | NOTIFY F7 | 631 | |---------------------------------------->| 632 | | 200 OK F8 | 633 | |<----------------------------------------| 634 | NOTIFY F9 | | 635 |<-------------------| | 636 | 200 OK F10 | | 637 |------------------->| | 639 Figure 3. A member "dials in" to an existing conference. 641 6.5 Dial out - Added by the Focus 642 SIP Call Control - Conferencing for UAs October 2002 644 This section is equally applicable for both ad-hoc and reserved 645 conferences. 647 To directly add a member to a conference, a focus SHOULD send an 648 INVITE to the member containing a Contact header field with the 649 conference URI and the �isFocus� header parameter. The resulting 650 media session SHOULD be appropriately mixed with the media from the 651 other members. 653 The new member SHOULD subscribe to the conference ID from the Contact 654 from the INVITE. 656 The simplest UA (as in Type I) would simply ignore the conferencing 657 information and treat the session (from a SIP perspective) as a point 658 to point session. 660 The focus SHOULD notify other participants that a new member has been 661 added. 663 An example call flow is shown in Figure 4. It is assumed that Alice 664 is already a member of the conference. The focus invites Carol to 665 the conference by sending an INVITE. After the session is 666 established, Carol subscribes to the conference URI. 668 Alice Focus Bob Carol 669 | | | | 670 |<==================>| | | 671 | | | 672 | Focus "dials out" to add Carol to the conference | 673 | | | 674 | | INVITE Contact:Conf-ID;isFocus F1 | 675 | |---------------------------------------->| 676 | | 180 Ringing F2 | 677 | |<----------------------------------------| 678 | | 200 OK F3 | 679 | |<----------------------------------------| 680 | | ACK F4 | 681 | |---------------------------------------->| 682 | | RTP | 683 | |<=======================================>| 684 | | SUBSCRIBE sip:Conf-ID F5 | 685 | |<----------------------------------------| 686 | | 200 OK F6 | 687 | |---------------------------------------->| 688 | | NOTIFY F7 | 689 | |---------------------------------------->| 690 | | 200 OK F8 | 691 | |<----------------------------------------| 692 | NOTIFY F9 | | 693 SIP Call Control - Conferencing for UAs October 2002 695 |<-------------------| | 696 | 200 OK F10 | | 697 |------------------->| | 699 Figure 4. Focus "dials out" to add Carol to the conference. 701 6.6 Requesting the Focus Add a New Resource to a Conference. 703 A SIP conference URI can be used to inject different kinds of 704 information into the conference. Examples include new members, new 705 real-time media sources, new IM messages, and pointers to passive 706 information references (such as HTTP URIs). 708 To request the focus add a new information resource to the specified 709 conference, any SIP UA can send a REFER to the conference URI with a 710 Refer-To containing the URI of the new resource. Since this REFER is 711 sent to the conference URI and not the focus URI, the semantics to 712 the focus are to bring the resource into the conference and make it 713 visible to the conference members. The resultant focus procedures are 714 dependant both on the nature of the new resource (as expressed by its 715 URI) and the own focus abilities regarding IM, central real time 716 media processing, etc. 718 The flow for adding a new UA member is important to consider because 719 it works even if the new member does not support REFER and transfer 720 call control - only the requesting member and the focus need to 721 support the call control. 723 Upon receipt of the REFER containing a Refer-To header with a SIP 724 URI, the focus SHOULD send an INVITE to the new member identified by 725 the Refer-To SIP URI containing a Contact header field with the 726 conference URI and the "isFocus" header parameter. The resulting 727 media session SHOULD be appropriately mixed with the media from the 728 other members. 730 The new member SHOULD subscribe to the conference ID from the Contact 731 from the INVITE. 733 The simplest UA (as in Type I) would simply ignore the conferencing 734 information and treat the session (from a SIP perspective) as a point 735 to point session. 737 The focus SHOULD notify other participants that a new member has been 738 added. 740 An example call flow is shown in Figure 5. It is assumed that Alice 741 is already a member of the conference. Alice sends a REFER to the 742 conference URI. The focus invites Carol to the conference by sending 743 SIP Call Control - Conferencing for UAs October 2002 745 an INVITE. After the session is established, Carol subscribes to the 746 conference URI. 748 Alice Focus Bob Carol 749 | | | | 750 |<==================>| | | 751 | REFER sip:Conf-ID Refer-To:Carol F1 | | 752 |------------------->| | 753 | 202 Accepted F2 | | 754 |<-------------------| | 755 | | | 756 | Focus "dials out" to add Carol to the conference | 757 | | | 758 | | INVITE Contact:Conf-ID;isFocus F3 | 759 | |---------------------------------------->| 760 | | 180 Ringing F4 | 761 | |<----------------------------------------| 762 | | 200 OK F5 | 763 | |<----------------------------------------| 764 | | ACK F6 | 765 | |---------------------------------------->| 766 | | RTP | 767 | |<=======================================>| 768 | NOTIFY F7 | | 769 |<-------------------| | 770 | 200 OK F8 | | 771 |------------------->| | 772 | | SUBSCRIBE sip:Conf-ID F9 | 773 | |<----------------------------------------| 774 | | 200 OK F10 | 775 | |---------------------------------------->| 776 | | NOTIFY F11 | 777 | |---------------------------------------->| 778 | | 200 OK F12 | 779 | |<----------------------------------------| 780 | NOTIFY F13 | | 781 |<-------------------| | 782 | 200 OK F14 | | 783 |------------------->| | 785 Figure 5. Member Requests Focus add member to the conference. 787 6.7 Adding a 3rd Party Using Conference ID 789 This section is equally applicable for both ad-hoc and reserved 790 conferences. 792 SIP Call Control - Conferencing for UAs October 2002 794 A member wishing to add a new member simply requests another 795 participant to send an INVITE to the conference URI. This can be 796 done using a non-SIP means (such as passing or publishing the 797 conference URI in an email, IM, or web page). If a non-SIP means is 798 used, then the flow and requirements are identical to Section 6.4. 800 The SIP mechanism to do this utilizes the REFER method. 802 A UA wishing to add a new member SHOULD send a REFER request to the 803 member with a Refer-To header containing the conference URI. 805 The requirements are then identical to the "dial in" case of Section 806 6.4. The UA MAY receive notification through the REFER action that 807 the new member has been added in addition to the notification 808 received through the conference package. 810 An example is shown in Figure 6. In this call flow, it is assumed 811 that Alice is already a member of the conference. Alice sends Bob an 812 "out of band" REFER - that is, a REFER outside of an established 813 dialog. Should Bob reject the REFER, Alice might try sending an 814 INVITE to Bob to establish a session first, then send a REFER within 815 the dialog, effectively transferring Bob into the conference [17]. 817 Alice Focus Bob Carol 818 | | | | 819 |<==================>| | | 820 | | | | 821 | Alice adds Bob into conference | | 822 | | | | 823 | REFER Refer-To:Conf-ID F1 | | 824 |---------------------------------------->| | 825 | 202 Accepted F2 | | | 826 |<----------------------------------------| | 827 | NOTIFY F3 | | | 828 |<----------------------------------------| | 829 | 200 OK F4 | | | 830 |---------------------------------------->| | 831 | | INVITE sip:Conf-ID F5 | 832 | |<-------------------| | 833 | | 180 Ringing F6 | | 834 | |------------------->| | 835 | | 200 OK Contact:Conf-ID;isFocus F7 | 836 | |------------------->| | 837 | | ACK F8 | | 838 | |<-------------------| | 839 | | RTP | | 840 | |<==================>| | 841 | | NOTIFY F9 | | 842 SIP Call Control - Conferencing for UAs October 2002 844 |<----------------------------------------| | 845 | | 200 OK F10 | | 846 |---------------------------------------->| | 847 | NOTIFY F11 | | | 848 |<-------------------| | | 849 | 200 OK F12 | | | 850 |------------------->| | | 851 | | SUBSCRIBE sip:Conf-ID F13 | 852 | |<-------------------| | 853 | | 200 OK F14 | | 854 | |------------------->| | 855 | | NOTIFY F15 | | 856 | |------------------->| | 857 | | 200 OK F16 | | 858 | |<-------------------| | 860 Figure 6. Adding a member to an existing conference. 862 6.8 Adding a 3rd Party Using Call ID 864 Under some circumstances, a member wanting to join a conference may 865 only know a dialog ID of one of the legs of the conference and the 866 focus URI, instead of the conference URI. The information may have 867 been learned using the dialog package [18] or some non-SIP means. If 869 A UA can request to be added to a conference by sending a request to 870 the focus containing a Join [19] header field containing a dialog ID 871 of one leg of the conference (a dialog between a member and the 872 focus). 874 There are other scenarios in which a Type III or even Type II UA 875 which is capable of creating a conference can use the Join header for 876 certain conferencing call control scenarios. 878 The Join header field is also useful in the transition of a two party 879 call to a conference call, as described in [20]. 881 To request a conference member to be added to the conference without 882 knowing the conference URI, a UA SHOULD send an INVITE request to the 883 focus URI containing a Join header field. The Join header field MUST 884 contain the dialog identifier of a valid dialog between the focus and 885 the member. 887 An example is shown in Figure 7. It is assumed that Alice is a 888 member of the conference. The dialog identifier between Alice and 889 the focus is abbreviated as A-F and is known by Bob. Bob requests to 890 be added to the conference by sending an INVITE message F1 to the 891 focus containing a Join header which contains the dialog identifier 892 SIP Call Control - Conferencing for UAs October 2002 894 A-F. Note that this dialog identifier could be learned through some 895 non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the dialog event 896 package [21]. Bob is added into the conference by the focus. 898 Alice Focus Bob Carol 899 | | | | 900 |<==================>| | | 901 | | | | 902 | Bob requests to be added to the conference. | 903 | | | | 904 | | INVITE sip:Focus Join:A-F F1 | 905 | |<-------------------| | 906 | | 180 Ringing F2 | | 907 | |------------------->| | 908 | | 200 OK Contact:Conf-ID;isFocus F3 | 909 | |------------------->| | 910 | | ACK F4 | | 911 | |<-------------------| | 912 | | RTP | | 913 | |<==================>| | 914 | | SUBSCRIBE sip:Conf-ID F5 | 915 | |<-------------------| | 916 | | 200 OK F6 | | 917 | |------------------->| | 918 | | NOTIFY F7 | | 919 | |------------------->| | 920 | | 200 OK F8 | | 921 | |<-------------------| | 923 Figure 7. Adding a member to an existing conference using Join. 925 6.9 Bringing a Point-to-Point Dialog into a Conference 927 A focus is capable of bringing an existing point-to-point dialog with 928 another UA to a conference that the focus hosts. The focus would do 929 it by sending re-INVITE changing the Contact URI to the conference 930 URI with the �isFocus� parameter. By doing this, the focus signals to 931 the UA that it becomes a member of the conference, specified in the 932 Contact header. 934 Currently, there is no way for a UA, being in an active point-to- 935 point call with a focus, to express by SIP call control means a 936 request to bridge its dialog with a specific conference or to create 937 a new conference and include the dialog in this conference. Instead, 938 a new dialog will need to be created. Even if the UA discovers that 939 the other side has focus capabilities, the UA needs to close the old 940 session and to establish a new session/dialog with the focus. 942 SIP Call Control - Conferencing for UAs October 2002 944 Editor's Note: Is this an issue? 946 Security Considerations 948 TBD 950 References 952 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 953 9, RFC 2026, October 1996. 955 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 956 Levels", BCP 14, RFC 2119, March 1997 958 3 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 959 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 960 Initiation Protocol", RFC 3261, June 2002. 962 4 J. Rosenberg, "A Framework for Conferencing with the Session 963 Initiation Protocol," October 2002, Work in Progress. 965 5 O. Levin, R. Even, P. Koskelainen, S. Sen, "Requirements for 966 Tightly Coupled SIP Conferencing," Internet Engineering Task 967 Force, November 2002, Work in progress. 969 6 R. Mahy, B. Campbell, A. Johnston, D. Petrie, J. Rosenberg, and R. 970 Sparks, "A Multi-party Application Framework for SIP," Internet 971 Engineering Task Force, February 2002, Work in progress. 973 7 B. Campbell and R. Sparks, "Control of Service Context using SIP 974 Request-URI," RFC 3087, April 2001. 976 8 P. Faltstrom and M. Mealing, "The E.164 to URI DDDS Application," 977 Internet Engineering Task Force, June 2002, Work in progress. 979 9 E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location 980 Protocol, Version 2," RFC 2608, June 1999. 982 10 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Basic Call 983 Flow Examples", Internet Draft, Internet Engineering Task Force, 984 October 2002, Work in Progress. 986 11 R. Sparks, "The Refer Method", Internet Draft, Internet 987 Engineering Task Force, July 2002, Work in Progress. 989 SIP Call Control - Conferencing for UAs October 2002 991 12 A. Roach, "SIP-Specific Event Notification," RFC 3265, June 2002. 993 13 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol 994 (SIP) Event Package for Conference State," Internet Engineering 995 Task Force, June 2002, Work in progress. 997 14 J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application 998 server component architecture for SIP," Internet Draft, Internet 999 Engineering Task Force, Mar. 2001. Work in progress. 1001 15 H. Schulzrinne and J. Rosenberg, "SIP Caller Preferences and 1002 Callee Capabilities," Internet Engineering Task Force, June 2001, 1003 Work in Progress. 1005 16 R. Mahy , B. Biggs, and R. Dean, "The SIP Replaces header," 1006 Internet Draft, Internet Engineering Task Force, April 2002, Work 1007 in Progress. 1009 17 R. Sparks and A. Johnston, "SIP Call Control � Transfer," Internet 1010 Engineering Task Force, October 2002, Work in progress. 1012 18 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol 1013 (SIP) Event Package for Dialog State," Internet Engineering Task 1014 Force, June 2002, Work in progress. 1016 19 R. Mahy and D. Petrie, "The Session Initiation Protocol (SIP) 1017 'Join' Header," Internet Engineering Task Force, June 2002, Work 1018 in progress. 1020 20 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Service 1021 Examples", Internet Draft, Internet Engineering Task Force, 1022 October 2002, Work in Progress. 1024 21 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol 1025 (SIP) Event Package for Dialog State," Internet Engineering Task 1026 Force, June 2002, Work in progress. 1028 Acknowledgments 1030 The authors would like to thank all the members of the SIPPING 1031 Conferencing design team for their input and discussions. 1033 Author's Addresses 1034 SIP Call Control - Conferencing for UAs October 2002 1036 Alan Johnston 1037 WorldCom 1038 100 South 4th Street 1039 St. Louis, MO 63102 1040 USA 1042 EMail: alan.johnston@wcom.com 1044 Orit Levin 1045 RADVISION 1046 266 Harristown Road 1047 Glen Rock, NJ USA 1049 Email: orit@radvision.com 1050 Phone: +1-201-689-6330 1052 Copyright Notice 1054 "Copyright (C) The Internet Society 2002. All Rights Reserved. 1056 This document and translations of it may be copied and furnished to 1057 others, and derivative works that comment on or otherwise explain it 1058 or assist in its implementation may be prepared, copied, published 1059 and distributed, in whole or in part, without restriction of any 1060 kind, provided that the above copyright notice and this paragraph are 1061 included on all such copies and derivative works. However, this 1062 document itself may not be modified in any way, such as by removing 1063 the copyright notice or references to the Internet Society or other 1064 Internet organizations, except as needed for the purpose of 1065 developing Internet standards in which case the procedures for 1066 copyrights defined in the Internet Standards process must be 1067 followed, or as required to translate it into languages other than 1068 English. 1070 The limited permissions granted above are perpetual and will not be 1071 revoked by the Internet Society or its successors or assigns. 1073 This document and the information contained herein is provided on an 1074 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1075 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1076 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1077 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1078 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1080 Acknowledgement 1082 Funding for the RFC Editor function is currently provided by the 1083 SIP Call Control - Conferencing for UAs October 2002 1085 Internet Society.