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