idnits 2.17.1 draft-ietf-sipping-cc-conferencing-07.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1759. ** 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. 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 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 (June 3, 2005) is 6895 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 1645, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1708, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '3') (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '8') == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-10 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-03 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-08 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-04 Summary: 5 errors (**), 0 flaws (~~), 11 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: December 5, 2005 O. Levin 5 Microsoft Corporation 6 June 3, 2005 8 Session Initiation Protocol Call Control - Conferencing for User Agents 9 draft-ietf-sipping-cc-conferencing-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 5, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This specification defines conferencing call control features for the 43 Session Initiation Protocol (SIP). This document builds on the 44 Conferencing Requirements and Framework documents to define how a 45 tightly coupled SIP conference works. The approach is explored from 46 different user agent (UA) types perspective: conference-unaware, 47 conference-aware and focus UAs. The use of URIs in conferencing, 48 OPTIONS for capabilities discovery, and call control using REFER are 49 covered in detail with example call flow diagrams. The usage of the 50 isfocus feature tag is defined. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. SIP User Agent Conferencing Capability Types . . . . . . . . 5 57 3.1 Focus UA . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2 Conference Factory URI . . . . . . . . . . . . . . . . . . 6 59 3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . . 6 60 3.4 Conference-Aware UA . . . . . . . . . . . . . . . . . . . 6 61 4. Usage of the 'isfocus' Feature Parameter . . . . . . . . . . 7 62 4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2 Session Establishment . . . . . . . . . . . . . . . . . . 8 64 4.3 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. SIP Conferencing Primitives . . . . . . . . . . . . . . . . 8 66 5.1 INVITE: Joining a Conference using the Conference URI - 67 Dial-In . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2 INVITE: Adding a Participant by the Focus - Dial-Out . . . 12 69 5.3 INVITE: Manually Creating a Conference by Dialing into 70 a Conferencing Application . . . . . . . . . . . . . . . . 16 71 5.4 INVITE: Creating a Conference using Ad-Hoc SIP Methods . . 17 72 5.5 REFER: Requesting a Focus to Add a New Resource to a 73 Conference (Dial-out to a new Participant) . . . . . . . . 19 74 5.6 REFER: Requesting a User to Dial into a Conference 75 Using a Conference URI . . . . . . . . . . . . . . . . . . 22 76 5.7 REFER with REFER: Requesting a Focus to Refer a 77 Participant to dial into the Conference . . . . . . . . . 23 78 5.8 Join Header Field: Dialing into a Conference Using a 79 (3rd Party) Dialog Identifier . . . . . . . . . . . . . . 26 80 5.9 Replaces Header Field: Switching User Agents within a 81 Conference . . . . . . . . . . . . . . . . . . . . . . . . 28 82 5.10 Replaces Header Field: Transferring a Point-to-Point 83 Session into a Conference . . . . . . . . . . . . . . . 29 84 5.11 REFER with BYE: Requesting a Focus Remove a 85 Participant from a Conference . . . . . . . . . . . . . 31 86 5.12 Deleting a Conference . . . . . . . . . . . . . . . . . 33 87 5.13 Discovery of URI Properties using OPTIONS . . . . . . . 34 88 6. Security Considerations . . . . . . . . . . . . . . . . . . 36 89 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 90 8. Appendix - Creating a Conference by a Conference-Unaware 91 UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 10.1 Normative References . . . . . . . . . . . . . . . . . . 39 95 10.2 Informative References . . . . . . . . . . . . . . . . . 40 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 97 Intellectual Property and Copyright Statements . . . . . . . 42 99 1. Introduction 101 This specification uses the concepts and definitions from the high 102 level requirements [14] and the SIP conferencing framework [8] 103 documents. This approach is applicable to tightly coupled SIP 104 conferences. In this architecture, a UA, known as participant, 105 establishes a SIP dialog with another UA, known as a focus. The 106 focus is the central point of control, authentication, and 107 authorization. This specification defines the operation of a focus 108 and participant UAs. Note that only the signaling (SIP) needs to be 109 centralized in this model - the media can be centrally mixed, 110 distributed, or even multicast. For a full discussion of this 111 architecture, see the SIP conferencing framework [8] document. 113 The approach described in this document implements key functions in 114 the conferencing framework using SIP primitives only. This allows 115 for conducting simple conferences with defined functionalities using 116 SIP mechanisms and conventions. Many other advanced functions can be 117 implemented using additional means but they are not in the scope of 118 this document. 120 This document presents the basic call control (dial-in and dial-out) 121 conferencing building blocks from the UA perspective. Possible 122 applications include ad-hoc conferences and scheduled conferences. 124 Note that a single conference can bridge participants having 125 different capabilities and who potentially have joined the conference 126 by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc). 128 The call control and dialog manipulation approach is based on the 129 multiparty framework [15] document. That document defines the basic 130 approach of service design adopted for SIP which includes: 132 - Definition of primitives, not services 133 - Signaling model independent 134 - Invoker oriented 135 - Primitives make full use of URIs 136 - Include authentication, authorization, logging, etc. policies 137 - Define graceful fallback to baseline SIP. 139 The use of opaque URIs and the ability to communicate call control 140 context information within a URI (as opposed to using service-related 141 header fields), as discussed in RFC 3087 [11], is fundamental to this 142 approach. 144 Capabilities discovery is an important feature of SIP systems, and 145 conferencing systems can make use of such features. For a UA acting 146 as a focus in a conference, this specification defines the usage of 147 the 'isfocus' feature parameter. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 153 and "OPTIONAL" are to be interpreted as described in RFC 2119 and 154 indicate requirement levels for compliant implementations. 156 3. SIP User Agent Conferencing Capability Types 158 From a conferencing perspective, the framework document outlines a 159 number of possible different SIP components such as conference- 160 unaware participant, conference-aware participant, and focus. 162 This document applies the concepts above to the SIP call control part 163 of the conferencing components. It defines normative behavior of the 164 SIP UAs in various conferencing situations (referred later as 165 "scenarios"). 167 3.1 Focus UA 169 A focus, as defined in the framework, hosts a SIP conference and 170 maintains a SIP signaling relationship with each participant in the 171 conference. A focus contains a conference-aware user agent that 172 supports the conferencing call control conventions as defined in this 173 document. 175 A focus SHOULD support the conference package RFC XXXX [9], behave as 176 a notifier for that package, and indicate its support in the Allow- 177 Events header fields in requests and responses. A focus MAY include 178 information about the conference in SDP bodies sent as part of normal 179 SIP signaling by populating the Session Information, URI, Email 180 address, and Phone Number SDP fields. 182 In order to support advanced features, where a session established 183 between two endpoints can migrate to a centralized conference, a 184 focus SHOULD support the Replaces [6] header field. 186 A focus SHOULD utilize a GRUU as discussed in Section 4.2. 188 A user agent with focus capabilities could be implemented in end user 189 equipment and would be used for the creation of ad-hoc conferences. 191 A dedicated conferencing server, whose primary task is to 192 simultaneously host conferences of arbitrary type and size, may 193 allocate and publish a conference factory URI (as defined in the next 194 section) for creating an arbitrary number of ad-hoc conferences (and 195 subsequently their focuses) using SIP call control means. 197 3.2 Conference Factory URI 199 According to the framework, there are many ways in which a conference 200 can be created. A conferencing server implementation is free to 201 choose from these methods, which include non-automated means (such as 202 an Interactive Voice Response (IVR) system), SIP, or any conference 203 control protocol. 205 In order to automatically create an arbitrary number of ad-hoc 206 conferences (and subsequently their focuses) using SIP call control 207 means, a globally routable Conference Factory URI can be allocated 208 and published. 210 A successful attempt to establish a call to this URI would result in 211 the automatic creation a new conference and its focus. As a result, 212 note that the Conference Factory URI and the newly created focus URI 213 MAY resolve to different physical devices. 215 A scenario showing the use of the conference factory URI is shown in 216 Section 5.4. 218 3.3 Conference-Unaware UA 220 The simplest user agent can participate in a conference ignoring all 221 SIP conferencing-related information. The simplest user agent is 222 able to dial into a conference and to be invited to a conference. 223 Any conferencing information is optionally conveyed to/from it using 224 non-SIP means. Such a user agent would not usually host a conference 225 (at least, not using SIP explicitly). A conference-unaware UA need 226 only support RFC 3261 [2]. Call flows for conference-unaware UAs are 227 not shown in general in this document as they would be identical to 228 those in the SIP call flows [13] document. 230 Note that the presence of an 'isfocus' feature tag in a Contact 231 header field will not cause interoperability issues between a focus 232 and a conference-unaware UA since it will be treated as an unknown 233 header parameter and ignored, as per standard SIP behavior. 235 3.4 Conference-Aware UA 237 A conference-aware user agent supports SIP conferencing call control 238 conventions defined in this document as a conference participant, in 239 addition to support of RFC 3261 [2]. A conference-aware UA should be 240 able to process SIP redirections such as described in section 8.1.3.4 241 of RFC 3261. 243 A conference-aware UA MUST recognize the 'isfocus' feature parameter. 244 A conference-aware UA SHOULD support REFER [4], SIP events [3], and 245 the conferencing package [9]. 247 A conference-aware UA SHOULD subscribe to the conference package if 248 the 'isfocus' parameter is in the remote target URI of a dialog and 249 if the conference package is listed by a focus in an Allow-Events 250 header field. The SUBSCRIBE to the conference package SHOULD be sent 251 outside any INVITE-initiated dialog. A termination of the INVITE 252 dialog with a BYE does not necessarily terminate the SUBSCRIBE 253 dialog. 255 A conference-aware UA MAY render to the user any information about 256 the conference obtained from the SIP header fields and SDP fields 257 from the focus. 259 A conference-aware UA SHOULD render to the user any information about 260 the conference obtained from the SIP conference package. 262 4. Usage of the 'isfocus' Feature Parameter 264 4.1 General 266 The main design guidelines for the development of SIP extensions and 267 conventions for conferencing are to define the minimum number of 268 extensions and to have seamless backwards compatibility with 269 conference-unaware SIP UAs. The minimal requirement for SIP is being 270 able to express that a dialog is a part of a certain conference 271 referenced to by a URI. As a result of these extensions, it is 272 possible to do the following using SIP: 274 - Create a conference 275 - Join a conference 276 - Invite a user to a conference 277 - Expel a user by third party 278 - Discover if a URI is a conference URI 279 - Delete a conference 281 The approach taken is to use the feature parameter 'isfocus' to 282 express that a SIP dialog belongs to a conference. The use of 283 feature parameters in Contact header fields to describe the 284 characteristics and capabilities of a UA is described in the User 285 Agent Capabilities [5] document, which includes the definition of the 286 'isfocus' feature parameter. 288 4.2 Session Establishment 290 In session establishment, a focus MUST include the 'isfocus' feature 291 parameter in the Contact header field unless the focus wishes to hide 292 the fact that it is a focus. To a participant, the feature parameter 293 will be associated with the remote target URI of the dialog. It is 294 an indication to a conference-aware UA that the resulting dialog 295 belongs to a conference, identified by the URI in the Contact header 296 field, and that the call control conventions defined in this document 297 can be applied. 299 The Conference URI MUST have the GRUU (Globally Routable User Agent 300 URI) properties as detailed in [16]. 302 4.3 Discovery 304 Using the mechanism described in this section, it is possible, given 305 an opaque URI, to be able to determine if it belongs to a certain 306 conference (i.e. meaning that it is a conference URI) or not. This 307 discovery function can be implemented in SIP using an OPTIONS 308 request, and can be done either inside an active dialog or outside a 309 dialog. A focus MUST include the 'isfocus' feature parameter in a 310 200 OK response to an OPTIONS unless the focus wishes to hide the 311 fact that it is a focus. 313 5. SIP Conferencing Primitives 315 The SIP conferencing call control flows presented in this section are 316 the call control building blocks for various SIP conferencing 317 applications as described in the conferencing requirements [14] and 318 framework [8] documents. The major design goal is that the same SIP 319 conferencing primitives would be used by user agents having different 320 conferencing capabilities and implementing different applications. 322 5.1 INVITE: Joining a Conference using the Conference URI - Dial-In 324 In this section a user knows the conference URI and "dials in" to 325 join this conference. The focus will authenticate the participant 326 and apply authorization policy before allowing the participant to 327 join the conference. 329 If the UA is the first participant of the conference to dial-in, it 330 is likely that this INVITE will activate the focus and hence the 331 conference. However, the conference URI must have been reserved 332 prior to its use. 334 If the conference is up and running already, the dialing-in 335 participant is joined to the conference by its focus. 337 To join an existing specific conference, a UA will send an INVITE 338 with the Request-URI set to the conference URI. The focus MUST 339 include the 'isfocus' feature parameter in the Contact header field 340 of the 200 OK response to the INVITE. 342 An example call flow for joining a conference is shown in Figure 1. 344 Alice Focus Bob Carol 345 | | | 346 | | Carol joins the conference | 347 | | | 348 | | INVITE sip:Conf-ID F1 | 349 | |<----------------------------------------| 350 | | 180 Ringing F2 | 351 | |---------------------------------------->| 352 | | 200 OK Contact:Conf-ID;isfocus F3 | 353 | |---------------------------------------->| 354 | | ACK F4 | 355 | |<----------------------------------------| 356 | | RTP | 357 | |<=======================================>| 358 | | SUBSCRIBE sip:Conf-ID F5 | 359 | |<----------------------------------------| 360 | | 200 OK F6 | 361 | |---------------------------------------->| 362 | | NOTIFY F7 | 363 | |---------------------------------------->| 364 | | 200 OK F8 | 365 | |<----------------------------------------| 367 Figure 1. A Participant Joins a Conference using the Conference URI. 369 F1 INVITE sip:3402934234@conf.example.com SIP/2.0 370 Via: SIP/2.0/UDP client.chicago.example.com 371 ;branch=z9hG4bKhjhs8ass83 372 Max-Forwards: 70 373 To: 374 From: Carol ;tag=32331 375 Call-ID: d432fa84b4c76e66710 376 CSeq: 45 INVITE 377 Contact: 378 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 379 SUBSCRIBE, NOTIFY 380 Allow-Events: dialog 381 Accept: application/sdp, message/sipfrag 382 Supported: replaces 383 Content-Type: application/sdp 384 Content-Length: ... 386 (SDP not shown) 388 F3 SIP/2.0 200 OK 389 Via: SIP/2.0/UDP client.chicago.example.com 390 ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 391 To: ;tag=733413 392 From: Carol ;tag=32331 393 Call-ID: d432fa84b4c76e66710 394 CSeq: 45 INVITE 395 Contact: ;isfocus 396 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 397 SUBSCRIBE, NOTIFY 398 Allow-Events: dialog, conference 399 Accept: application/sdp, application/conference-info+xml, 400 message/sipfrag 401 Supported: replaces, join, gruu 402 Content-Type: application/sdp 403 Content-Length: ... 405 v=0 406 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com 407 s=- 408 i=Example Conference Hosted by Example.com 409 u=http://conf.example.com/3402934234 410 e=3402934234@conf-help.example.com 411 p=+1-888-2934234 412 c=IN IP4 ms5.conf.example.com 413 t=0 0 414 m=audio 49170 RTP/AVP 0 415 m=video 51372 RTP/AVP 31 417 F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0 418 Via: SIP/2.0/UDP client.chicago.example.com 419 ;branch=z9hG4bKdf334 420 Max-Forwards: 70 421 To: 422 From: Carol ;tag=43524545 423 Call-ID: k3l43id034ksereree 424 CSeq: 22 SUBSCRIBE 425 Contact: 426 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 427 SUBSCRIBE, NOTIFY 428 Event: conference 429 Accept: application/sdp, message/sipfrag 430 Supported: replaces 431 Content-Length: 0 433 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 434 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 435 Max-Forwards: 70 436 To: Carol ;tag=43524545 437 From: ;tag=a3343df32 438 Call-ID: k3l43id034ksereree 439 CSeq: 34321 NOTIFY 440 Contact: ;isfocus 441 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 442 SUBSCRIBE, NOTIFY 443 Event: conference 444 Accept: application/sdp, message/sipfrag 445 Subscription-State: active;expires=3600 446 Supported: replaces, join, gruu 447 Content-Type: application/conference-info+xml 449 Content-Length: ... 451 453 454 455 456 tel:+18882934234 457 458 459 460 461 462 Carol 463 464 connected 465 dialed-in 466 467 Main Audio 468 audio 469 583398 470 sendrecv 471 472 473 video 474 345212 475 sendrecv 477 478 479 480 481 483 5.2 INVITE: Adding a Participant by the Focus - Dial-Out 485 To directly add a participant to a conference, a focus SHOULD send an 486 INVITE to the participant containing a Contact header field with the 487 conference URI and the 'isfocus' feature parameter. 489 Note that a conference-unaware UA would simply ignore the 490 conferencing information and treat the session (from a SIP 491 perspective) as a point to point session. This is because standard 492 RFC 3261 [2] behavior is to ignore unknown header parameters such as 493 'isfocus'. 495 An example call flow is shown in Figure 2. It is assumed that Alice 496 is already a participant of the conference. The focus invites Carol 497 to the conference by sending an INVITE. After the session is 498 established, Carol subscribes to the conference URI. It is important 499 to note that there is no dependency on Carol's SUBSCRIBE (F5) and the 500 NOTIFY to Alice (F9) - they occur asynchronously and independently. 502 Alice Focus Bob Carol 503 | | | | 504 |<==================>| | | 505 | | | 506 | Focus "dials out" to add Carol to the conference | 507 | | | 508 | | INVITE Contact:Conf-ID;isfocus F1 | 509 | |---------------------------------------->| 510 | | 180 Ringing F2 | 511 | |<----------------------------------------| 512 | | 200 OK F3 | 513 | |<----------------------------------------| 514 | | ACK F4 | 515 | |---------------------------------------->| 516 | | RTP | 517 | |<=======================================>| 518 | | SUBSCRIBE sip:Conf-ID F5 | 519 | |<----------------------------------------| 520 | | 200 OK F6 | 521 | |---------------------------------------->| 522 | | NOTIFY F7 | 523 | |---------------------------------------->| 524 | | 200 OK F8 | 525 | |<----------------------------------------| 526 | NOTIFY F9 | | 527 |<-------------------| | 528 | 200 OK F10 | | 529 |------------------->| | 531 Figure 2. A Focus "dials out" to Add a Participant to the Conference. 533 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 534 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 535 Max-Forwards: 70 536 To: Carol ;tag=43524545 537 From: ;tag=a3343df32 538 Call-ID: k3l43id034ksereree 539 CSeq: 34321 NOTIFY 540 Contact: ;isfocus 541 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 542 SUBSCRIBE, NOTIFY 543 Event: conference 544 Accept: application/sdp, message/sipfrag 545 Subscription-State: active;expires=3600 546 Supported: replaces, gruu 547 Content-Type: application/conference-info+xml 548 Content-Length: ... 550 552 553 554 555 tel:+18882934234 556 557 558 559 560 561 Alice 562 563 connected 564 dialed-in 565 566 Main Audio 567 audio 568 647231 569 sendrecv 570 571 572 video 573 21345 574 sendrecv 575 576 577 578 579 Carol 580 581 connected 582 dialed-out 583 584 Main Audio 585 audio 586 583398 587 sendrecv 588 589 590 video 591 345212 592 sendrecv 593 594 595 597 598 600 F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 601 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 602 Max-Forwards: 70 603 To: Alice ;tag=43524545 604 From: ;tag=a3343df32 605 Call-ID: 8820450524545 606 CSeq: 998 NOTIFY 607 Contact: ;isfocus 608 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 609 SUBSCRIBE, NOTIFY 610 Event: conference 611 Accept: application/sdp, message/sipfrag 612 Subscription-State: active;expires=2450 613 Supported: replaces, gruu 614 Content-Type: application/conference-info+xml 615 Content-Length: ... 617 619 620 621 Carol 622 623 connected 624 dialed-out 625 626 Main Audio 627 audio 628 583398 629 sendrecv 630 631 632 video 633 345212 634 sendrecv 635 636 637 638 639 641 5.3 INVITE: Manually Creating a Conference by Dialing into a 642 Conferencing Application 644 In this section, a user sends an INVITE to a conference server 645 application. The application (such as an IVR system or a web page) 646 is implemented because the system requires additional input from the 647 user before it is able to create a conference. After a normal dialog 648 is established, additional information is received and the conference 649 together with its focus are created. Since the UA is now in a dialog 650 with a focus, the focus will re-INVITE the user with the conference 651 URI in Contact with the 'isfocus' feature parameter. 653 Alternatively, the additional information can be provided by the user 654 during an early dialog (see RFC 3261 [2] for a discussion of early 655 dialogs in SIP). This could be accomplished by a 183 Session 656 Progress response sent by the conferencing application. After the 657 conference is created, the conference URI would then be returned in a 658 Contact in the 200 OK. 660 Note that since this flow is all about human interaction with a 661 conferencing application, any errors and failures will be returned to 662 the human (recorded announcements, error tones, etc.). 664 As discussed in the conferencing framework, the conference URI must 665 be unique across all distinct conferences within the same domain. In 666 general, the user part of a conference URI will contain a pseudo 667 random string. 669 An example call flow is shown in Figure 3. In this example, Alice 670 uses a conference application which is triggered when Alice sends an 671 INVITE to the conference application. In this example, Conf-App is 672 used to represent the conference application URI. Alice's 673 conference-aware UA learns of the existence of the conference from 674 the 'isfocus' feature parameter and subscribes to the conference 675 package to receive notifications of the conference state. 677 Alice Focus Bob Carol 678 | | | | 679 | Alice establishes session with conference application. | 680 | | | | 681 | INVITE sip:Conf-App F1 | | 682 |------------------->| | | 683 | 180 Ringing F2 | | | 684 |<-------------------| | | 685 | 200 OK F3 | | | 686 |<-------------------| | | 687 | ACK F4 | | | 688 |------------------->| | | 689 | RTP | | | 690 |<==================>| | | 691 | | | | 692 | Alice uses the application to create the conference. | 693 | | | | 694 | INVITE Contact:Conf-ID;isfocus F5 | | 695 |<-------------------| | | 696 | 200 OK F6 | | | 697 |------------------->| | | 698 | ACK F7 | | | 699 |<-------------------| | | 700 | RTP | | | 701 |<==================>| | | 702 | | | | 703 | SUBSCRIBE sip:Conf-ID F8 | | 704 |------------------->| | | 705 | 200 OK F9 | | | 706 |<-------------------| | | 707 | NOTIFY F10 | | | 708 |<-------------------| | | 709 | 200 OK F11 | | | 710 |------------------->| | | 712 Figure 3. A Participant Creates a Conference using an Application. 714 5.4 INVITE: Creating a Conference using Ad-Hoc SIP Methods 716 This section addresses creating a conference by using ad-hoc SIP 717 means. The conference factory URI (as defined in Section 3.2) is 718 used to automatically create the conference in this example. This is 719 different from the previous scenario in that no human intervention is 720 required - an automaton can create the conference and add 721 participants. Since the conference does not need to be scheduled or 722 reserved, but is created "on the fly", it is an "ad-hoc" conference 723 creation. 725 The benefit of this approach is that the conference URI need not be 726 known to the user - instead it is created by a focus and used by the 727 participants' UAs. The main difference between this scenario and 728 Section 5.3 is that no user intervention (IVR, web page form, etc.) 729 is required to create the conference. 731 The SIP URI of the conference factory can be provisioned in the UA 732 (as in a "create new conference" button on a SIP phone) or can be 733 discovered using other means. 735 A SIP entity (such as conferencing server) can distinguish this 736 INVITE request as a request to create a new ad-hoc conference from a 737 request to join an existing conference by the Request-URI. That is, 738 although both requests may route to the same application, the 739 differing services requested can be identified by the differing URIs 740 in the request itself. 742 Assuming that all security and policy requirements have been met, a 743 new conference will be created with the Contact URI returned in the 744 200 OK being the conference URI. The Contact header field MUST 745 contain the 'isfocus' feature parameter to indicate that this URI is 746 for a conference. 748 An example call flow is shown in Figure 4. Note that Conf-Factory is 749 shorthand for the conference factory URI and Conf-ID Is short for the 750 conference URI. In this flow, Alice has a conference-aware UA and 751 creates a conference by sending an INVITE to the conference factory 752 URI. The conference factory application creates the conference and 753 redirects Alice to the focus using a 302 Moved Temporarily response. 754 Note that with proxy recursion as part of normal RFC 3261 [2] 755 behavior, Alice may never see the redirect but may just receive the 756 responses from the focus starting with message F5. Once the media 757 session is established, Alice subscribes to the conference URI 758 obtained through the Contact in the 200 OK response from the focus. 760 Alice Conf-Factory App Focus Bob 761 | | | | 762 | Alice creates the conference. | | 763 | | | | 764 | INVITE sip:Conf-Factory F1 | | 765 |------------------->| | | 766 | 302 Moved Contact:Conf-ID;isfocus F2 | | 767 |<-------------------| | | 768 | ACK F3 | | | 769 |------------------->| | | 770 | INVITE sip:Conf-ID F4 | | 771 |---------------------------------------->| | 772 | 180 Ringing F5 | | 773 |<----------------------------------------| | 774 | 200 OK Contact:Conf-ID;isfocus F6 | | 775 |<----------------------------------------| | 776 | ACK F7 | | 777 |---------------------------------------->| | 778 | RTP | | 779 |<=======================================>| | 780 | | | 781 | Alice subscribes to the conference URI. | | 782 | | | 783 | SUBSCRIBE sip:Conf-ID F8 | | 784 |---------------------------------------->| | 785 | 200 OK F9 | | 786 |<----------------------------------------| | 787 | NOTIFY F10 | | 788 |<----------------------------------------| | 789 | 200 OK F11 | | 790 |---------------------------------------->| | 792 Figure 4. Creation of a Conference using SIP Ad-Hoc Methods. 794 5.5 REFER: Requesting a Focus to Add a New Resource to a Conference 795 (Dial-out to a new Participant) 797 A SIP conference URI can be used to inject different kinds of 798 information into the conference. Examples include new participants, 799 new real-time media sources, new IM messages, and pointers to passive 800 information references (such as HTTP URIs). 802 To request the focus add a new information resource to the specified 803 conference, any SIP UA can send a REFER to the conference URI with a 804 Refer-To containing the URI of the new resource. Since this REFER is 805 sent to the conference URI and not the conference factory URI, the 806 semantics to the focus are to bring the resource into the conference 807 and make it visible to the conference participants. The resultant 808 focus procedures are dependent both on the nature of the new resource 809 (as expressed by its URI) and the policy of the focus regarding IM, 810 central vs. distributed real time media processing, etc. 812 The scenario for adding a new UA participant is important to support 813 because it works even if the new participant does not support REFER 814 and transfer call control - only the requesting participant and the 815 focus need to support the REFER and transfer call control. 817 Upon receipt of the REFER containing a Refer-To header with a SIP 818 URI, the focus SHOULD send an INVITE to the new participant 819 identified by the Refer-To SIP URI containing a Contact header field 820 with the conference URI and the 'isfocus' feature parameter. 822 A conference-unaware UA would simply ignore the conferencing 823 information and treat the session (from a SIP perspective) as a point 824 to point session. 826 An example call flow is shown in Figure 5. While this flow shows the 827 use of REFER to add a new participant to the conference, the 828 mechanism can generally add a resource as identified by a URI to the 829 conference. It is assumed that Alice is already a participant of the 830 conference. Alice sends a REFER to the conference URI. The focus 831 invites Carol to the conference by sending an INVITE. After the 832 session is established, Carol subscribes to the conference URI. It 833 is important to note that there is no dependency on Carol's SUBSCRIBE 834 (F11) and the NOTIFY to Alice (F15) - they occur asynchronously and 835 independently. 837 Alice Focus Bob Carol 838 | | | | 839 |<==================>| | | 840 | REFER sip:Conf-ID Refer-To:Carol F1 | | 841 |------------------->| | 842 | 202 Accepted F2 | | 843 |<-------------------| | 844 | NOTIFY (Trying) F3 | 845 |<-------------------| | 846 | 200 OK F4 | | 847 |------------------->| | 848 | | | 849 | Focus "dials out" to join Carol to the conference | 850 | | | 851 | | INVITE Contact:Conf-ID;isfocus F5 | 852 | |---------------------------------------->| 853 | | 180 Ringing F6 | 854 | |<----------------------------------------| 855 | | 200 OK F7 | 856 | |<----------------------------------------| 857 | | ACK F8 | 858 | |---------------------------------------->| 859 | | RTP | 860 | |<=======================================>| 861 | NOTIFY (OK) F9 | | 862 |<-------------------| | 863 | 200 OK F10 | | 864 |------------------->| | 865 | | SUBSCRIBE sip:Conf-ID F11 | 866 | |<----------------------------------------| 867 | | 200 OK F12 | 868 | |---------------------------------------->| 869 | | NOTIFY F13 | 870 | |---------------------------------------->| 871 | | 200 OK F14 | 872 | |<----------------------------------------| 873 | NOTIFY F15 | | 874 |<-------------------| | 875 | 200 OK F16 | | 876 |------------------->| | 878 Figure 5. Participant Requests Focus add a Participant to the 879 Conference. 881 F1 REFER sip:3402934234@conf.example.com SIP/2.0 882 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 883 Max-Forwards: 70 884 To: 885 From: Alice ;tag=5534562 886 Call-ID: 849392fklgl43 887 CSeq: 476 REFER 888 Contact: 889 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 890 SUBSCRIBE, NOTIFY 891 Accept: application/sdp, message/sipfrag 892 Refer-To: 893 Supported: replaces 894 Content-Length: 0 896 5.6 REFER: Requesting a User to Dial into a Conference Using a 897 Conference URI 899 A participant wishing to add a new participant will request this 900 participant to send an INVITE to the conference URI. This can be 901 done using a non-SIP means (such as passing or publishing the 902 conference URI in an email, IM, or web page). If a non-SIP means is 903 used, then the flow and requirements are identical to Section 5.1. 905 The SIP mechanism to do this utilizes the REFER method. 907 A UA wishing to add a new participant SHOULD send a REFER request to 908 the participant with a Refer-To header containing the conference URI. 910 The requirements are then identical to the dial-in case of Section 911 5.1. The inviting participant MAY receive notification through the 912 REFER action that the new participant has been added in addition to 913 the notification received through the conference package. 915 An example is shown in Figure 6. In this call flow, it is assumed 916 that Alice is already a participant of the conference. Alice sends 917 Bob an "out of band" REFER - that is, a REFER outside of an 918 established dialog. Should Bob reject the REFER, Alice might try 919 sending an INVITE to Bob to establish a session first, then send a 920 REFER within the dialog, effectively transferring Bob into the 921 conference [18]. 923 Alice Focus Bob Carol 924 | | | | 925 |<==================>| | | 926 | | | | 927 | Alice adds Bob into conference | | 928 | | | | 929 | REFER Refer-To:Conf-ID F1 | | 930 |---------------------------------------->| | 931 | 202 Accepted F2 | | | 932 |<----------------------------------------| | 933 | NOTIFY (Trying) F3| | | 934 |<----------------------------------------| | 935 | 200 OK F4 | | | 936 |---------------------------------------->| | 937 | | INVITE sip:Conf-ID F5 | 938 | |<-------------------| | 939 | | 180 Ringing F6 | | 940 | |------------------->| | 941 | | 200 OK Contact:Conf-ID;isfocus F7 | 942 | |------------------->| | 943 | | ACK F8 | | 944 | |<-------------------| | 945 | | RTP | | 946 | |<==================>| | 947 | NOTIFY (OK) F9 | | | 948 |<----------------------------------------| | 949 | 200 OK F10 | | | 950 |---------------------------------------->| | 951 | NOTIFY F11 | | | 952 |<-------------------| | | 953 | 200 OK F12 | | | 954 |------------------->| | | 955 | | SUBSCRIBE sip:Conf-ID F13 | 956 | |<-------------------| | 957 | | 200 OK F14 | | 958 | |------------------->| | 959 | | NOTIFY F15 | | 960 | |------------------->| | 961 | | 200 OK F16 | | 962 | |<-------------------| | 964 Figure 6. Adding a Participant to an Existing Conference. 966 5.7 REFER with REFER: Requesting a Focus to Refer a Participant to dial 967 into the Conference 969 A participant may request the focus refer a participant into the 970 conference by sending a REFER method. The Refer-To header field will 971 have the method set to REFER and an escaped Refer-To header field 972 containing the conference URI. 974 Note that in Message F1 below, the Refer-To header field is shown as 975 continuing across two lines - this would not be the case in an actual 976 message, the URI would have continued beyond the formatting 977 limitations of this document. 979 This scenario is shown in Figure 7. 981 Alice Focus Bob Carol 982 | | | | 983 |<==================>| | | 984 | | | | 985 | Alice asks focus to REFER Bob into conference | 986 | | | | 987 |REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1 988 |------------------->| | | 989 | 202 Accepted F2 | | | 990 |<-------------------| | | 991 | NOTIFY (Trying) F3| | | 992 |<-------------------| | | 993 | 200 OK F4 | | | 994 |------------------->| | | 995 | | | | 996 | Focus REFERs Bob to the conference | 997 | | | | 998 | | REFER Refer-To:Conf-ID F5 | 999 | |------------------->| | 1000 | | 202 Accepted F6 | | 1001 | NOTIFY (202) F7 |<-------------------| | 1002 |<-------------------| NOTIFY (Trying) F8 | | 1003 | 200 OK F9 |<-------------------| | 1004 |------------------->| 200 OK F10 | | 1005 | |------------------->| | 1006 | | INVITE sip:Conf-ID F11 | 1007 | |<-------------------| | 1008 | | 180 Ringing F12 | | 1009 | |------------------->| | 1010 | | 200 OK Contact:Conf-ID;isfocus F13 | 1011 | |------------------->| | 1012 | | ACK F14 | | 1013 | NOTIFY F15 |<-------------------| | 1014 |<-------------------| RTP | | 1015 | 200 OK F16 |<==================>| | 1016 |------------------->| NOTIFY (200) F17 | | 1017 | |<-------------------| | 1018 | | 200 OK F18 | | 1019 | |------------------->| | 1020 | | SUBSCRIBE sip:Conf-ID F17 | 1021 | |<-------------------| | 1022 | | 200 OK F19 | | 1023 | |------------------->| | 1024 | | NOTIFY F20 | | 1025 | |------------------->| | 1026 | | 200 OK F21 | | 1027 | |<-------------------| | 1029 Figure 7. Requesting a Focus Refer a Participant to a Conference. 1031 F1 REFER sip:3402934234@conf.example.com SIP/2.0 1032 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 1033 Max-Forwards: 70 1034 To: 1035 From: Alice ;tag=5534562 1036 Call-ID: 849392fklgl43 1037 CSeq: 476 REFER 1038 Contact: 1039 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1040 SUBSCRIBE, NOTIFY 1041 Accept: application/sdp, message/sipfrag 1042 Refer-To: 1044 Supported: replaces 1045 Content-Length: 0 1047 F5 REFER sip:3402934234@conf.example.com SIP/2.0 1048 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243 1049 Max-Forwards: 70 1050 To: 1051 From: ;tag=345621412 1052 Call-ID: 5494204 1053 CSeq: 4524323 REFER 1054 Contact: ;isfocus 1055 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1056 SUBSCRIBE, NOTIFY 1057 Accept: application/sdp, message/sipfrag 1058 Refer-To: 1059 Supported: join, gruu, replaces 1060 Content-Length: 0 1062 F11 INVITE sip:3402934234@conf.example.com SIP/2.0 1063 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887 1064 Max-Forwards: 70 1065 To: 1066 From: Bob ;tag=32411 1067 Call-ID: 5d4324fa84b4c76e66710 1068 CSeq: 764 INVITE 1069 Contact: 1070 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1071 SUBSCRIBE, NOTIFY 1072 Allow-Events: dialog 1073 Accept: application/sdp, message/sipfrag 1074 Supported: replaces, join 1075 Content-Type: application/sdp 1076 Content-Length: ... 1078 (SDP not shown) 1080 5.8 Join Header Field: Dialing into a Conference Using a (3rd Party) 1081 Dialog Identifier 1083 Under some circumstances, a participant wanting to join a conference 1084 may only know a dialog identifier of one of the legs of the 1085 conference. The information may have been learned using the dialog 1086 package [19] or some non-SIP means to retrieve this information from 1087 another conference participant. 1089 A UA can request to be added to a conference by sending a request to 1090 the focus containing a Join [7] header field containing a dialog ID 1091 of one leg of the conference (a dialog between another participant 1092 and the focus). 1094 There are other scenarios in which a UA can use the Join header for 1095 certain conferencing call control scenarios. See [7] for further 1096 examples and details. 1098 An example is shown in Figure 8. It is assumed that Alice is a 1099 participant of the conference. The dialog identifier between Alice 1100 and the focus is abbreviated as A-F and is known by Bob. Bob requests 1101 to be added to the conference by sending an INVITE message F1 to the 1102 focus containing a Join header which contains the dialog identifier 1103 A-F. Bob is added into the conference by the focus. 1105 Alice Focus Bob Carol 1106 | | | | 1107 |<==================>| | | 1108 | | | | 1109 | Bob requests to be added to the conference. | 1110 | | | | 1111 | | INVITE Join:A-F F1| | 1112 | |<-------------------| | 1113 | | 180 Ringing F2 | | 1114 | |------------------->| | 1115 | | 200 OK Contact:Conf-ID;isfocus F3 | 1116 | |------------------->| | 1117 | | ACK F4 | | 1118 | |<-------------------| | 1119 | | RTP | | 1120 | NOTIFY F5 |<==================>| | 1121 |<-------------------| SUBSCRIBE sip:Conf-ID F6 | 1122 | 200 OK F7 |<-------------------| | 1123 |------------------->| 200 OK F8 | | 1124 | |------------------->| | 1125 | | NOTIFY F9 | | 1126 | |------------------->| | 1127 | | 200 OK F10 | | 1128 | |<-------------------| | 1130 Figure 8. Adding a Participant to an Existing Conference using Join. 1132 F1 INVITE sip:3402934234@conf.example.com SIP/2.0 1133 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832 1134 Max-Forwards: 70 1135 To: 1136 From: Bob ;tag=32411 1137 Call-ID: d432fa84b4c76e66710 1138 CSeq: 8 INVITE 1139 Contact: 1140 Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331 1141 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1142 SUBSCRIBE, NOTIFY 1143 Allow-Events: dialog 1144 Accept: application/sdp, message/sipfrag 1145 Supported: replaces, join 1146 Content-Type: application/sdp 1147 Content-Length: ... 1149 (SDP not shown) 1151 5.9 Replaces Header Field: Switching User Agents within a Conference 1153 A participant in a conference may want to change the user agent (i.e. 1154 the endpoint or the device) with which they participate in the 1155 conference. While this could be done by simply sending a BYE from 1156 one user agent to leave the conference and an INVITE from the other 1157 user agent to rejoin. However, the SIP Replaces [6] primitive is 1158 perfectly suited to this operation. 1160 An example is shown in Figure 9. It is assumed that Alice is a 1161 participant of the conference using user agent #1. The dialog 1162 identifier between Alice's user agent #1 and the focus is abbreviated 1163 as A-F. Alice switches to user agent #2 and sends an INVITE message 1164 F1 to the focus containing a Replaces header which contains the 1165 dialog identifier A-F. Note that this dialog identifier could be 1166 learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY 1167 and the dialog event package [19]. Alice's user agent #2 is added 1168 into the conference by the focus. The focus sends a BYE to user 1169 agent #1. User agent #1 then automatically terminates the 1170 subscription by sending a SUBSCRIBE with Expires:0 to terminate the 1171 subscription. Note that the participant list (roster) has not 1172 necessarily changed during this scenario, unless detailed information 1173 about participant's user agents (i.e. endpoints) is included in the 1174 conference state notifications. For a full discussion of conference 1175 package notifications, refer to [9]. 1177 Alice UA#1 Focus Alice UA#2 Carol 1178 | | | | 1179 |<==================>| | | 1180 | | | | 1181 | Alice switches user agents during the conference. | 1182 | | | | 1183 | | INVITE sip:Conf-ID Replaces:A-F F1 | 1184 | |<-------------------| | 1185 | | 200 OK Contact:Conf-ID;isfocus F2 | 1186 | |------------------->| | 1187 | | ACK F3 | | 1188 | |<-------------------| | 1189 | | RTP | | 1190 | |<==================>| | 1191 | BYE F4 | | | 1192 |<-------------------| | | 1193 | 200 OK F5 | | | 1194 |------------------->| | | 1195 | SUBSCRIBE Expires:0 F6 | | 1196 |------------------->| | | 1197 | 200 OK F7 | | | 1198 |<-------------------| | | 1199 | NOTIFY Subscription-State:terminated F8 | | 1200 |<-------------------| | | 1201 | 200 OK F9 | | | 1202 |------------------->| | | 1203 | | SUBSCRIBE sip:Conf-ID F10 | 1204 | |<-------------------| | 1205 | | 200 OK F11 | | 1206 | |------------------->| | 1207 | | NOTIFY F12 | | 1208 | |------------------->| | 1209 | | 200 OK F13 | | 1210 | |<-------------------| | 1212 Figure 9. Switching a User Agent within a Conference. 1214 5.10 Replaces Header Field: Transferring a Point-to-Point Session into 1215 a Conference 1217 This call flow shows how a point to point call can be transferred to 1218 a conference call involving an external focus. 1220 Alice and Bob have an established session with a dialog identifier 1221 A-B. Alice joins the conference with the focus by sending an INVITE 1222 to the Conference URI. Alice then sends a REFER request to the focus 1223 to send an INVITE request to the other participant. Alice includes 1224 an escaped Replaces header field in the URI included in the Refer-To 1225 header field. Bob receives the INVITE from the focus, matches the 1226 dialog in the Replaces header field with the dialog with Alice. As a 1227 result, Bob accepts the INVITE, joins the conference, and sends a BYE 1228 to Alice to tear down their point to point dialog. 1230 Alice Focus Bob Carol 1231 | | | | 1232 | Alice is in a session with Bob | | 1233 |<=======================================>| | 1234 | | | | 1235 | Alice joins the conference | | 1236 | | | | 1237 | INVITE sip:Conf-ID F1 | | 1238 |------------------->| | | 1239 | 200 OK Contact:sip:Conf-ID;isfocus F2 | | 1240 |<-------------------| | | 1241 | ACK F3 | | | 1242 |------------------->| | | 1243 | SUBSCRIBE F4 | | | 1244 |------------------->| | | 1245 | 200 OK F5 | | | 1246 |<-------------------| | | 1247 | NOTIFY F6 | | | 1248 |<-------------------| | | 1249 | 200 OK F7 | | | 1250 |------------------->| | | 1251 |<==================>| | | 1252 | | | | 1253 | Alice asks focus to REFER Bob into conference | 1254 | | | | 1255 | REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 | 1256 |------------------->| | | 1257 | 202 Accepted F9 | | | 1258 |<-------------------| | | 1259 | NOTIFY (Trying) F10| | | 1260 |<-------------------| | | 1261 | 200 OK F11 | | | 1262 |------------------->| | | 1263 | | | | 1264 | Focus invites Bob to the conference | 1265 | | | | 1266 | | INVITE sip:Conf-ID Replaces:A-B F12 | 1267 | |------------------->| | 1268 | | 200 OK F13 | | 1269 | |<-------------------| | 1270 | | ACK F14 | | 1271 | |------------------->| | 1272 | | RTP | | 1273 | |<==================>| | 1274 | BYE F15 | | 1275 |<----------------------------------------| | 1276 | 200 OK F16 | | 1277 |---------------------------------------->| | 1278 | NOTIFY (200) F17 | | | 1279 |<-------------------| | | 1280 | 200 OK F18 | | | 1281 |------------------->| | | 1282 | NOTIFY F19 | | | 1283 |<-------------------| | | 1284 | 200 OK F20 | | | 1285 |------------------->| | | 1286 | | SUBSCRIBE sip:Conf-ID F21 | 1287 | |<-------------------| | 1288 | | 200 OK F22 | | 1289 | |------------------->| | 1290 | | NOTIFY F23 | | 1291 | |------------------->| | 1292 | | 200 OK F24 | | 1293 | |<-------------------| | 1294 | | | | 1296 Figure 10. Transitioning a Point to Point Session into a Conference. 1298 5.11 REFER with BYE: Requesting a Focus Remove a Participant from a 1299 Conference 1301 To request the focus remove a participant from the specified 1302 conference, a properly authorized SIP UA (typically the conference 1303 owner) can send a REFER to the conference URI with a Refer-To 1304 containing the URI of the participant and with the method set to BYE. 1305 The requestor does not need to know the dialog information about the 1306 dialog between the focus and the participant who will be removed - 1307 the focus knows this information and fills it when it generates the 1308 BYE request. 1310 An example call flow is shown in Figure 11. It is assumed that Alice 1311 and Carol are already participants of the conference and that Alice 1312 is authorized to remove members from the conference. Alice sends a 1313 REFER to the conference URI with a Refer-To header containing a URI 1314 of the form sip:carol@chicago.example.com;method=BYE. 1316 Alice Focus Bob Carol 1317 | | | | 1318 |<==================>| | 1319 | REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 | 1320 |------------------->| | 1321 | 202 Accepted F2 | | 1322 |<-------------------| | 1323 | NOTIFY (Trying) F3 | 1324 |<-------------------| | 1325 | 200 OK F4 | | 1326 |------------------->| | 1327 | | | 1328 | Focus removes Carol from the conference | 1329 | | | 1330 | | BYE sip:Carol F5 | 1331 | |---------------------------------------->| 1332 | | 200 OK F6 | 1333 | |<----------------------------------------| 1334 | | NOTIFY Subscription-State:terminated F7 | 1335 | |---------------------------------------->| 1336 | | 200 OK F8 | 1337 | |<----------------------------------------| 1338 | NOTIFY (200) F9 | | 1339 |<-------------------| | 1340 | 200 OK F10 | | 1341 |------------------->| | 1342 | NOTIFY F11 | | 1343 |<-------------------| | 1344 | 200 OK F12 | | 1345 |------------------->| | 1347 Figure 11. Participant Requests Focus Remove a Participant from the 1348 Conference. 1350 F1 REFER sip:3402934234@conf.example.com SIP/2.0 1351 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 1352 Max-Forwards: 70 1353 To: 1354 From: Alice ;tag=5534562 1355 Call-ID: 849392fklgl43 1356 CSeq: 476 REFER 1357 Contact: 1358 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1359 SUBSCRIBE, NOTIFY 1360 Accept: application/sdp, message/sipfrag 1361 Refer-To: 1362 Supported: replaces 1363 Content-Length: 0 1365 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 1366 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 1367 Max-Forwards: 70 1368 From: ;tag=5393k2312 1369 To: Carol ;tag=32331 1370 Call-ID: d432fa84b4c76e66710 1371 CSeq: 78654 BYE 1372 Content-Length: 0 1374 5.12 Deleting a Conference 1376 The default conference policy for conferences created using the 1377 Conference Factory URI is that the conference is deleted when the 1378 creator departs. 1380 Figure 12 shows this call flow in which the creator Alice departs 1381 causing the conference to be deleted. Note that the order of sending 1382 BYEs and final NOTIFYs is not important. 1384 Alice Focus Bob Carol 1385 | | | | 1386 |<==================>|<==================>| | 1387 | BYE F1 |<=======================================>| 1388 |------------------->| | | 1389 | 200 OK F2 | | | 1390 |<-------------------| | | 1391 | | BYE F3 | | 1392 | |------------------->| | 1393 | | 200 OK F4 | | 1394 | |<-------------------| | 1395 | | BYE F5 | 1396 | |---------------------------------------->| 1397 | | 200 OK F6 | 1398 | |<----------------------------------------| 1399 | NOTIFY Subscription-State:terminated F7 | 1400 |<-------------------| | | 1401 | 200 OK F8 | | | 1402 |------------------->| NOTIFY Subscription-State:terminated F9 | 1403 | |------------------->| | 1404 | | 200 OK F10 | | 1405 | |<-------------------| | 1406 | | NOTIFY Subscription-State:terminated F11| 1407 | |---------------------------------------->| 1408 | | 200 OK F12 | 1409 | |<----------------------------------------| 1411 Figure 12. Deleting a Conference 1413 5.13 Discovery of URI Properties using OPTIONS 1415 A UA MAY send an OPTIONS request to discover if an opaque URI is a 1416 conference URI (resolves to a focus). In addition, the reply to the 1417 OPTIONS request can also indicate support for various SIP call 1418 control extensions used in this document. 1420 Note that the Allow, Accept, Allow-Events, and Supported header 1421 fields should be present in an INVITE from a focus or a 200 OK answer 1422 from the focus to an INVITE as a part of a normal dialog 1423 establishment process. 1425 An example is shown in Figure 13 where Alice sends an OPTIONS to a 1426 URI which resolves to a focus. 1428 Alice Focus Bob Carol 1429 | | | | 1430 | OPTIONS sip:Conf-ID F1 | | 1431 |------------------->| | | 1432 | 200 OK Contact:Conf-ID;isfocus F2 | | 1433 |<-------------------| | | 1435 Figure 13. Participant Queries Capabilities of URI of a Focus. 1437 Following is an example message detail of message F2 in Figure 13. 1438 Based on the response, Alice's UA learns that the URI is a conference 1439 URI and that the responding UA is focus that supports a number of SIP 1440 call control extensions. 1442 The response details are as follows: 1444 F2 SIP/2.0 200 OK 1445 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87 1446 ;received=192.0.2.4 1447 To: ;tag=93810874 1448 From: Alice ;tag=1928301774 1449 Call-ID: a84b4c76e66710 1450 CSeq: 63104 OPTIONS 1451 Contact: ;isfocus 1452 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1453 SUBSCRIBE, NOTIFY 1454 Allow-Events: refer, conference 1455 Accept: application/sdp, application/conference-info+xml, 1456 message/sipfrag 1457 Accept-Language: en 1458 Supported: replaces, join, gruu 1459 Content-Type: application/sdp 1460 Content-Length: ... 1462 v=0 1463 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com 1464 s=- 1465 i=Example Conference Hosted by Example.com 1466 u=http://conf.example.com/3402934234 1467 e=3402934234@conf-help.example.com 1468 p=+18882934234 1469 c=IN IP4 ms5.conf.example.com 1470 t=0 0 1471 m=audio 0 RTP/AVP 0 3 5 7 1472 m=video 0 RTP/AVP 31 32 1474 Useful information from each of these headers is detailed in the next 1475 sections. 1477 Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY 1478 indicate that the user agent supports call control and SIP Events. 1480 Accept. The support of bodies such as message/sipfrag [12], 1481 application/conference-info+xml [9] also indicates support of call 1482 control and conferencing. 1484 Allow-Events. The support of event packages such as refer [4], 1485 conference [9]. 1487 Supported. The support of extensions such as replaces, join, and 1488 gruu. 1490 Contact. The presence of the 'isfocus' feature parameter in the 1491 Contact header indicates that the URI is a conference URI and that 1492 the UA is a focus. 1494 6. Security Considerations 1496 This specification defines the interaction between a focus UA and a 1497 participant UA in a conferencing application. As a result, the 1498 security considerations and mechanisms defined in RFC 3261 [2] apply. 1499 However, there are some aspects unique to conferencing which will be 1500 discussed here. 1502 A conference often involves the use of substantial network bandwidth 1503 and computing resources. As a result, authentication is even more 1504 important than in a simple peer to peer session. As discussed in the 1505 conferencing framework [8], conferences often have policy related to 1506 conferencing resources. A focus SHOULD authenticate participants 1507 before joining them to a conference and allowing utilization of 1508 conferencing resources. Different policies can be applied by a focus 1509 to different participants based on the result of authentication. 1511 A participant will be interacting with a number of other participants 1512 through the focus. As a result, a participant should authenticate 1513 the focus and be sure that the focus used for the conference is 1514 trusted. Normal SIP authentication mechanisms are suitable for 1515 participant and focus authentication, such as SIP Digest utilizing a 1516 shared secret, or certificates, or a secured SIP identity mechanism. 1517 In addition, a focus SHOULD support Secure SIP connections so that 1518 hop by hop mutual authentication and confidentiality provided by TLS 1519 can be achieved. 1521 In the SIP dialog between them, a focus utilizes the 'isfocus' 1522 feature tag to indicate that the UA is acting as a focus. As such, 1523 the SIP header fields such as Contact SHOULD have end to end 1524 integrity. A participant and focus SHOULD support an end to end 1525 integrity mechanism such as S/MIME. 1527 Once a participant has learned that the other UA is a focus, SIP call 1528 control operations (such as REFER) can be implemented, or a 1529 subscription to the conference package of the focus might be 1530 attempted. The security considerations described in RFC 3515 [4] 1531 apply to any REFER call control operations. A focus and participant 1532 will apply policy to determine which call control operations are 1533 allowed. 1535 A focus accepting subscriptions to the conference package must follow 1536 the security considerations in RFC XXXX [9]. Since notifications can 1537 carry sensitive information, the subscriptions should be 1538 authenticated and the notifications delivered with confidentiality 1539 and integrity protection. Since a participant is not able to 1540 authenticate other participants directly, a participant must rely on 1541 the focus to perform this authentication. 1543 A focus MUST support a participant's request for privacy, either 1544 through conference policy or as expressed through the signaling. For 1545 example, a participant joining a conference and including a Privacy 1546 header field [10] must not have identity information revealed to 1547 other participants by the focus. If other signaling protocols are 1548 used, privacy signaled through them also must be respected. 1550 7. Contributors 1552 We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, 1553 Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others 1554 in list discussions. 1556 Thanks to Miguel Garcia for his detailed last call review and 1557 suggestions. 1559 8. Appendix - Creating a Conference by a Conference-Unaware UA 1561 This section discusses how a human user operating a conference- 1562 unaware UA can create and add participants to a conference. This 1563 method is described as an appendix since it is NOT RECOMMENDED. The 1564 scenarios involving creating a conference using ad-hoc or manual 1565 means are recommended over this scenario. This scenario is included, 1566 however, for completeness. 1568 A user (human) would choose a conference URI according to system 1569 rules and insert it into the Request-URI of the INVITE. This same 1570 URI is echoed by a focus adhering to certain addressing conventions 1571 (discussed below) in the Contact header by the focus. Additional 1572 participants could be added by non-SIP means (publication of the 1573 chosen conference URI using web pages, email, IM, etc.). 1574 Alternatively, the conference-unaware UA could then add other 1575 participants to the conference using SIP call control by establishing 1576 a session with them, then transferring [18] them to the conference 1577 URI. Note that in this scenario only the user (human) is aware of 1578 the conferencing application, and the conference-unaware UA only need 1579 support RFC 3261 [2] and optionally call transfer. 1581 Making this work does impose certain addressing conventions on a 1582 system. As a service/implementation choice, a system could allow the 1583 creator of the conference to choose the user portion of the 1584 conference URI. However, this requires the URI format to be agreed 1585 upon between a user and the system. 1587 For example, a service provider might reserve the domain 1588 conf.example.com for all conference URIs. Any URI in the domain of 1589 conf.example.com would resolve to the focus. The focus could be 1590 configured to interpret an unknown user part in the conf.example.com 1591 domain as a request for a conference to be created with the 1592 conference URI as the Request-URI. For example, an INVITE sent with 1593 a Request-URI of sip:k32934208ds72@conf.example.com could be routed 1594 to the focus that would then create the conference. This conference 1595 URI should be registered by the newly created focus to become 1596 routable as a conference URI within the conf.example.com domain. The 1597 returned Contact would look as follows: 1599 Contact: ;isfocus 1601 Note, however, that this approach relies on conventions adopted 1602 between the user (human) and the focus. Also, the approach is not 1603 robust against collisions in the conference names. If a second user 1604 wishing to create a new conference happened to choose the same user 1605 part as an existing conference, the result would be that the second 1606 user would be added into the existing conference instead of creating 1607 a new one. 1609 As a result, methods of conference creation in which the conference 1610 URI is an opaque URI generated by the focus are preferred. 1612 An example call flow is shown in Figure 14. The participant Alice 1613 creates the conference URI (using some convention agreed to with the 1614 focus domain) and sends an INVITE to that URI which creates the 1615 focus. The focus creates the conference and returns the same 1616 conference URI in the 200 OK answer to the INVITE (which is ignored 1617 by the conference-unaware UA). 1619 Alice Focus Bob Carol 1620 | | | | 1621 | Alice creates the conference and chooses the conference URI. | 1622 | | | | 1623 | INVITE sip:Conf-ID F1 | | 1624 |------------------->| | | 1625 | 180 Ringing F2 | | | 1626 |<-------------------| | | 1627 | 200 OK Contact:Conf-ID;isfocus F3 | | 1628 |<-------------------| | | 1629 | ACK F4 | | | 1630 |------------------->| | | 1631 | RTP | | | 1632 |<==================>| | | 1634 Figure 14. Not Recommended - Conferencing Unaware Participant 1635 Creates a Conference 1637 9. IANA Considerations 1639 None. 1641 10. References 1643 10.1 Normative References 1645 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1646 Levels", BCP 14, RFC 2119, March 1997. 1648 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1649 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1650 Session Initiation Protocol", RFC 3261, June 2002. 1652 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1653 Notification", RFC 3265, June 2002. 1655 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1656 Method", RFC 3515, April 2003. 1658 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1659 User Agent Capabilities in the Session Initiation Protocol 1660 (SIP)", RFC 3840, August 2004. 1662 [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1663 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1665 [7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1666 "Join" Header", RFC 3911, October 2004. 1668 [8] Rosenberg, J., "A Framework for Conferencing with the Session 1669 Initiation Protocol", 1670 draft-ietf-sipping-conferencing-framework-05 (work in 1671 progress), May 2005. 1673 [9] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1674 Package for Conference State", 1675 draft-ietf-sipping-conference-package-10 (work in progress), 1676 March 2005. 1678 [10] Peterson, J., "A Privacy Mechanism for the Session Initiation 1679 Protocol (SIP)", RFC 3323, November 2002. 1681 10.2 Informative References 1683 [11] Campbell, B. and R. Sparks, "Control of Service Context using 1684 SIP Request-URI", RFC 3087, April 2001. 1686 [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1687 November 2002. 1689 [13] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. 1690 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 1691 Examples", BCP 75, RFC 3665, December 2003. 1693 [14] Levin, O. and R. Even, "High Level Requirements for Tightly 1694 Coupled SIP Conferencing", 1695 draft-ietf-sipping-conferencing-requirements-01 (work in 1696 progress), October 2004. 1698 [15] Mahy, R., "A Call Control and Multi-party usage framework for 1699 the Session Initiation Protocol (SIP)", 1700 draft-ietf-sipping-cc-framework-04 (work in progress), 1701 February 2005. 1703 [16] Rosenberg, J., "Obtaining and Using Globally Routable User 1704 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1705 (SIP)", draft-ietf-sip-gruu-03 (work in progress), 1706 February 2005. 1708 [17] Johnston, A. and R. Sparks, "Session Initiation Protocol 1709 Service Examples", draft-ietf-sipping-service-examples-08 (work 1710 in progress), February 2005. 1712 [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1713 Control - Transfer", draft-ietf-sipping-cc-transfer-04 (work in 1714 progress), April 2005. 1716 [19] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 1717 the Session Initiation Protocol (SIP)", 1718 draft-ietf-sipping-dialog-package-06 (work in progress), 1719 April 2005. 1721 Authors' Addresses 1723 Alan Johnston 1724 MCI 1725 100 South 4th Street 1726 St. Louis, MO 63102 1728 Email: alan.johnston@mci.com 1730 Orit Levin 1731 Microsoft Corporation 1732 One Microsoft Way 1733 Redmond, WA 98052 1735 Email: oritl@microsoft.com 1737 Intellectual Property Statement 1739 The IETF takes no position regarding the validity or scope of any 1740 Intellectual Property Rights or other rights that might be claimed to 1741 pertain to the implementation or use of the technology described in 1742 this document or the extent to which any license under such rights 1743 might or might not be available; nor does it represent that it has 1744 made any independent effort to identify any such rights. Information 1745 on the procedures with respect to rights in RFC documents can be 1746 found in BCP 78 and BCP 79. 1748 Copies of IPR disclosures made to the IETF Secretariat and any 1749 assurances of licenses to be made available, or the result of an 1750 attempt made to obtain a general license or permission for the use of 1751 such proprietary rights by implementers or users of this 1752 specification can be obtained from the IETF on-line IPR repository at 1753 http://www.ietf.org/ipr. 1755 The IETF invites any interested party to bring to its attention any 1756 copyrights, patents or patent applications, or other proprietary 1757 rights that may cover technology that may be required to implement 1758 this standard. Please address the information to the IETF at 1759 ietf-ipr@ietf.org. 1761 Disclaimer of Validity 1763 This document and the information contained herein are provided on an 1764 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1765 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1766 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1767 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1768 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1769 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1771 Copyright Statement 1773 Copyright (C) The Internet Society (2005). This document is subject 1774 to the rights, licenses and restrictions contained in BCP 78, and 1775 except as set forth therein, the authors retain all their rights. 1777 Acknowledgment 1779 Funding for the RFC Editor function is currently provided by the 1780 Internet Society.