idnits 2.17.1 draft-ietf-sipping-cc-conferencing-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1690. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 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 of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 36) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 13 characters in excess of 72. == There are 2 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 21, 2004) is 7127 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) == Unused Reference: '1' is defined on line 1579, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1639, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-03 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-07 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-02 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-04 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group A. Johnston 2 Internet-Draft MCI 3 Expires: April 21, 2005 O. Levin 4 Microsoft 5 October 21, 2004 7 Session Initiation Protocol Call Control - Conferencing for User 8 Agents 9 draft-ietf-sipping-cc-conferencing-05 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 21, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This specification defines conferencing call control features for the 45 Session Initiation Protocol (SIP). This document builds on the 46 Conferencing Requirements and Framework documents to define how a 47 tightly coupled SIP conference works. The approach is explored from 48 different user agent (UA) types perspective: conference-unaware, 49 conference-aware and focus UAs. The use of URIs in conferencing, 50 OPTIONS for capabilities discovery, and call control using REFER are 51 covered in detail with example call flow diagrams. The usage of the 52 isfocus feature tag is defined. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Usage of the 'isfocus' Feature Parameter . . . . . . . . . . 3 58 2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2 Session Establishment . . . . . . . . . . . . . . . . . . 4 60 2.3 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. SIP User Agent Conferencing Capability Types . . . . . . . . 4 62 3.1 Focus UA . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2 Conference Factory URI . . . . . . . . . . . . . . . . . . 5 64 3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . . 6 65 3.4 Conference-Aware UA . . . . . . . . . . . . . . . . . . . 6 66 4. SIP Conferencing Primitives . . . . . . . . . . . . . . . . 6 67 4.1 Joining a Conference using the Conference URI - Dial In . 7 68 4.2 Adding a Participant by the Focus - Dial Out . . . . . . . 10 69 4.3 Manually Creating a Conference by Dialing into a 70 Conferencing Application . . . . . . . . . . . . . . . . . 13 71 4.4 Creating a Conference using Ad-Hoc SIP Methods . . . . . . 15 72 4.5 Requesting the Focus Add a New Resource to a Conference . 17 73 4.6 Adding a 3rd Party Using Conference URI . . . . . . . . . 19 74 4.7 Requesting Focus Refer a Participant into the Conference . 21 75 4.8 Adding a 3rd Party Using a Dialog Identifier . . . . . . . 23 76 4.9 Changing User Agents within a Conference . . . . . . . . . 25 77 4.10 Bringing a Point-to-Point Session into a Conference . . 26 78 4.11 Requesting the Focus Remove a Participant from a 79 Conference . . . . . . . . . . . . . . . . . . . . . . . 28 80 4.12 Deleting a conference . . . . . . . . . . . . . . . . . 30 81 4.13 Discovery of Conferencing Capabilities using OPTIONS . . 31 82 5. Appendix - Creating a Conference by a Conference-Unaware 83 UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 85 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 86 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 87 9. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 35 88 10. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 35 89 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 36 90 12. Changes since -01 . . . . . . . . . . . . . . . . . . . . . 36 91 13. Changes since -00 . . . . . . . . . . . . . . . . . . . . . 36 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 93 14.1 Normative References . . . . . . . . . . . . . . . . . . . 36 94 14.2 Informative References . . . . . . . . . . . . . . . . . . 37 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 96 Intellectual Property and Copyright Statements . . . . . . . 39 98 1. Introduction 100 This specification uses the concepts and definitions from the high 101 level requirements [10] and the SIP conferencing framework [11] 102 documents. 104 The approach described in this document implements key functions in 105 the conferencing framework using SIP primitives only. This allows 106 for conducting simple conferences with defined functionalities using 107 SIP mechanisms and conventions. Many other advanced functions can be 108 implemented using additional means but they are not in the scope of 109 this document. 111 This document presents the basic call control (dial-in and dial-out) 112 conferencing building blocks from the UA perspective. Possible 113 applications include ad-hoc conferences and scheduled conferences. 115 Note that a single conference can bridge participants having 116 different capabilities and who potentially have joined the conference 117 by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc). 119 The call control and dialog manipulation approach is based on the 120 multiparty framework [12] document. That document defines the basic 121 approach of service design adopted for SIP which includes: 123 - Definition of primitives, not services 124 - Signaling model independent 125 - Invoker oriented 126 - Primitives make full use of URIs 127 - Include authentication, authorization, logging, etc. policies 128 - Define graceful fallback to baseline SIP. 130 The use of opaque URIs and the ability to communicate call control 131 context information within a URI (as opposed to service-related 132 header fields), as discussed in RFC 3087 [13], is fundamental to this 133 approach. 135 Capabilities discovery is an important feature of SIP systems, and 136 conferencing systems can make use of such features. For a UA acting 137 as a focus in a conference, this specification defines the usage of 138 the 'isfocus' feature parameter. 140 2. Usage of the 'isfocus' Feature Parameter 142 2.1 General 144 The main design guidelines for the development of SIP extensions and 145 conventions for conferencing are to define the minimum number of 146 extensions and to have seamless backwards compatibility with 147 conference-unaware SIP UAs. The minimal requirement for SIP is being 148 able to express that a dialog is a part of a certain conference 149 referenced to by a URI. As a result of these extensions, it is 150 possible to do the following using SIP: 152 - Create a conference 153 - Join a conference 154 - Invite a user to a conference 155 - Expel a user by third party 156 - Discover if a URI is a conference URI 157 - Delete a conference 159 The approach taken is to use the feature parameter "isfocus" to 160 express that a SIP dialog belongs to a conference. The use of 161 feature parameters in Contact header fields to describe the 162 characteristics and capabilities of a UA is described in the User 163 Agent Capabilities [7] document which includes the definition of the 164 "isfocus" feature parameter. 166 2.2 Session Establishment 168 In session establishment, a focus MUST include the "isfocus" feature 169 parameter in the Contact header field unless the focus wishes to hide 170 the fact that it is a focus. To a participant, the feature parameter 171 will be associated with the remote target URI of the dialog. It is 172 an indication to a conference-aware UA that the resulting dialog 173 belongs to a conference identified by the URI in the Contact header 174 field and that the call control conventions defined in this document 175 can be applied. 177 The Conference URI MUST meet the requirements to be a GRUU (Globally 178 Routable User Agent URI) as detailed in [9] 180 2.3 Discovery 182 Currently the only met requirement is: given an opaque URI, being 183 able to recognize whether it belongs to a certain conference (i.e. 184 meaning that it is a conference URI) or not. This discovery function 185 can be implemented in SIP using an OPTIONS request, and can be done 186 either inside an active dialog or outside a dialog. A focus MUST 187 include the "isfocus" feature parameter in a 200 OK response to an 188 OPTIONS unless the focus wishes to hide the fact that it is a focus. 190 3. SIP User Agent Conferencing Capability Types 192 From a conferencing perspective, the framework document outlines a 193 number of possible different SIP components such as 194 conference-unaware participant, conference-aware participant, and 195 focus. 197 This document applies the concepts above to the SIP call control part 198 of the conferencing components. It defines normative behavior of the 199 SIP UAs in various conferencing situations (referred later as 200 "scenarios"). 202 3.1 Focus UA 204 A focus, as defined in the framework, hosts a SIP conference and 205 maintains a SIP signaling relationship with each participant in the 206 conference. A focus contains a conference-aware user agent that 207 supports the conferencing call control conventions as defined in this 208 document. 210 A focus SHOULD support the conference package [5] and indicate so in 211 Allow-Events header fields in requests and responses. A focus MAY 212 include information about the conference in SDP message bodies sent. 214 A focus SHOULD support the Replaces [8] header field. 216 A user agent with focus capabilities could be implemented in end user 217 equipment and would be used for the creation of ad-hoc conferences. 219 A dedicated conferencing server, whose primary task is to 220 simultaneously host conferences of arbitrary type and size, may 221 allocate and publish a conference factory URI (as defined in the next 222 section) for creating an arbitrary number of ad-hoc conferences (and 223 subsequently their focuses) using SIP call control means. 225 3.2 Conference Factory URI 227 According to the framework, there are many ways in which a conference 228 can be created. These are open to the conferencing server 229 implementation policy and include non-automated means (such as IVR), 230 SIP, and a conference policy control protocol. 232 In order to automatically create an arbitrary number of ad-hoc 233 conferences (and subsequently their focuses) using SIP call control 234 means, a globally routable Conference Factory URI can be allocated 235 and published. 237 A successful attempt to establish a call to this URI would result in 238 the automatic creation a new conference and its focus. As a result, 239 note that the Conference Factory URI and the newly created focus URI 240 MAY resolve to different physical devices. 242 A scenario showing the use of the conference factory URI is shown in 243 Section 4.4. 245 3.3 Conference-Unaware UA 247 The simplest user agent can participate in a conference ignoring all 248 SIP conferencing-related information. The simplest user agent is 249 able to dial into a conference and to be invited to a conference. 250 Any conferencing information is optionally conveyed to/from it using 251 non-SIP means. Such a user agent would not usually host a conference 252 (at least, not using SIP explicitly). A conference-unaware UA needs 253 only to support RFC 3261 [2]. Call flows for conference-unaware UAs 254 are not shown in general in this document as they would be identical 255 to those in the SIP call flows [15] document. 257 3.4 Conference-Aware UA 259 A conference-aware user agent supports SIP conferencing call control 260 conventions defined in this document as a conference participant, in 261 addition to support of RFC 3261. 263 A conference-aware UA MUST recognize the "isfocus" feature parameter. 264 A conference-aware UA SHOULD support REFER [3], SIP events [4], and 265 the conferencing package [5]. 267 A conference-aware UA SHOULD subscribe to the conference package if 268 the "isfocus" parameter is in the remote target URI of a dialog and 269 if the conference package is listed by a focus in an Allow-Events 270 header field. The SUBSCRIBE to the conference package should be sent 271 outside any INVITE-initiated dialog. A termination of the INVITE 272 dialog with a BYE does not necessarily terminate the SUBSCRIBE 273 dialog. 275 A conference-aware UA MAY render to the user any information about 276 the conference obtained from the SIP header fields and SDP fields 277 from the focus. 279 4. SIP Conferencing Primitives 281 The SIP conferencing call control flows presented in this section are 282 the call control building blocks for various SIP tight conferencing 283 applications as described in the conferencing requirements [10] and 284 framework [11] documents. The major design goal is that the same SIP 285 conferencing primitives would be used by user agents having different 286 conferencing capabilities and comprising different applications. 288 4.1 Joining a Conference using the Conference URI - Dial In 290 In this section a user knows the conference URI and "dials in" to 291 join this conference. 293 If the UA is the first participant of the conference to dial in, it 294 is likely that this INVITE will create the focus and hence the 295 conference. However, the conference URI must have been reserved 296 prior to its use. 298 If the conference is up and running already, the dialing-in 299 participant is joined to the conference by its focus. 301 To join an existing specific conference a UA SHOULD send an INVITE 302 with the Request-URI set to the conference URI. The focus MUST 303 include the "isfocus" feature parameter in the Contact header field 304 of the 200 OK response to the INVITE. 306 An example call flow for joining a conference is shown in Figure 1. 308 Alice Focus Bob Carol 309 | | | 310 | | Carol joins the conference | 311 | | | 312 | | INVITE sip:Conf-ID F1 | 313 | |<----------------------------------------| 314 | | 180 Ringing F2 | 315 | |---------------------------------------->| 316 | | 200 OK Contact:Conf-ID;isfocus F3 | 317 | |---------------------------------------->| 318 | | ACK F4 | 319 | |<----------------------------------------| 320 | | RTP | 321 | |<=======================================>| 322 | | SUBSCRIBE sip:Conf-ID F5 | 323 | |<----------------------------------------| 324 | | 200 OK F6 | 325 | |---------------------------------------->| 326 | | NOTIFY F7 | 327 | |---------------------------------------->| 328 | | 200 OK F8 | 329 | |<----------------------------------------| 331 Figure 1. A Participant Joins a Conference using the Conference URI. 333 F1 INVITE sip:3402934234@example.com SIP/2.0 334 Via: SIP/2.0/UDP client.chicago.example.com 335 ;branch=z9hG4bKhjhs8ass83 336 Max-Forwards: 70 337 To: 338 From: Carol ;tag=32331 339 Call-ID: d432fa84b4c76e66710 340 CSeq: 45 INVITE 341 Contact: 342 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 343 SUBSCRIBE, NOTIFY 344 Allow-Events: dialog 345 Accept: application/sdp, message/sipfrag 346 Supported: conf, replaces 347 Content-Type: application/sdp 348 Content-Length: 274 350 (SDP not shown) 352 F3 SIP/2.0 200 OK 353 Via: SIP/2.0/UDP client.chicago.example.com 354 ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 355 To: ;tag=733413 356 From: Carol ;tag=32331 357 Call-ID: d432fa84b4c76e66710 358 CSeq: 45 INVITE 359 Contact: ;isfocus 360 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 361 SUBSCRIBE, NOTIFY 362 Allow-Events: dialog, conference 363 Accept: application/sdp, application/conference-info+xml, 364 message/sipfrag 365 Supported: replaces, join, gruu 366 Content-Type: application/sdp 367 Content-Length: 274 369 v=0 370 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com 371 s=Example Subject 372 i=Example Conference Hosted by Example.com 373 u=http://conf.example.com/3402934234 374 e=3402934234@conf-help.example.com 375 p=+1-888-2934234 376 c=IN IP4 ms5.conf.example.com 377 t=0 0 378 m=audio 49170 RTP/AVP 0 379 m=video 51372 RTP/AVP 31 381 F5 SUBSCRIBE sip:3402934234@example.com SIP/2.0 382 Via: SIP/2.0/UDP client.chicago.example.com 383 ;branch=z9hG4bKdf334 384 Max-Forwards: 70 385 To: 386 From: Carol ;tag=43524545 387 Call-ID: k3l43id034ksereree 388 CSeq: 22 SUBSCRIBE 389 Contact: 390 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 391 SUBSCRIBE, NOTIFY 392 Event: conference 393 Accept: application/sdp, message/sipfrag 394 Supported: conf, replaces 395 Content-Length: 0 397 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 398 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 399 Max-Forwards: 70 400 To: Carol ;tag=43524545 401 From: ;tag=a3343df32 402 Call-ID: k3l43id034ksereree 403 CSeq: 34321 NOTIFY 404 Contact: ;isfocus 405 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 406 SUBSCRIBE, NOTIFY 407 Event: conference 408 Accept: application/sdp, message/sipfrag 409 Subscription-State: active;expires=3600 410 Supported: replaces, join, gruu 411 Content-Type: application/conference-info+xml 412 Content-Length: ... 414 416 417 418 419 tel:+18882934234 420 421 422 423 424 Carol 425 426 connected 427 dialed-in 428 429 Main Audio 430 audio 431 583398 432 active 433 434 435 video 436 345212 437 active 438 439 440 441 443 4.2 Adding a Participant by the Focus - Dial Out 445 To directly add a participant to a conference, a focus SHOULD send an 446 INVITE to the participant containing a Contact header field with the 447 conference URI and the "isfocus" feature parameter. 449 Note that a conference-unaware UA would simply ignore the 450 conferencing information and treat the session (from a SIP 451 perspective) as a point to point session. 453 An example call flow is shown in Figure 2. It is assumed that Alice 454 is already a participant of the conference. The focus invites Carol 455 to the conference by sending an INVITE. After the session is 456 established, Carol subscribes to the conference URI. It is important 457 to note that there is no dependency on Carol's SUBSCRIBE (F5) and the 458 NOTIFY to Alice (F9) - they occur asynchronously and independently. 460 Alice Focus Bob Carol 461 | | | | 462 |<==================>| | | 463 | | | 464 | Focus "dials out" to add Carol to the conference | 465 | | | 466 | | INVITE Contact:Conf-ID;isfocus F1 | 467 | |---------------------------------------->| 468 | | 180 Ringing F2 | 469 | |<----------------------------------------| 470 | | 200 OK F3 | 471 | |<----------------------------------------| 472 | | ACK F4 | 473 | |---------------------------------------->| 474 | | RTP | 475 | |<=======================================>| 476 | | SUBSCRIBE sip:Conf-ID F5 | 477 | |<----------------------------------------| 478 | | 200 OK F6 | 479 | |---------------------------------------->| 480 | | NOTIFY F7 | 481 | |---------------------------------------->| 482 | | 200 OK F8 | 483 | |<----------------------------------------| 484 | NOTIFY F9 | | 485 |<-------------------| | 486 | 200 OK F10 | | 487 |------------------->| | 489 Figure 2. A Focus "dials out" to Add a Participant to the Conference. 491 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 492 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 493 Max-Forwards: 70 494 To: Carol ;tag=43524545 495 From: ;tag=a3343df32 496 Call-ID: k3l43id034ksereree 497 CSeq: 34321 NOTIFY 498 Contact: ;isfocus 499 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 500 SUBSCRIBE, NOTIFY 501 Event: conference 502 Accept: application/sdp, message/sipfrag 503 Subscription-State: active;expires=3600 504 Supported: replaces, gruu 505 Content-Type: application/conference-info+xml 506 Content-Length: ... 508 510 511 512 513 tel:+18882934234 514 515 516 517 518 Alice 519 520 connected 521 dialed-in 522 523 Main Audio 524 audio 525 647231 526 active 527 528 529 video 530 21345 531 active 532 533 534 535 536 Carol 537 538 connected 539 dialed-out 540 541 Main Audio 542 audio 543 583398 544 active 545 546 547 video 548 345212 549 active 550 551 552 553 555 F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 556 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 557 Max-Forwards: 70 558 To: Alice ;tag=43524545 559 From: ;tag=a3343df32 560 Call-ID: 8820450524545 561 CSeq: 998 NOTIFY 562 Contact: ;isfocus 563 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 564 SUBSCRIBE, NOTIFY 565 Event: conference 566 Accept: application/sdp, message/sipfrag 567 Subscription-State: active;expires=2450 568 Supported: replaces, gruu 569 Content-Type: application/conference-info+xml 570 Content-Length: ... 572 574 575 Carol 576 577 connected 578 dialed-out 579 580 Main Audio 581 audio 582 583398 583 active 584 585 586 video 587 345212 588 active 589 590 591 592 594 4.3 Manually Creating a Conference by Dialing into a Conferencing 595 Application 597 In this section, a user sends an INVITE to a conference server 598 application. The application (such as an IVR system or a web page) 599 is implemented because the system requires additional input from the 600 user before it is able to create a conference. After a normal dialog 601 is established, additional information is received and the conference 602 together with its focus are created. At this point the conference 603 server MUST re-INVITE the user with the conference URI in Contact 604 with the "isfocus" feature parameter. 606 Alternatively, the additional information MAY be provided by the user 607 during an early dialog established. This could be accomplished by a 608 183 Session Progress response sent by the conferencing application. 609 After the conference is created, the conference URI MUST then be 610 returned in a Contact in the 200 OK. 612 An example call flow is shown in Figure 3. In this example, Alice 613 uses a conference application which is triggered when Alice sends an 614 INVITE to the conference application. In this example, Conf-App is 615 used to represent the conference application URI. Alice's 616 conference-aware UA learns of the existence of the conference from 617 the "isfocus" feature parameter and subscribes to the conference 618 package to receive notifications of the conference state. 620 Alice Focus Bob Carol 621 | | | | 622 | Alice establishes session with conference application. | 623 | | | | 624 | INVITE sip:Conf-App F1 | | 625 |------------------->| | | 626 | 180 Ringing F2 | | | 627 |<-------------------| | | 628 | 200 OK F3 | | | 629 |<-------------------| | | 630 | ACK F4 | | | 631 |------------------->| | | 632 | RTP | | | 633 |<==================>| | | 634 | | | | 635 | Alice uses the application to create the conference. | 636 | | | | 637 | INVITE Contact:Conf-ID;isfocus F5 | | 638 |<-------------------| | | 639 | 200 OK F6 | | | 640 |------------------->| | | 641 | ACK F7 | | | 642 |<-------------------| | | 643 | RTP | | | 644 |<==================>| | | 645 | | | | 646 | SUBSCRIBE sip:Conf-ID F8 | | 647 |------------------->| | | 648 | 200 OK F9 | | | 649 |<-------------------| | | 650 | NOTIFY F10 | | | 651 |<-------------------| | | 652 | 200 OK F11 | | | 653 |------------------->| | | 655 Figure 3. A Participant Creates a Conference using an Application. 657 4.4 Creating a Conference using Ad-Hoc SIP Methods 659 This section addresses creating a conference by using ad-hoc SIP 660 means. The conference factory URI (as defined in Section 3.2) is 661 used to automatically create the conference in this example. 663 The benefit of this approach is that the conference URI need not be 664 known to the user - instead it is created by a focus and used by the 665 participants' UAs. The main difference between this scenario and 666 Section 4.3 is that no user intervention (IVR, web page form, etc.) 667 is required to create the conference. 669 The SIP URI of the conference factory can be provisioned in the UA 670 (as in a "create new conference" button on a SIP phone) or can be 671 discovered using other means. 673 A SIP entity (such as conferencing server) can distinguish this 674 INVITE request as a request to create a new ad-hoc conference from a 675 request to join an existing conference by the Request-URI. 677 Assuming that all security and policy requirements have been met, a 678 new conference will be created with the Contact URI returned in the 679 200 OK being the conference URI. The Contact header field MUST 680 contain the "isfocus" feature parameter to indicate that this URI is 681 for a conference. 683 An example call flow is shown in Figure 4. Note that Conf-Factory is 684 shorthand for the conference factory URI and Conf-ID Is short for the 685 conference URI. In this flow, Alice has a conference-aware UA and 686 creates a conference by sending an INVITE to the conference factory 687 URI. The conference factory application creates the conference and 688 redirects using a 302 Moved Temporarily response to the focus. Note 689 that with proxy recursion, Alice may never see the redirect but may 690 just receive the responses from the focus starting with message F5. 691 Once the media session is established, Alice subscribes to the 692 conference URI obtained through the Contact in the 200 OK response 693 from the focus. 695 Alice Conf-Factory App Focus Bob 696 | | | | 697 | Alice creates the conference. | | 698 | | | | 699 | INVITE sip:Conf-Factory F1 | | 700 |------------------->| | | 701 | 302 Moved Contact:Conf-ID;isfocus F2 | | 702 |<-------------------| | | 703 | ACK F3 | | | 704 |------------------->| | | 705 | INVITE sip:Conf-ID F4 | | 706 |---------------------------------------->| | 707 | 180 Ringing F5 | | 708 |<----------------------------------------| | 709 | 200 OK Contact:Conf-ID;isfocus F6 | | 710 |<----------------------------------------| | 711 | ACK F7 | | 712 |---------------------------------------->| | 713 | RTP | | 714 |<=======================================>| | 715 | | | 716 | Alice subscribes to the conference URI. | | 717 | | | 718 | SUBSCRIBE sip:Conf-ID F8 | | 719 |---------------------------------------->| | 720 | 200 OK F9 | | 721 |<----------------------------------------| | 722 | NOTIFY F10 | | 723 |<----------------------------------------| | 724 | 200 OK F11 | | 725 |---------------------------------------->| | 727 Figure 4. Creation of a Conference using SIP Ad-Hoc Methods. 729 4.5 Requesting the Focus Add a New Resource to a Conference 731 A SIP conference URI can be used to inject different kinds of 732 information into the conference. Examples include new participants, 733 new real-time media sources, new IM messages, and pointers to passive 734 information references (such as HTTP URIs). 736 To request the focus add a new information resource to the specified 737 conference, any SIP UA can send a REFER to the conference URI with a 738 Refer-To containing the URI of the new resource. Since this REFER is 739 sent to the conference URI and not the conference factory URI, the 740 semantics to the focus are to bring the resource into the conference 741 and make it visible to the conference participants. The resultant 742 focus procedures are dependant both on the nature of the new resource 743 (as expressed by its URI) and the own focus policies regarding IM, 744 central vs. distributed real time media processing, etc. 746 The scenario for adding a new UA participant is important to support 747 because it works even if the new participant does not support REFER 748 and transfer call control - only the requesting participant and the 749 focus need to support the REFER and transfer call control. 751 Upon receipt of the REFER containing a Refer-To header with a SIP 752 URI, the focus SHOULD send an INVITE to the new participant 753 identified by the Refer-To SIP URI containing a Contact header field 754 with the conference URI and the "isfocus" feature parameter. 756 A conference-unaware UA would simply ignore the conferencing 757 information and treat the session (from a SIP perspective) as a point 758 to point session. 760 An example call flow is shown in Figure 5. It is assumed that Alice 761 is already a participant of the conference. Alice sends a REFER to 762 the conference URI. The focus invites Carol to the conference by 763 sending an INVITE. After the session is established, Carol 764 subscribes to the conference URI. It is important to note that there 765 is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to Alice 766 (F15) - they occur asynchronously and independently. 768 Alice Focus Bob Carol 769 | | | | 770 |<==================>| | | 771 | REFER sip:Conf-ID Refer-To:Carol F1 | | 772 |------------------->| | 773 | 202 Accepted F2 | | 774 |<-------------------| | 775 | NOTIFY (Trying) F3 | 776 |<-------------------| | 777 | 200 OK F4 | | 778 |------------------->| | 779 | | | 780 | Focus "dials out" to join Carol to the conference | 781 | | | 782 | | INVITE Contact:Conf-ID;isfocus F5 | 783 | |---------------------------------------->| 784 | | 180 Ringing F6 | 785 | |<----------------------------------------| 786 | | 200 OK F7 | 787 | |<----------------------------------------| 788 | | ACK F8 | 789 | |---------------------------------------->| 790 | | RTP | 791 | |<=======================================>| 792 | NOTIFY (OK) F9 | | 793 |<-------------------| | 794 | 200 OK F10 | | 795 |------------------->| | 796 | | SUBSCRIBE sip:Conf-ID F11 | 797 | |<----------------------------------------| 798 | | 200 OK F12 | 799 | |---------------------------------------->| 800 | | NOTIFY F13 | 801 | |---------------------------------------->| 802 | | 200 OK F14 | 803 | |<----------------------------------------| 804 | NOTIFY F15 | | 805 |<-------------------| | 806 | 200 OK F16 | | 807 |------------------->| | 809 Figure 5. Participant Requests Focus add a Participant to the Conference. 811 F1 REFER sip:3402934234@example.com SIP/2.0 812 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 813 Max-Forwards: 70 814 To: 815 From: Alice ;tag=5534562 816 Call-ID: 849392fklgl43 817 CSeq: 476 REFER 818 Contact: 819 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 820 SUBSCRIBE, NOTIFY 821 Accept: application/sdp, message/sipfrag 822 Refer-To: 823 Supported: replaces 824 Content-Length: 0 826 4.6 Adding a 3rd Party Using Conference URI 828 A participant wishing to add a new participant will request this 829 participant to send an INVITE to the conference URI. This can be 830 done using a non-SIP means (such as passing or publishing the 831 conference URI in an email, IM, or web page). If a non-SIP means is 832 used, then the flow and requirements are identical to Section 4.1. 834 The SIP mechanism to do this utilizes the REFER method. 836 A UA wishing to add a new participant SHOULD send a REFER request to 837 the participant with a Refer-To header containing the conference URI. 839 The requirements are then identical to the "dial in" case of Section 840 4.1. The inviting participant MAY receive notification through the 841 REFER action that the new participant has been added in addition to 842 the notification received through the conference package. 844 An example is shown in Figure 6. In this call flow, it is assumed 845 that Alice is already a participant of the conference. Alice sends 846 Bob an "out of band" REFER - that is, a REFER outside of an 847 established dialog. Should Bob reject the REFER, Alice might try 848 sending an INVITE to Bob to establish a session first, then send a 849 REFER within the dialog, effectively transferring Bob into the 850 conference [17]. 852 Alice Focus Bob Carol 853 | | | | 854 |<==================>| | | 855 | | | | 856 | Alice adds Bob into conference | | 857 | | | | 858 | REFER Refer-To:Conf-ID F1 | | 859 |---------------------------------------->| | 860 | 202 Accepted F2 | | | 861 |<----------------------------------------| | 862 | NOTIFY (Trying) F3| | | 863 |<----------------------------------------| | 864 | 200 OK F4 | | | 865 |---------------------------------------->| | 866 | | INVITE sip:Conf-ID F5 | 867 | |<-------------------| | 868 | | 180 Ringing F6 | | 869 | |------------------->| | 870 | | 200 OK Contact:Conf-ID;isfocus F7 | 871 | |------------------->| | 872 | | ACK F8 | | 873 | |<-------------------| | 874 | | RTP | | 875 | |<==================>| | 876 | NOTIFY (OK) F9 | | | 877 |<----------------------------------------| | 878 | 200 OK F10 | | | 879 |---------------------------------------->| | 880 | NOTIFY F11 | | | 881 |<-------------------| | | 882 | 200 OK F12 | | | 883 |------------------->| | | 884 | | SUBSCRIBE sip:Conf-ID F13 | 885 | |<-------------------| | 886 | | 200 OK F14 | | 887 | |------------------->| | 888 | | NOTIFY F15 | | 889 | |------------------->| | 890 | | 200 OK F16 | | 891 | |<-------------------| | 893 Figure 6. Adding a Participant to an Existing Conference. 895 4.7 Requesting Focus Refer a Participant into the Conference 897 A participant may request the focus refer a participant into the 898 conference by sending a REFER method. The Refer-To header field will 899 have the method set to REFER and an escaped Refer-To header field 900 containing the conference URI. 902 Note that in Message F1 below, the Refer-To header field is shown as 903 continuing across two lines - this would not be the case in an actual 904 message, the URI would have continued beyond the formatting 905 limitations of this document. 907 This scenario is shown in Figure 7. 909 Alice Focus Bob Carol 910 | | | | 911 |<==================>| | | 912 | | | | 913 | Alice asks focus to REFER Bob into conference | 914 | | | | 915 | REFER sip:Conf-ID Refer-To:Bob?method=REFER&Refer-To=Conf-ID F1 916 |------------------->| | | 917 | 202 Accepted F2 | | | 918 |<-------------------| | | 919 | NOTIFY (Trying) F3| | | 920 |<-------------------| | | 921 | 200 OK F4 | | | 922 |------------------->| | | 923 | | | | 924 | Focus REFERs Bob to the conference | 925 | | | | 926 | | REFER Refer-To:Conf-ID F5 | 927 | |------------------->| | 928 | | 202 Accepted F6 | | 929 | NOTIFY (202) F7 |<-------------------| | 930 |<-------------------| NOTIFY (Trying) F8 | | 931 | 200 OK F9 |<-------------------| | 932 |------------------->| 200 OK F10 | | 933 | |------------------->| | 934 | | INVITE sip:Conf-ID F11 | 935 | |<-------------------| | 936 | | 180 Ringing F12 | | 937 | |------------------->| | 938 | | 200 OK Contact:Conf-ID;isfocus F13 | 939 | |------------------->| | 940 | | ACK F14 | | 941 | NOTIFY F15 |<-------------------| | 942 |<-------------------| RTP | | 943 | 200 OK F16 |<==================>| | 944 |------------------->| NOTIFY (200) F17 | | 945 | |<-------------------| | 946 | | 200 OK F18 | | 947 | |------------------->| | 948 | | SUBSCRIBE sip:Conf-ID F17 | 949 | |<-------------------| | 950 | | 200 OK F19 | | 951 | |------------------->| | 952 | | NOTIFY F20 | | 953 | |------------------->| | 954 | | 200 OK F21 | | 955 | |<-------------------| | 957 Figure 7. Requesting a Focus Refer a Participant to a Conference. 959 F1 REFER sip:3402934234@example.com SIP/2.0 960 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 961 Max-Forwards: 70 962 To: 963 From: Alice ;tag=5534562 964 Call-ID: 849392fklgl43 965 CSeq: 476 REFER 966 Contact: 967 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 968 SUBSCRIBE, NOTIFY 969 Accept: application/sdp, message/sipfrag 970 Refer-To: 972 Supported: conf, replaces 973 Content-Length: 0 975 F5 REFER sip:3402934234@example.com SIP/2.0 976 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243 977 Max-Forwards: 70 978 To: 979 From: ;tag=345621412 980 Call-ID: 5494204 981 CSeq: 4524323 REFER 982 Contact: ;isfocus 983 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 984 SUBSCRIBE, NOTIFY 985 Accept: application/sdp, message/sipfrag 986 Refer-To: 987 Supported: join, gruu, replaces 988 Content-Length: 0 990 F11 INVITE sip:3402934234@example.com SIP/2.0 991 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887 992 Max-Forwards: 70 993 To: 994 From: Bob ;tag=32411 995 Call-ID: 5d4324fa84b4c76e66710 996 CSeq: 764 INVITE 997 Contact: 998 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 999 SUBSCRIBE, NOTIFY 1000 Allow-Events: dialog 1001 Accept: application/sdp, message/sipfrag 1002 Supported: replaces, join 1003 Content-Type: application/sdp 1004 Content-Length: 274 1006 (SDP not shown) 1008 4.8 Adding a 3rd Party Using a Dialog Identifier 1010 Under some circumstances, a participant wanting to join a conference 1011 may only know a dialog identifier of one of the legs of the 1012 conference. The information may have been learned using the dialog 1013 package [18] or some non-SIP means to retrieve this information from 1014 a conference participant. 1016 A UA can request to be added to a conference by sending a request to 1017 the focus containing a Join [6] header field containing a dialog ID 1018 of one leg of the conference (a dialog between a participant and the 1019 focus). 1021 There are other scenarios in which a UA can use the Join header for 1022 certain conferencing call control scenarios. See [6] for further 1023 examples and details. 1025 An example is shown in Figure 8. It is assumed that Alice is a 1026 participant of the conference. The dialog identifier between Alice 1027 and the focus is abbreviated as A-F and is known by Bob. Bob 1028 requests to be added to the conference by sending an INVITE message 1029 F1 to the focus containing a Join header which contains the dialog 1030 identifier A-F. Bob is added into the conference by the focus. 1032 Alice Focus Bob Carol 1033 | | | | 1034 |<==================>| | | 1035 | | | | 1036 | Bob requests to be added to the conference. | 1037 | | | | 1038 | | INVITE Join:A-F F1| | 1039 | |<-------------------| | 1040 | | 180 Ringing F2 | | 1041 | |------------------->| | 1042 | | 200 OK Contact:Conf-ID;isfocus F3 | 1043 | |------------------->| | 1044 | | ACK F4 | | 1045 | |<-------------------| | 1046 | | RTP | | 1047 | NOTIFY F5 |<==================>| | 1048 |<-------------------| SUBSCRIBE sip:Conf-ID F6 | 1049 | 200 OK F7 |<-------------------| | 1050 |------------------->| 200 OK F8 | | 1051 | |------------------->| | 1052 | | NOTIFY F9 | | 1053 | |------------------->| | 1054 | | 200 OK F10 | | 1055 | |<-------------------| | 1057 Figure 8. Adding a Participant to an Existing Conference using Join. 1059 F1 INVITE sip:3402934234@example.com SIP/2.0 1060 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832 1061 Max-Forwards: 70 1062 To: 1063 From: Bob ;tag=32411 1064 Call-ID: d432fa84b4c76e66710 1065 CSeq: 8 INVITE 1066 Contact: 1067 Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331 1068 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1069 SUBSCRIBE, NOTIFY 1070 Allow-Events: dialog 1071 Accept: application/sdp, message/sipfrag 1072 Supported: replaces, join 1073 Content-Type: application/sdp 1074 Content-Length: 274 1076 (SDP not shown) 1078 4.9 Changing User Agents within a Conference 1080 A participant in a conference may want to change the user agent with 1081 which they participate in the conference. While this could be done 1082 by simply sending a BYE from one user agent to leave the conference 1083 and an INVITE from the other user agent to rejoin. However, the SIP 1084 Replaces [6] primitive is perfectly suited to this operation. 1086 An example is shown in Figure 9. It is assumed that Alice is a 1087 participant of the conference using user agent #1. The dialog 1088 identifier between Alice's user agent #1 and the focus is abbreviated 1089 as A-F. Alice switches to user agent #2 and sends an INVITE message 1090 F1 to the focus containing a Replaces header which contains the 1091 dialog identifier A-F. Note that this dialog identifier could be 1092 learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY 1093 and the dialog event package [18]. Alice's user agent #2 is added 1094 into the conference by the focus. The focus sends a BYE to user 1095 agent #1. User agent #1 then automatically terminates the 1096 subscription by sending a SUBSCRIBE with Expires:0 to terminate the 1097 subscription. Note that as the participant list (roster) has not 1098 changed during this scenario. 1100 Alice UA#1 Focus Alice UA#2 Carol 1101 | | | | 1102 |<==================>| | | 1103 | | | | 1104 | Alice switches user agents during the conference. | 1105 | | | | 1106 | | INVITE sip:Conf-ID Replaces:A-F F1 | 1107 | |<-------------------| | 1108 | | 200 OK Contact:Conf-ID;isfocus F2 | 1109 | |------------------->| | 1110 | | ACK F3 | | 1111 | |<-------------------| | 1112 | | RTP | | 1113 | |<==================>| | 1114 | BYE F4 | | | 1115 |<-------------------| | | 1116 | 200 OK F5 | | | 1117 |------------------->| | | 1118 | SUBSCRIBE Expires:0 F6 | | 1119 |------------------->| | | 1120 | 200 OK F7 | | | 1121 |<-------------------| | | 1122 | NOTIFY Subscription-State:terminated F8 | | 1123 |<-------------------| | | 1124 | 200 OK F9 | | | 1125 |------------------->| | | 1126 | | SUBSCRIBE sip:Conf-ID F10 | 1127 | |<-------------------| | 1128 | | 200 OK F11 | | 1129 | |------------------->| | 1130 | | NOTIFY F12 | | 1131 | |------------------->| | 1132 | | 200 OK F13 | | 1133 | |<-------------------| | 1135 Figure 9. Adding a Participant to an Existing Conference using Join. 1137 4.10 Bringing a Point-to-Point Session into a Conference 1139 This call flow shows how a point to point call can be switched to a 1140 conference call involving an external focus. 1142 Alice and Bob have an established session with a dialog identifier 1143 A-B. Alice joins the conference with the focus by sending an INVITE 1144 to the Conference URI. Alice then sends a REFER to the focus and 1145 includes an escaped Replaces header field in the Refer-To header 1146 field. Bob receives the INVITE from the focus, matches the dialog in 1147 the Replaces header field with the dialog with Alice. As a result, 1148 Bob accepts the INVITE, joins the conference, and sends a BYE to 1149 Alice to tear down their point to point dialog. 1151 Alice Focus Bob Carol 1152 | | | | 1153 | Alice is in a session with Bob | | 1154 |<=======================================>| | 1155 | | | | 1156 | Alice joins the conference | | 1157 | | | | 1158 | INVITE sip:Conf-ID F1 | | 1159 |------------------->| | | 1160 | 200 OK Contact:sip:Conf-ID F2 | | 1161 |<-------------------| | | 1162 | ACK F3 | | | 1163 |------------------->| | | 1164 |<==================>| | | 1165 | | | | 1166 | Alice asks focus to REFER Bob into conference | 1167 | | | | 1168 | REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F4 | 1169 |------------------->| | | 1170 | 202 Accepted F5 | | | 1171 |<-------------------| | | 1172 | NOTIFY (Trying) F6| | | 1173 |<-------------------| | | 1174 | 200 OK F7 | | | 1175 |------------------->| | | 1176 | | | | 1177 | Focus invites Bob to the conference | 1178 | | | | 1179 | | INVITE sip:Conf-ID Replaces:A-B F8 | 1180 | |------------------->| | 1181 | | 200 OK F9 | | 1182 | |<-------------------| | 1183 | | ACK F10 | | 1184 | |------------------->| | 1185 | | RTP | | 1186 | |<==================>| | 1187 | BYE F11 | | 1188 |<----------------------------------------| | 1189 | 200 OK F12 | | 1190 |---------------------------------------->| | 1191 | NOTIFY (200) F13 | | | 1192 |<-------------------| | | 1193 | 200 OK F14 | | | 1194 |------------------->| | | 1195 | NOTIFY F15 | | | 1196 |<-------------------| | | 1197 | 200 OK F16 | | | 1198 |------------------->| | | 1199 | | SUBSCRIBE sip:Conf-ID F17 | 1200 | |<-------------------| | 1201 | | 200 OK F18 | | 1202 | |------------------->| | 1203 | | NOTIFY F19 | | 1204 | |------------------->| | 1205 | | 200 OK F20 | | 1206 | |<-------------------| | 1207 | | | | 1209 Figure 10. Transitioning a Point to Point Session into a Conference. 1211 4.11 Requesting the Focus Remove a Participant from a Conference 1213 To request the focus remove a participant from the specified 1214 conference, a properly authorized SIP UA (typically the conference 1215 owner) can send a REFER to the conference URI with a Refer-To 1216 containing the URI of the participant and with the method set to BYE. 1217 The requestor does not need to know the dialog information about the 1218 dialog between the focus and the participant who will be removed - 1219 the focus knows this information and fills it when it generates the 1220 BYE request. 1222 An example call flow is shown in Figure 11. It is assumed that Alice 1223 and Carol are already participants of the conference and that Alice 1224 is authorized to remove members from the conference. Alice sends a 1225 REFER to the conference URI with a Refer-To header containing a URI 1226 of the form <sip:carol@chicago.example.com?method=BYE>. 1228 Alice Focus Bob Carol 1229 | | | | 1230 |<==================>| | 1231 | REFER sip:Conf-ID Refer-To:Carol?method=BYE F1 | 1232 |------------------->| | 1233 | 202 Accepted F2 | | 1234 |<-------------------| | 1235 | NOTIFY (Trying) F3 | 1236 |<-------------------| | 1237 | 200 OK F4 | | 1238 |------------------->| | 1239 | | | 1240 | Focus removes Carol from the conference | 1241 | | | 1242 | | BYE sip:Carol F5 | 1243 | |---------------------------------------->| 1244 | | 200 OK F6 | 1245 | |<----------------------------------------| 1246 | | NOTIFY Subscription-State:terminated F7 | 1247 | |---------------------------------------->| 1248 | | 200 OK F8 | 1249 | |<----------------------------------------| 1250 | NOTIFY (200) F9 | | 1251 |<-------------------| | 1252 | 200 OK F10 | | 1253 |------------------->| | 1254 | NOTIFY F11 | | 1255 |<-------------------| | 1256 | 200 OK F12 | | 1257 |------------------->| | 1259 Figure 11. Participant Requests Focus Remove a Participant from the Conference. 1261 F1 REFER sip:3402934234@example.com SIP/2.0 1262 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 1263 Max-Forwards: 70 1264 To: 1265 From: Alice ;tag=5534562 1266 Call-ID: 849392fklgl43 1267 CSeq: 476 REFER 1268 Contact: 1269 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1270 SUBSCRIBE, NOTIFY 1271 Accept: application/sdp, message/sipfrag 1272 Refer-To: 1273 Supported: replaces 1274 Content-Length: 0 1276 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 1277 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 1278 Max-Forwards: 70 1279 From: ;tag=5393k2312 1280 To: Carol ;tag=32331 1281 Call-ID: d432fa84b4c76e66710 1282 CSeq: 78654 BYE 1283 Content-Length: 0 1285 4.12 Deleting a conference 1287 A conference created using the Conference Factory URI is 1288 automatically deleted when the creator of the conference leaves the 1289 conference by sending a BYE. 1291 If the focus allows the conference policy to be manipulated, it is 1292 possible for the conference to continue after the creator departs if 1293 the policy is changed. However, the default conference policy for 1294 conferences created using the Conference Factory URI is that the 1295 conference is deleted when the creator departs. 1297 Figure 12 shows this call flow in which the creator Alice departs 1298 causing the conference to be deleted. Note that the order of sending 1299 BYEs and final NOTIFYs is not important. 1301 Alice Focus Bob Carol 1302 | | | | 1303 |<==================>|<==================>| | 1304 | BYE F1 |<=======================================>| 1305 |------------------->| | | 1306 | 200 OK F2 | | | 1307 |<-------------------| | | 1308 | | BYE F3 | | 1309 | |------------------->| | 1310 | | 200 OK F4 | | 1311 | |------------------->| | 1312 | | BYE F5 | 1313 | |---------------------------------------->| 1314 | | 200 OK F6 | 1315 | |<----------------------------------------| 1316 | NOTIFY Subscription-State:terminated F7 | 1317 |<-------------------| | | 1318 | 200 OK F8 | | | 1319 |------------------->| NOTIFY Subscription-State:terminated F9 1320 | |------------------->| | 1321 | | 200 OK F10 | | 1322 | |<-------------------| | 1323 | | NOTIFY Subscription-State:terminated F11 1324 | |---------------------------------------->| 1325 | | 200 OK F12 | 1326 | |<----------------------------------------| 1328 Figure 12. Deleting a Conference 1330 4.13 Discovery of Conferencing Capabilities using OPTIONS 1332 A UA MAY send an OPTIONS request to discover if an opaque URI is a 1333 conference URI (resolves to a focus). In addition, the reply to the 1334 OPTIONS request can also indicate support for various SIP call 1335 control extensions used in this document. 1337 Note that the Allow, Accept, Allow-Events, and Supported header 1338 fields should be present in an INVITE from a focus or a 200 OK answer 1339 from the focus to an INVITE as a part of a normal dialog 1340 establishment process. 1342 An example is shown in Figure 13 where Alice sends an OPTIONS to a 1343 URI which resolves to a focus. 1345 Alice Focus Bob Carol 1346 | | | | 1347 | OPTIONS sip:Conf-ID F1 | | 1348 |------------------->| | | 1349 | 200 OK Contact:Conf-ID;isfocus F2 | | 1350 |<-------------------| | | 1352 Figure 13. Participant Queries Capabilities of URI which resolves to a Focus. 1354 Following is an example message detail of message F2 in Figure 13. 1355 Based on the response, Alice's UA learns that the URI is a conference 1356 URI and that the responding UA is focus that supports a number of SIP 1357 call control extensions. 1359 The response details are as follows: 1361 F2 SIP/2.0 200 OK 1362 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjhs8ass877 1363 ;received=192.0.2.4 1364 To: ;tag=93810874 1365 From: Alice ;tag=1928301774 1366 Call-ID: a84b4c76e66710 1367 CSeq: 63104 OPTIONS 1368 Contact: ;isfocus 1369 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1370 SUBSCRIBE, NOTIFY 1371 Allow-Events: refer, conference 1372 Accept: application/sdp, application/conference-info+xml, 1373 message/sipfrag 1374 Accept-Language: en 1375 Supported: replaces, join, gruu 1376 Content-Type: application/sdp 1377 Content-Length: ... 1379 v=0 1380 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com 1381 s=Example Subject 1382 i=Example Conference Hosted by Example.com 1383 u=http://conf.example.com/3402934234 1384 e=3402934234@conf-help.example.com 1385 p=+18882934234 1386 c=IN IP4 ms5.conf.example.com 1387 t=0 0 1388 m=audio 49170 RTP/AVP 0 1 3 5 7 1389 m=video 51372 RTP/AVP 31 32 1391 Useful information from each of these headers is detailed in the next 1392 sections. 1394 Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY 1395 indicate that the user agent supports call control and SIP Events. 1397 Accept. The support of bodies such as message/sipfrag [14], 1398 application/conference-info+xml [5] also indicates support of call 1399 control and conferencing. 1401 Allow-Events. The support of event packages such as refer [3], 1402 conference [5]. 1404 Supported. The support of extensions such as replaces, join, and 1405 gruu. 1407 Contact. The presence of the "isfocus" feature parameter in the 1408 Contact header indicates that the URI is a conference URI and that 1409 the UA is a focus. 1411 5. Appendix - Creating a Conference by a Conference-Unaware UA 1413 This section discusses how a human user operating a 1414 conference-unaware UA can create and add participants to a 1415 conference. This method is described as an appendix since it is NOT 1416 RECOMMENDED. The scenarios involving creating a conference using 1417 ad-hoc or manual means are recommended over this scenario. This 1418 scenario is included, however, for completeness. 1420 A user (human) would choose a conference URI according to system 1421 rules and insert it into the Request-URI of the INVITE. This same 1422 URI is echoed by a focus adhering to certain addressing conventions 1423 (discussed below) in the Contact header by the focus. Additional 1424 participants could be added by non-SIP means (publication of the 1425 chosen conference URI using web pages, email, IM, etc.). 1426 Alternatively, the conference-unaware UA could then add other 1427 participants to the conference using SIP call control by establishing 1428 a session with them, then transferring [17] them to the conference 1429 URI. Note that in this scenario only the user (human) is aware of 1430 the conferencing application, and the conference-unaware UA only need 1431 support RFC 3261 and optionally call transfer. 1433 Making this work does impose certain addressing conventions on a 1434 system. As a service/implementation choice, a system could allow the 1435 creator of the conference to choose the user portion of the 1436 conference URI. However, this requires the URI format to be agreed 1437 upon between a user and the system. 1439 For example, a service provider might reserve the domain 1440 conf.example.com for all conference URIs. Any URI in the domain of 1441 conf.example.com would resolve to the focus. The focus could be 1442 configured to interpret an unknown user part in the conf.example.com 1443 domain as a request for a conference to be created with the 1444 conference URI as the Request-URI. For example, an INVITE sent with 1445 a Request-URI of sip:k32934208ds72@conf.example.com could be routed 1446 to the focus that would then create the conference. This conference 1447 URI should be registered by the newly created focus to become 1448 routable as a conference URI within the conf.example.com domain. The 1449 returned Contact would look as follows: 1451 Contact: ;isfocus 1453 Note, however, that this approach relies on conventions adopted 1454 between the user (human) and the focus. Also, the approach is not 1455 robust against collisions in the conference names. If a second user 1456 wishing to create a new conference happened to choose the same user 1457 part as an existing conference, the result would be that the second 1458 user would be added into the existing conference instead of creating 1459 a new one. 1461 As a result, methods of conference creation in which the conference 1462 URI is an opaque URI generated by the focus are preferred. 1464 An example call flow is shown in Figure 14. The participant Alice 1465 creates the conference URI (using some convention agreed to with the 1466 focus domain) and sends an INVITE to that URI which creates the 1467 focus. The focus creates the conference and returns the same 1468 conference URI in the 200 OK answer to the INVITE (which is ignored 1469 by the conference-unaware UA). 1471 Alice Focus Bob Carol 1472 | | | | 1473 | Alice creates the conference and chooses the conference URI. | 1474 | | | | 1475 | INVITE sip:Conf-ID F1 | | 1476 |------------------->| | | 1477 | 180 Ringing F2 | | | 1478 |<-------------------| | | 1479 | 200 OK Contact:Conf-ID;isfocus F3 | | 1480 |<-------------------| | | 1481 | ACK F4 | | | 1482 |------------------->| | | 1483 | RTP | | | 1484 |<==================>| | | 1486 Figure 14. Not Recommended - Conferencing Unaware Participant Creates a Conference 1488 6. IANA Considerations 1490 None. 1492 7. Security Considerations 1494 This document discusses call control for SIP conferencing. Both call 1495 control and conferencing have specific security requirements which 1496 will be summarized here. Conferences generally have authorization 1497 rules about who may or may not join a conference, what type of media 1498 may or may not be used, etc. This information is used by the focus 1499 to admit or deny participation in a conference. It is recommended 1500 that these types of authorization rules be used to provide security 1501 for a SIP conference. For this authorization information to be used, 1502 the focus needs to be able to authenticate potential participants. 1503 Normal SIP mechanisms including Digest authentication and 1504 certificates can be used. These conference specific security 1505 requirements are discussed further in the requirements and framework 1506 documents. 1508 For call control security, a user agent must maintain local policy on 1509 who is permitted to perform call control operations, initiate REFERs, 1510 and replace dialogs. Normal SIP authentication mechanisms are also 1511 appropriate here. The specific authentication and authorization 1512 schemes are described in the multiparty call control framework 1513 document. 1515 8. Contributors 1517 We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, 1518 Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others 1519 in list discussions. 1521 9. Changes since -04 1523 - Removed definition and IANA registration for conf option tag for 1524 UAs 1526 - Updated conference package examples 1528 10. Changes since -03 1530 - Added definition and IANA registration for conf option tag for UAs 1532 - Added requirement and flow for deletion of conference 1534 - Added scenario of participant requesting focus refer a participant 1535 to the conference 1536 - Added scenario of moving a point to point call to a conference with 1537 a separate focus 1539 11. Changes since -02 1541 - Added reference and text about use of GRUUs. 1543 - Updated for latest version of conference package. 1545 - Clarified that conference package subscription should use a 1546 separate dialog from INVITE dialog. 1548 12. Changes since -01 1550 - Added messages details of selected INVITE, 200 OK, SUBSCRIBE, 1551 REFER, and NOTIFY messages. 1553 13. Changes since -00 1555 - Showed separation between conference factory application and focus 1556 by having the application redirect to the newly created focus in the 1557 ad-hoc creation scenario. 1559 - Removed inclusion of "isfocus" parameter in Refer-To header field - 1560 this may be a useful extension to the REFER mechanism in the future, 1561 however. 1563 - Updated reference from Caller Prefs document to the new 1564 Capabilities of User Agents document. 1566 - Added scenario of participant changing user agents during a 1567 conference. 1569 - Added requirement on focus to support Replaces header field. 1571 - Added discussion about termination of dialog using BYE and 1572 subscription using SUBSCRIBE/NOTIFY to flows involving termination of 1573 session with the focus. 1575 14. References 1577 14.1 Normative References 1579 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1580 Levels", BCP 14, RFC 2119, March 1997. 1582 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1583 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1584 Session Initiation Protocol", RFC 3261, June 2002. 1586 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1587 Method", RFC 3515, April 2003. 1589 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1590 Notification", RFC 3265, June 2002. 1592 [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol 1593 (SIP) Event Package for Conference State", 1594 draft-ietf-sipping-conference-package-05 (work in progress), 1595 July 2004. 1597 [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 1598 'Join' Header", draft-ietf-sip-join-03 (work in progress), 1599 February 2004. 1601 [7] Rosenberg, J., "Indicating User Agent Capabilities in the 1602 Session Initiation Protocol (SIP)", 1603 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 1605 [8] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation 1606 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1608 [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 1609 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 1610 draft-ietf-sip-gruu-02 (work in progress), July 2004. 1612 14.2 Informative References 1614 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 1615 Coupled SIP Conferencing", 1616 draft-ietf-sipping-conferencing-requirements-01 (work in 1617 progress), October 2004. 1619 [11] Rosenberg, J., "A Framework for Conferencing with the Session 1620 Initiation Protocol", 1621 draft-ietf-sipping-conferencing-framework-03 (work in 1622 progress), October 2004. 1624 [12] Mahy, R., "A Call Control and Multi-party usage framework for 1625 the Session Initiation Protocol (SIP)", 1626 draft-ietf-sipping-cc-framework-03 (work in progress), October 1627 2003. 1629 [13] Campbell, B. and R. Sparks, "Control of Service Context using 1630 SIP Request-URI", RFC 3087, April 2001. 1632 [14] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1633 November 2002. 1635 [15] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 1636 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 1637 Examples", BCP 75, RFC 3665, December 2003. 1639 [16] Johnston, A. and R. Sparks, "Session Initiation Protocol 1640 Service Examples", draft-ietf-sipping-service-examples-07 (work 1641 in progress), July 2004. 1643 [17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1644 Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in 1645 progress), February 2004. 1647 [18] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1648 Event Package for the Session Initiation Protocol (SIP)", 1649 draft-ietf-sipping-dialog-package-04 (work in progress), 1650 February 2004. 1652 Authors' Addresses 1654 Alan Johnston 1655 MCI 1656 100 South 4th Street 1657 St. Louis, MO 63102 1659 EMail: alan.johnston@mci.com 1661 Orit Levin 1662 Microsoft 1663 One Microsoft Way 1664 Redmond, WA 75024 1666 EMail: oritl@microsoft.com 1668 Intellectual Property Statement 1670 The IETF takes no position regarding the validity or scope of any 1671 Intellectual Property Rights or other rights that might be claimed to 1672 pertain to the implementation or use of the technology described in 1673 this document or the extent to which any license under such rights 1674 might or might not be available; nor does it represent that it has 1675 made any independent effort to identify any such rights. Information 1676 on the procedures with respect to rights in RFC documents can be 1677 found in BCP 78 and BCP 79. 1679 Copies of IPR disclosures made to the IETF Secretariat and any 1680 assurances of licenses to be made available, or the result of an 1681 attempt made to obtain a general license or permission for the use of 1682 such proprietary rights by implementers or users of this 1683 specification can be obtained from the IETF on-line IPR repository at 1684 http://www.ietf.org/ipr. 1686 The IETF invites any interested party to bring to its attention any 1687 copyrights, patents or patent applications, or other proprietary 1688 rights that may cover technology that may be required to implement 1689 this standard. Please address the information to the IETF at 1690 ietf-ipr@ietf.org. 1692 Disclaimer of Validity 1694 This document and the information contained herein are provided on an 1695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1697 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1698 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1699 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1702 Copyright Statement 1704 Copyright (C) The Internet Society (2004). This document is subject 1705 to the rights, licenses and restrictions contained in BCP 78, and 1706 except as set forth therein, the authors retain all their rights. 1708 Acknowledgment 1710 Funding for the RFC Editor function is currently provided by the 1711 Internet Society.