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