idnits 2.17.1 draft-ietf-sipping-cc-conferencing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance 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 28, 2003) is 7601 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 1026, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1084, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-join-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-callee-caps-00 == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-03 == Outdated reference: A later version (-01) exists of draft-ietf-sipping-conferencing-requirements-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-02 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-04 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-01 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 3 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 27, 2003 O. Levin 5 RADVISION 6 June 28, 2003 8 Session Initiation Protocol Call Control - Conferencing for User 9 Agents 10 draft-ietf-sipping-cc-conferencing-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 27, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines conferencing call control features for the 41 Session Initiation Protocol (SIP). This document builds on the 42 Conferencing Requirements and Framework documents to define how a 43 tightly coupled SIP conference works. The approach is explored from 44 different user agent (UA) types perspective: conference-unaware, 45 conference-aware and focus UAs. The use of URIs in conferencing, 46 OPTIONS for capabilities discovery, and call control using REFER are 47 covered in detail with example call flow diagrams. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Usage of the 'isfocus' Feature Parameter . . . . . . . . . . 3 53 2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2 Session Establishment . . . . . . . . . . . . . . . . . . . 4 55 2.3 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. SIP User Agent Conferencing Capability Types . . . . . . . . 4 57 3.1 Focus UA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2 Conference Factory URI . . . . . . . . . . . . . . . . . . . 5 59 3.3 Conference-Unaware UA . . . . . . . . . . . . . . . . . . . 5 60 3.4 Conference-Aware UA . . . . . . . . . . . . . . . . . . . . 6 61 4. SIP Conferencing Primitives . . . . . . . . . . . . . . . . 6 62 4.1 Joining a Conference using the Conference URI - Dial In . . 6 63 4.2 Adding a Participant by the Focus - Dial Out . . . . . . . . 7 64 4.3 Manually Creating a Conference by Dialing into a 65 Conferencing Application . . . . . . . . . . . . . . . . . . 8 66 4.4 Creating a Conference by a Conference-Unaware UA . . . . . . 10 67 4.5 Creating a Conference using Ad-Hoc SIP Methods . . . . . . . 11 68 4.6 Requesting the Focus Add a New Resource to a Conference . . 13 69 4.7 Adding a 3rd Party Using Conference URI . . . . . . . . . . 15 70 4.8 Adding a 3rd Party Using a Dialog Identifier . . . . . . . . 16 71 4.9 Changing User Agents within a Conference . . . . . . . . . . 17 72 4.10 Bringing a Point-to-Point Dialog into a Conference . . . . . 18 73 4.11 Requesting the Focus Remove a Participant from a 74 Conference . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 4.12 Discovery of Conferencing Capabilities using OPTIONS . . . . 20 76 5. Security Considerations . . . . . . . . . . . . . . . . . . 21 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7. Changes since -00 . . . . . . . . . . . . . . . . . . . . . 22 79 Normative References . . . . . . . . . . . . . . . . . . . . 22 80 Informative References . . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 82 Intellectual Property and Copyright Statements . . . . . . . 25 84 1. Introduction 86 This document uses the concepts and definitions from the high level 87 requirements [9] and the SIP conferencing framework [10] documents. 89 The approach described in this document implements key functions in 90 the conferencing framework using SIP primitives only. This allows for 91 conducting simple conferences with defined functionalities using SIP 92 mechanisms and conventions. Many other advanced functions can be 93 implemented using additional means but they are not in the scope of 94 this document. 96 This document presents the basic call control (dial-in and dial-out) 97 conferencing building blocks from the UA perspective. Possible 98 applications include ad-hoc conferences and scheduled conferences. 100 Note that a single conference can bridge participants having 101 different capabilities and who potentially have joined the conference 102 by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc). 104 The call control and dialog manipulation approach is based on the 105 multiparty framework [11] document. That document defines the basic 106 approach of service design adopted for SIP which includes: 108 - Definition of primitives, not services 109 - Signaling model independent 110 - Invoker oriented 111 - Primitives make full use of URIs 112 - Include authentication, authorization, logging, etc. policies 113 - Define graceful fallback to baseline SIP. 115 The use of opaque URIs and the ability to communicate call control 116 context information within a URI (as opposed to service-related 117 header fields), as discussed in RFC 3087 [12], is fundamental to this 118 approach. 120 2. Usage of the 'isfocus' Feature Parameter 122 2.1 General 124 The main design guidelines for the development of SIP extensions and 125 conventions for conferencing are to define the minimum number of 126 extensions and to have seamless backwards compatibility with 127 conference-unaware SIP UAs. The minimal requirement for SIP is being 128 able to express that a dialog is a part of a certain conference 129 referenced to by a URI. As a result of these extensions, it is 130 possible to do the following using SIP: 132 - Create a conference 133 - Join a conference 134 - Invite a user to a conference 135 - Expel a user by third party 136 - Discover if a URI is a conference URI 138 The approach taken is to use the feature parameter "isfocus" to 139 express that a SIP dialog belongs to a conference. The use of 140 feature parameters in Contact header fields to describe the 141 characteristics and capabilities of a UA is described in the User 142 Agent Capabilities [7] document which includes the definition of the 143 "isfocus" feature parameter. 145 2.2 Session Establishment 147 In session establishment, a focus MUST include the "isfocus" feature 148 parameter in the Contact header field unless the focus wishes to hide 149 the fact that it is a focus. To a participant, the feature parameter 150 will be associated with the remote target URI of the dialog. It is 151 an indication to a conference-aware UA that the resulting dialog 152 belongs to a conference identified by the URI in the Contact header 153 field and that the call control conventions defined in this document 154 can be applied. 156 2.3 OPTIONS 158 Currently the only met requirement is: given an opaque URI, being 159 able to recognize whether it belongs to a certain conference (i.e. 160 meaning that it is a conference URI) or not. As with any other 161 OPTIONS request, it can be done either inside an active dialog or 162 outside a dialog. A focus MUST include the "isfocus" feature 163 parameter in a 200 OK response to an OPTIONS unless the focus wishes 164 to hide the fact that it is a focus. 166 3. SIP User Agent Conferencing Capability Types 168 From a conferencing perspective, the framework document outlines a 169 number of possible different SIP components such as 170 conference-unaware participant, conference-aware participant, and 171 focus. 173 This document applies the concepts above to the SIP call control part 174 of the conferencing components. It defines normative behavior of the 175 SIP UAs in various conferencing situations (referred later as 176 "scenarios"). 178 3.1 Focus UA 180 A focus, as defined in the framework, hosts a SIP conference and 181 maintains a SIP signaling relationship with each participant in the 182 conference. A focus contains a conference-aware user agent that 183 supports the conferencing call control conventions as defined in this 184 document. 186 A focus SHOULD support the conference package [5] and indicate so in 187 Allow-Events header fields in requests and responses. A focus MAY 188 include information about the conference in SDP message bodies sent. 190 A focus SHOULD support the Replaces [8] header field. 192 A user agent with focus capabilities could be implemented in end user 193 equipment and would be used for the creation of ad-hoc conferences. 195 A dedicated conferencing server, whose primary task is to 196 simultaneously host conferences of arbitrary type and size, may 197 allocate and publish a conference factory URI (as defined in the next 198 section) for creating an arbitrary number of ad-hoc conferences (and 199 subsequently their focuses) using SIP call control means. 201 3.2 Conference Factory URI 203 According to the framework, there are many ways in which a conference 204 can be created. These are open to the conferencing server 205 implementation policy and include non-automated means (such as IVR), 206 SIP, and a conference policy control protocol. 208 In order to automatically create an arbitrary number of ad-hoc 209 conferences (and subsequently their focuses) using SIP call control 210 means, a globally routable Conference Factory URI can be allocated 211 and published. 213 A successful attempt to establish a call to this URI would result in 214 the automatic creation a new conference and its focus. As a result, 215 note that the Conference Factory URI and the newly created focus URI 216 MAY resolve to different physical devices. 218 A scenario showing the use of the conference factory URI is shown in 219 Section 4.5. 221 3.3 Conference-Unaware UA 223 The simplest user agent can participate in a conference ignoring all 224 SIP conferencing-related information. The simplest user agent is able 225 to dial into a conference and to be invited to a conference. Any 226 conferencing information is optionally conveyed to/from it using 227 non-SIP means. Such a user agent would not usually host a conference 228 (at least, not using SIP explicitly). A conference-unaware UA needs 229 only to support RFC 3261 [2]. Call flows for conference-unaware UAs 230 are not shown in general in this document as they would be identical 231 to those in the SIP call flows [14] document. 233 3.4 Conference-Aware UA 235 A conference-aware user agent supports SIP conferencing call control 236 conventions defined in this document as a conference participant, in 237 addition to support of RFC 3261. 239 A conference-aware UA MUST recognize the "isfocus" feature parameter. 240 A conference-aware UA SHOULD support REFER [3], SIP events [4], and 241 the conferencing package [5]. 243 A conference-aware UA SHOULD subscribe to the conference package if 244 the "isfocus" parameter is in the remote target URI of a dialog and 245 if the conference package is listed by a focus in an Allow-Events 246 header field. 248 A conference-aware UA MAY render to the user any information about 249 the conference obtained from the SIP header fields and SDP fields 250 from the focus. 252 4. SIP Conferencing Primitives 254 The SIP conferencing call control flows presented in this section are 255 the call control building blocks for various SIP tight conferencing 256 applications as described in the conferencing requirements [9] and 257 framework [10] documents. The major design goal is that the same SIP 258 conferencing primitives would be used by user agents having different 259 conferencing capabilities and comprising different applications. 261 4.1 Joining a Conference using the Conference URI - Dial In 263 In this section a user knows the conference URI and "dials in" to 264 join this conference. 266 If the UA is the first participant of the conference to dial in, it 267 is likely that this INVITE will create the focus and hence the 268 conference. However, the conference URI must have been reserved 269 prior to its use. 271 If the conference is up and running already, the dialing-in 272 participant is joined to the conference by its focus. 274 To join an existing specific conference a UA SHOULD send an INVITE 275 with the Request-URI set to the conference URI. The focus MUST 276 include the "isfocus" feature parameter in the Contact header field 277 of the 200 OK response to the INVITE. 279 Participants leaving the conference send a BYE to the focus. If they 280 have a current subscription to the conference package, they also must 281 send a SUBSCRIBE with an Expires:0 header field to terminate the 282 subscription since the BYE does not automatically terminate the 283 subscription. 285 An example call flow for joining a conference is shown in Figure 1. 287 Alice Focus Bob Carol 288 | | | 289 | | Carol joins the conference | 290 | | | 291 | | INVITE sip:Conf-ID F1 | 292 | |<----------------------------------------| 293 | | 180 Ringing F2 | 294 | |---------------------------------------->| 295 | | 200 OK Contact:Conf-ID;isfocus F3 | 296 | |---------------------------------------->| 297 | | ACK F4 | 298 | |<----------------------------------------| 299 | | RTP | 300 | |<=======================================>| 301 | | SUBSCRIBE sip:Conf-ID F5 | 302 | |<----------------------------------------| 303 | | 200 OK F6 | 304 | |---------------------------------------->| 305 | | NOTIFY F7 | 306 | |---------------------------------------->| 307 | | 200 OK F8 | 308 | |<----------------------------------------| 310 Figure 1. A Participant Joins a Conference using the Conference URI. 312 4.2 Adding a Participant by the Focus - Dial Out 314 To directly add a participant to a conference, a focus SHOULD send an 315 INVITE to the participant containing a Contact header field with the 316 conference URI and the "isfocus" feature parameter. 318 Note that a conference-unaware UA would simply ignore the 319 conferencing information and treat the session (from a SIP 320 perspective) as a point to point session. 322 An example call flow is shown in Figure 2. It is assumed that Alice 323 is already a participant of the conference. The focus invites Carol 324 to the conference by sending an INVITE. After the session is 325 established, Carol subscribes to the conference URI. It is important 326 to note that there is no dependency on Carol's SUBSCRIBE (F5) and the 327 NOTIFY to Alice (F9) - they occur asynchronously and independently. 329 Alice Focus Bob Carol 330 | | | | 331 |<==================>| | | 332 | | | 333 | Focus "dials out" to add Carol to the conference | 334 | | | 335 | | INVITE Contact:Conf-ID;isfocus F1 | 336 | |---------------------------------------->| 337 | | 180 Ringing F2 | 338 | |<----------------------------------------| 339 | | 200 OK F3 | 340 | |<----------------------------------------| 341 | | ACK F4 | 342 | |---------------------------------------->| 343 | | RTP | 344 | |<=======================================>| 345 | | SUBSCRIBE sip:Conf-ID F5 | 346 | |<----------------------------------------| 347 | | 200 OK F6 | 348 | |---------------------------------------->| 349 | | NOTIFY F7 | 350 | |---------------------------------------->| 351 | | 200 OK F8 | 352 | |<----------------------------------------| 353 | NOTIFY F9 | | 354 |<-------------------| | 355 | 200 OK F10 | | 356 |------------------->| | 358 Figure 2. A Focus "dials out" to Add a Participant to the Conference. 360 4.3 Manually Creating a Conference by Dialing into a Conferencing 361 Application 363 In this section, a user sends an INVITE to a conference server 364 application. The application (such as an IVR system or a web page) 365 is implemented because the system requires additional input from the 366 user before it is able to create a conference. After a normal dialog 367 is established, additional information is received and the conference 368 together with its focus are created. At this point the conference 369 server MUST re-INVITE the user with the conference URI in Contact 370 with the "isfocus" feature parameter. 372 Alternatively, the additional information MAY be provided by the user 373 during an early dialog established. This could be accomplished by a 374 183 Session Progress response sent by the conferencing application. 375 After the conference is created, the conference URI MUST then be 376 returned in a Contact in the 200 OK. 378 An example call flow is shown in Figure 3. In this example, Alice 379 uses a conference application which is triggered when Alice sends an 380 INVITE to the conference application. In this example, Conf-App is 381 used to represent the conference application URI. Alice's 382 conference-aware UA learns of the existence of the conference from 383 the "isfocus" feature parameter and subscribes to the conference 384 package to receive notifications of the conference state. 386 Alice Focus Bob Carol 387 | | | | 388 | Alice establishes session with conference application. | 389 | | | | 390 | INVITE sip:Conf-App F1 | | 391 |------------------->| | | 392 | 180 Ringing F2 | | | 393 |<-------------------| | | 394 | 200 OK F3 | | | 395 |<-------------------| | | 396 | ACK F4 | | | 397 |------------------->| | | 398 | RTP | | | 399 |<==================>| | | 400 | | | | 401 | Alice uses the application to create the conference. | 402 | | | | 403 | INVITE Contact:Conf-ID;isfocus F5 | | 404 |<-------------------| | | 405 | 200 OK F6 | | | 406 |------------------->| | | 407 | ACK F7 | | | 408 |<-------------------| | | 409 | RTP | | | 410 |<==================>| | | 411 | | | | 412 | SUBSCRIBE sip:Conf-ID F8 | | 413 |------------------->| | | 414 | 200 OK F9 | | | 416 |<-------------------| | | 417 | NOTIFY F10 | | | 418 |<-------------------| | | 419 | 200 OK F11 | | | 420 |------------------->| | | 422 Figure 3. A Participant Creates a Conference using an Application. 424 4.4 Creating a Conference by a Conference-Unaware UA 426 It is a requirement that a user (human) be able to use a 427 conference-unaware UA to create and add participants to a conference. 429 A user (human) would choose a conference URI according to system 430 rules and insert it into the Request-URI of the INVITE. This same URI 431 is echoed by a focus adhering to certain addressing conventions 432 (discussed below) in the Contact header by the focus. Additional 433 participants could be added by non-SIP means (publication of the 434 chosen conference URI using web pages, email, IM, etc.). 435 Alternatively, the conference-unaware UA could then add other 436 participants to the conference using SIP call control by establishing 437 a session with them, then transferring [16] them to the conference 438 URI. Note that in this scenario only the user (human) is aware of 439 the conferencing application, and the conference-unaware UA only need 440 support RFC 3261 and optionally call transfer. 442 Making this work does impose certain addressing conventions on a 443 system. As a service/implementation choice, a system could allow the 444 creator of the conference to choose the user portion of the 445 conference URI. However, this requires the URI format to be agreed 446 upon between a user and the system. 448 For example, a service provider might reserve the domain 449 conf.example.com for all conference URIs. Any URI in the domain of 450 conf.example.com would resolve to the focus. The focus could be 451 configured to interpret an unknown user part in the conf.example.com 452 domain as a request for a conference to be created with the 453 conference URI as the Request-URI. For example, an INVITE sent with 454 a Request-URI of sip:k32934208ds72@conf.example.com could be routed 455 to the focus that would then create the conference. This conference 456 URI should be registered by the newly created focus to become 457 routable as a conference URI within the conf.example.com domain. The 458 returned Contact would look as follows: 460 Contact: ;isfocus 462 Note, however, that this approach relies on conventions adopted 463 between the user (human) and the focus. Also, the approach is not 464 robust against collisions in the conference names. If a second user 465 wishing to create a new conference happened to choose the same user 466 part as an existing conference, the result would be that the second 467 user would be added into the existing conference instead of creating 468 a new one. 470 As a result, methods of conference creation in which the conference 471 URI is an opaque URI generated by the focus are preferred. 473 An example call flow is shown in Figure 4. The participant Alice 474 creates the conference URI (using some convention agreed to with the 475 focus domain) and sends an INVITE to that URI which creates the 476 focus. The focus creates the conference and returns the same 477 conference URI in the 200 OK answer to the INVITE (which is ignored 478 by the conference-unaware UA). 480 Alice Focus Bob Carol 481 | | | | 482 | Alice creates the conference and chooses the conference URI. | 483 | | | | 484 | INVITE sip:Conf-ID F1 | | 485 |------------------->| | | 486 | 180 Ringing F2 | | | 487 |<-------------------| | | 488 | 200 OK Contact:Conf-ID;isfocus F3 | | 489 |<-------------------| | | 490 | ACK F4 | | | 491 |------------------->| | | 492 | RTP | | | 493 |<==================>| | | 495 Figure 4. A Conferencing Unaware Participant Creates a Conference 497 4.5 Creating a Conference using Ad-Hoc SIP Methods 499 This section addresses creating a conference by using ad-hoc SIP 500 means. The conference factory URI (as defined in Section 2.4) is 501 used to automatically create the conference in this example. 503 The benefit of this approach is that the conference URI need not be 504 known to the user - instead it is created by a focus and used by the 505 participants' UAs. The main difference between this scenario and 506 Section 4.3 is that no user intervention (IVR, web page form, etc.) 507 is required to create the conference. 509 The SIP URI of the conference factory can be provisioned in the UA 510 (as in a "create new conference" button on a SIP phone) or can be 511 discovered using other means. 513 A SIP entity (such as conferencing server) can distinguish this 514 INVITE request as a request to create a new ad-hoc conference from a 515 request to join an existing conference by the Request-URI. 517 Assuming that all security and policy requirements have been met, a 518 new conference will be created with the Contact URI returned in the 519 200 OK being the conference URI. The Contact header field MUST 520 contain the "isfocus" feature parameter to indicate that this URI is 521 for a conference. 523 An example call flow is shown in Figure 5. Note that Conf-Factory is 524 shorthand for the conference factory URI and Conf-ID Is short for the 525 conference URI. In this flow, Alice has a conference-aware UA and 526 creates a conference by sending an INVITE to the conference factory 527 URI. The conference factory application creates the conference and 528 redirects using a 302 Moved Temporarily response to the focus. Note 529 that with proxy recursion, Alice may never see the redirect but may 530 just receive the responses from the focus starting with message F5. 531 Once the media session is established, Alice subscribes to the 532 conference URI obtained through the Contact in the 200 OK response 533 from the focus. 535 Alice Conf-Factory App Focus Bob 536 | | | | 537 | Alice creates the conference. | | 538 | | | | 539 | INVITE sip:Conf-Factory F1 | | 540 |------------------->| | | 541 | 302 Moved Contact:Conf-ID;isfocus F2 | | 542 |<-------------------| | | 543 | ACK F3 | | | 544 |------------------->| | | 545 | INVITE sip:Conf-ID F4 | | 546 |---------------------------------------->| | 547 | 180 Ringing F5 | | 548 |<----------------------------------------| | 549 | 200 OK Contact:Conf-ID;isfocus F6 | | 550 |<----------------------------------------| | 551 | ACK F7 | | 552 |---------------------------------------->| | 553 | RTP | | 554 |<=======================================>| | 555 | | | 556 | Alice subscribes to the conference URI. | | 557 | | | 558 | SUBSCRIBE sip:Conf-ID F8 | | 559 |---------------------------------------->| | 560 | 200 OK F9 | | 561 |<----------------------------------------| | 562 | NOTIFY F10 | | 563 |<----------------------------------------| | 564 | 200 OK F11 | | 565 |---------------------------------------->| | 567 Figure 5. Creation of a Conference using SIP Ad-Hoc Methods. 569 4.6 Requesting the Focus Add a New Resource to a Conference 571 A SIP conference URI can be used to inject different kinds of 572 information into the conference. Examples include new participants, 573 new real-time media sources, new IM messages, and pointers to passive 574 information references (such as HTTP URIs). 576 To request the focus add a new information resource to the specified 577 conference, any SIP UA can send a REFER to the conference URI with a 578 Refer-To containing the URI of the new resource. Since this REFER is 579 sent to the conference URI and not the conference factory URI, the 580 semantics to the focus are to bring the resource into the conference 581 and make it visible to the conference participants. The resultant 582 focus procedures are dependant both on the nature of the new resource 583 (as expressed by its URI) and the own focus policies regarding IM, 584 central vs. distributed real time media processing, etc. 586 The scenario for adding a new UA participant is important to support 587 because it works even if the new participant does not support REFER 588 and transfer call control - only the requesting participant and the 589 focus need to support the REFER and transfer call control. 591 Upon receipt of the REFER containing a Refer-To header with a SIP 592 URI, the focus SHOULD send an INVITE to the new participant 593 identified by the Refer-To SIP URI containing a Contact header field 594 with the conference URI and the "isfocus" feature parameter. 596 A conference-unaware UA would simply ignore the conferencing 597 information and treat the session (from a SIP perspective) as a point 598 to point session. 600 An example call flow is shown in Figure 6. It is assumed that Alice 601 is already a participant of the conference. Alice sends a REFER to 602 the conference URI. The focus invites Carol to the conference by 603 sending an INVITE. After the session is established, Carol 604 subscribes to the conference URI. It is important to note that 605 there is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to 606 Alice (F15) - they occur asynchronously and independently. 608 Alice Focus Bob Carol 609 | | | | 610 |<==================>| | | 611 | REFER sip:Conf-ID Refer-To:Carol F1 | | 612 |------------------->| | 613 | 202 Accepted F2 | | 614 |<-------------------| | 615 | NOTIFY (Trying) F3 | 616 |<-------------------| | 617 | 200 OK F4 | | 618 |------------------->| | 619 | | | 620 | Focus "dials out" to join Carol to the conference | 621 | | | 622 | | INVITE Contact:Conf-ID;isfocus F5 | 623 | |---------------------------------------->| 624 | | 180 Ringing F6 | 625 | |<----------------------------------------| 626 | | 200 OK F7 | 627 | |<----------------------------------------| 628 | | ACK F8 | 629 | |---------------------------------------->| 630 | | RTP | 631 | |<=======================================>| 632 | NOTIFY (OK) F9 | | 633 |<-------------------| | 634 | 200 OK F10 | | 635 |------------------->| | 636 | | SUBSCRIBE sip:Conf-ID F11 | 637 | |<----------------------------------------| 638 | | 200 OK F12 | 639 | |---------------------------------------->| 640 | | NOTIFY F13 | 641 | |---------------------------------------->| 642 | | 200 OK F14 | 643 | |<----------------------------------------| 644 | NOTIFY F15 | | 645 |<-------------------| | 646 | 200 OK F16 | | 647 |------------------->| | 649 Figure 6. Participant Requests Focus add a Participant to the Conference. 651 4.7 Adding a 3rd Party Using Conference URI 653 A participant wishing to add a new participant will request this 654 participant to send an INVITE to the conference URI. This can be 655 done using a non-SIP means (such as passing or publishing the 656 conference URI in an email, IM, or web page). If a non-SIP means is 657 used, then the flow and requirements are identical to Section 4.1. 659 The SIP mechanism to do this utilizes the REFER method. 661 A UA wishing to add a new participant SHOULD send a REFER request to 662 the participant with a Refer-To header containing the conference URI. 664 The requirements are then identical to the "dial in" case of Section 665 4.1. The inviting participant MAY receive notification through the 666 REFER action that the new participant has been added in addition to 667 the notification received through the conference package. 669 An example is shown in Figure 7. In this call flow, it is assumed 670 that Alice is already a participant of the conference. Alice sends 671 Bob an "out of band" REFER - that is, a REFER outside of an 672 established dialog. Should Bob reject the REFER, Alice might try 673 sending an INVITE to Bob to establish a session first, then send a 674 REFER within the dialog, effectively transferring Bob into the 675 conference [16]. 677 Alice Focus Bob Carol 678 | | | | 679 |<==================>| | | 680 | | | | 681 | Alice adds Bob into conference | | 682 | | | | 683 | REFER Refer-To:Conf-ID F1 | | 684 |---------------------------------------->| | 685 | 202 Accepted F2 | | | 686 |<----------------------------------------| | 687 | NOTIFY (Trying) F3| | | 688 |<----------------------------------------| | 689 | 200 OK F4 | | | 690 |---------------------------------------->| | 691 | | INVITE sip:Conf-ID F5 | 692 | |<-------------------| | 693 | | 180 Ringing F6 | | 694 | |------------------->| | 695 | | 200 OK Contact:Conf-ID;isfocus F7 | 696 | |------------------->| | 697 | | ACK F8 | | 698 | |<-------------------| | 699 | | RTP | | 700 | |<==================>| | 701 | NOTIFY (OK) F9 | | | 702 |<----------------------------------------| | 703 | 200 OK F10 | | | 704 |---------------------------------------->| | 705 | NOTIFY F11 | | | 706 |<-------------------| | | 707 | 200 OK F12 | | | 708 |------------------->| | | 709 | | SUBSCRIBE sip:Conf-ID F13 | 710 | |<-------------------| | 711 | | 200 OK F14 | | 712 | |------------------->| | 713 | | NOTIFY F15 | | 714 | |------------------->| | 715 | | 200 OK F16 | | 716 | |<-------------------| | 718 Figure 7. Adding a Participant to an Existing Conference. 720 4.8 Adding a 3rd Party Using a Dialog Identifier 722 Under some circumstances, a participant wanting to join a conference 723 may only know a dialog identifier of one of the legs of the 724 conference and the conference factory URI, instead of the conference 725 URI. The information may have been learned using the dialog package 726 [17] or some non-SIP means to retrieve this information from a 727 conference participant. 729 A UA can request to be added to a conference by sending a request to 730 the focus containing a Join [6] header field containing a dialog ID 731 of one leg of the conference (a dialog between a participant and the 732 focus). 734 There are other scenarios in which a UA can use the Join header for 735 certain conferencing call control scenarios. See [6] for further 736 examples and details. 738 An example is shown in Figure 8. It is assumed that Alice is a 739 participant of the conference. The dialog identifier between Alice 740 and the focus is abbreviated as A-F and is known by Bob. Bob 741 requests to be added to the conference by sending an INVITE message 742 F1 to the focus containing a Join header which contains the dialog 743 identifier A-F. Note that this dialog identifier could be learned 744 through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the 745 dialog event package [17]. Bob is added into the conference by the 746 focus. 748 Alice Focus Bob Carol 749 | | | | 750 |<==================>| | | 751 | | | | 752 | Bob requests to be added to the conference. | 753 | | | | 754 | | INVITE Join:A-F F1| | 755 | |<-------------------| | 756 | | 180 Ringing F2 | | 757 | |------------------->| | 758 | | 200 OK Contact:Conf-ID;isfocus F3 | 759 | |------------------->| | 760 | | ACK F4 | | 761 | |<-------------------| | 762 | | RTP | | 763 | |<==================>| | 764 | | SUBSCRIBE sip:Conf-ID F5 | 765 | |<-------------------| | 766 | | 200 OK F6 | | 767 | |------------------->| | 768 | | NOTIFY F7 | | 769 | |------------------->| | 770 | | 200 OK F8 | | 771 | |<-------------------| | 773 Figure 8. Adding a Participant to an Existing Conference using Join. 775 4.9 Changing User Agents within a Conference 777 A participant in a conference may want to change the user agent with 778 which they participate in the conference. While this could be done 779 by simply sending a BYE from one user agent to leave the conference 780 and an INVITE from the other user agent to rejoin. However, the SIP 781 Replaces [6] primitive is perfectly suited to this operation. 783 An example is shown in Figure 9. It is assumed that Alice is a 784 participant of the conference using user agent #1. The dialog 785 identifier between Alice's user agent #1 and the focus is abbreviated 786 as A-F. Alice switches to user agent #2 and sends an INVITE message 787 F1 to the focus containing a Replaces header which contains the 788 dialog identifier A-F. Note that this dialog identifier could be 789 learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY 790 and the dialog event package [17]. Alice's user agent #2 is added 791 into the conference by the focus. The focus sends a BYE to user 792 agent #1. User agent #1 then automatically terminates the 793 subscription by sending a SUBSCRIBE with Expires:0 to terminate the 794 subscription. Note that as the participant list (roster) has not 795 changed during this scenario, no NOTIFYs are sent by the focus to 796 subscribers to the participant list. 798 Alice UA#1 Focus Alice UA#2 Carol 799 | | | | 800 |<==================>| | | 801 | | | | 802 | Alice switches user agents during the conference. | 803 | | | | 804 | | INVITE sip:Conf-ID Replaces:A-F F1 | 805 | |<-------------------| | 806 | | 200 OK Contact:Conf-ID;isfocus F2 | 807 | |------------------->| | 808 | | ACK F3 | | 809 | |<-------------------| | 810 | | RTP | | 811 | |<==================>| | 812 | BYE F4 | | | 813 |<-------------------| | | 814 | 200 OK F5 | | | 815 |------------------->| | | 816 | SUBSCRIBE Expires:0 F6 | | 817 |------------------->| | | 818 | 200 OK F7 | | | 819 |<-------------------| | | 820 | NOTIFY Subscription-State:terminated F8 | | 821 |<-------------------| | | 822 | 200 OK F9 | | | 823 |------------------->| | | 824 | | SUBSCRIBE sip:Conf-ID F10 | 825 | |<-------------------| | 826 | | 200 OK F11 | | 827 | |------------------->| | 828 | | NOTIFY F12 | | 829 | |------------------->| | 830 | | 200 OK F13 | | 831 | |<-------------------| | 833 Figure 9. Adding a Participant to an Existing Conference using Join. 835 4.10 Bringing a Point-to-Point Dialog into a Conference 837 A focus is capable of bringing an existing point-to-point dialog with 838 another UA to a conference that the focus hosts. The focus would do 839 it by sending re-INVITE changing the Contact URI to the conference 840 URI with the "isfocus" feature parameter. By doing this, the focus 841 signals to the UA that it becomes a participant of the conference, 842 specified in the Contact header. 844 Currently, there is no way for a UA, being in an active 845 point-to-point call with a focus, to express by SIP call control 846 means a request to bridge its dialog with a specific conference or to 847 create a new conference and include the dialog in this conference. 848 Instead, a new dialog will need to be created. Even if the UA 849 discovers that the other side has focus capabilities, the UA needs to 850 close the old session and to establish a new session/dialog with the 851 focus. 853 4.11 Requesting the Focus Remove a Participant from a Conference 855 To request the focus remove a participant from the specified 856 conference, a properly authorized SIP UA (typically the conference 857 owner) can send a REFER to the conference URI with a Refer-To 858 containing the URI of the participant and with the method set to BYE. 859 The requestor does not need to know the dialog information about the 860 dialog between the focus and the participant who will be removed - 861 the focus knows this information and fills it when it generates the 862 BYE request. 864 An example call flow is shown in Figure 10. It is assumed that Alice 865 and Carol are already participants of the conference and that Alice 866 is authorized to remove members from the conference. Alice sends a 867 REFER to the conference URI with a Refer-To header containing a URI 868 of the form <sip:carol@chicago.example.com&method=BYE>. 870 Alice Focus Bob Carol 871 | | | | 872 |<==================>| | 873 | REFER sip:Conf-ID Refer-To:Carol?method=BYE F1 | 874 |------------------->| | 875 | 202 Accepted F2 | | 876 |<-------------------| | 877 | NOTIFY (Trying) F3 | 878 |<-------------------| | 879 | 200 OK F4 | | 880 |------------------->| | 881 | | | 882 | Focus removes Carol from the conference | 883 | | | 884 | | BYE sip:Carol F5 | 885 | |---------------------------------------->| 886 | | 200 OK F6 | 887 | |<----------------------------------------| 888 | | NOTIFY Subscription-State:terminated F7 | 889 | |---------------------------------------->| 890 | | 200 OK F8 | 891 | |<----------------------------------------| 892 | NOTIFY (OK) F9 | | 893 |<-------------------| | 894 | 200 OK F10 | | 895 |------------------->| | 896 | NOTIFY F11 | | 897 |<-------------------| | 898 | 200 OK F12 | | 899 |------------------->| | 901 Figure 10. Participant Requests Focus Remove a Participant from the Conference. 903 4.12 Discovery of Conferencing Capabilities using OPTIONS 905 A UA MAY send an OPTIONS request to discover if an opaque URI is a 906 conference URI (resolves to a focus). In addition, the reply to the 907 OPTIONS request can also indicate support for various SIP call 908 control extensions used in this document. 910 Note that the Allow, Accept, Allow-Events, and Supported header 911 fields should be present in an INVITE from a focus or a 200 OK answer 912 from the focus to an INVITE as a part of a normal dialog 913 establishment process. 915 An example is shown in Figure 11 where Alice sends an OPTIONS to a 916 URI which resolves to a focus. 918 Alice Focus Bob Carol 919 | | | | 920 | OPTIONS sip:Conf-ID F1 | | 921 |------------------->| | | 922 | 200 OK Contact:Conf-ID;isfocus F2 | | 923 |<-------------------| | | 925 Figure 11. Participant Queries Capabilities of URI which resolves to a Focus. 927 Following is an example message detail of message F2 in Figure 11. 928 Based on the response, Alice's UA learns that the URI is a conference 929 URI and that the responding UA is focus that supports a number of SIP 930 call control extensions. 932 The response details are as follows: 934 SIP/2.0 200 OK 935 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 936 ;received=192.0.2.4 937 To: ;tag=93810874 938 From: Alice ;tag=1928301774 939 Call-ID: a84b4c76e66710 940 CSeq: 63104 OPTIONS 941 Contact: ;isfocus 942 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 943 SUBSCRIBE, NOTIFY 944 Allow-Events: refer, conference 945 Accept: application/sdp, application/conference-info+xml, 946 message/sipfrag 947 Accept-Language: en 948 Supported: replaces 949 Content-Type: application/sdp 950 Content-Length: 274 952 (SDP not shown) 954 Useful information from each of these headers is detailed in the next 955 sections. 957 Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY 958 indicate that the user agent supports call control and SIP Events. 960 Accept. The support of bodies such as message/sipfrag [13], 961 application/conference-info+xml [5] also indicates support of call 962 control and conferencing. 964 Allow-Events. The support of event packages such as refer [3], 965 conference [5]. 967 Supported. The support of extensions such as replaces [8]. 969 Contact. The presence of the "isfocus" feature parameter in the 970 Contact header indicates that the URI is a conference URI and that 971 the UA is a focus. 973 5. Security Considerations 975 This document discusses call control for SIP conferencing. Both call 976 control and conferencing have specific security requirements which 977 will be summarized here. Conferences generally have authorization 978 rules about who may or may not join a conference, what type of media 979 may or may not be used, etc. This information is used by the Focus 980 to admit or deny participation in a conference. It is recommended 981 that these types of authorization rules be used to provide security 982 for a SIP conference. For this authorization information to be used, 983 the focus needs to be able to authenticate potential participants. 984 Normal SIP mechanisms including Digest authentication and 985 certificates can be used. These conference specific security 986 requirements are discussed further in the requirements and framework 987 documents. 989 For call control security, a user agent must maintain local policy on 990 who is permitted to perform call control operations, initiate REFERs, 991 and replace dialogs. Normal SIP authentication mechanisms are also 992 appropriate here. The specific authentication and authorization 993 schemes are described in the multiparty call control framework 994 document. 996 6. Contributors 998 We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, 999 Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others 1000 in list discussions. 1002 7. Changes since -00 1004 - Showed separation between conference factory application and focus 1005 by having the application redirect to the newly created focus in the 1006 ad-hoc creation scenario. 1008 - Removed inclusion of "isfocus" parameter in Refer-To header field - 1009 this may be a useful extension to the REFER mechanism in the future, 1010 however. 1012 - Updated reference from Caller Prefs document to the new 1013 Capabilities of User Agents document. 1015 - Added scenario of participant changing user agents during a 1016 conference. 1018 - Added requirement on focus to support Replaces header field. 1020 - Added discussion about termination of dialog using BYE and 1021 subscription using SUBSCRIBE/NOTIFY to flows involving termination of 1022 session with the focus. 1024 Normative References 1026 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1027 Levels", BCP 14, RFC 2119, March 1997. 1029 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1030 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1032 Session Initiation Protocol", RFC 3261, June 2002. 1034 [3] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 1035 (work in progress), December 2002. 1037 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1038 Notification", RFC 3265, June 2002. 1040 [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol 1041 (SIP) Event Package for Conference State", 1042 draft-ietf-sipping-conference-package-00 (work in progress), 1043 June 2002. 1045 [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 1046 'Join' Header", draft-ietf-sip-join-01 (work in progress), March 1047 2003. 1049 [7] Rosenberg, J., "Indicating User Agent Capabilities in the 1050 Session Initiation Protocol (SIP)", 1051 draft-ietf-sip-callee-caps-00 (work in progress), June 2003. 1053 [8] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation 1054 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03 1055 (work in progress), March 2003. 1057 Informative References 1059 [9] Levin, O. and R. Even, "High Level Requirements for Tightly 1060 Coupled SIP Conferencing", 1061 draft-ietf-sipping-conferencing-requirements-00 (work in 1062 progress), April 2003. 1064 [10] Rosenberg, J., "A Framework for Conferencing with the Session 1065 Initiation Protocol", 1066 draft-ietf-sipping-conferencing-framework-00 (work in 1067 progress), May 2003. 1069 [11] Mahy, R., "A Call Control and Multi-party usage framework for 1070 the Session Initiation Protocol (SIP)", 1071 draft-ietf-sipping-cc-framework-02 (work in progress), March 1072 2003. 1074 [12] Campbell, B. and R. Sparks, "Control of Service Context using 1075 SIP Request-URI", RFC 3087, April 2001. 1077 [13] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1078 November 2002. 1080 [14] Johnston, A., "Session Initiation Protocol Basic Call Flow 1081 Examples", draft-ietf-sipping-basic-call-flows-02 (work in 1082 progress), April 2003. 1084 [15] Johnston, A. and S. Donovan, "Session Initiation Protocol 1085 Service Examples", draft-ietf-sipping-service-examples-04 (work 1086 in progress), March 2003. 1088 [16] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1089 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 1090 progress), February 2003. 1092 [17] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1093 Event Package for the Session Initiation Protocol (SIP", 1094 draft-ietf-sipping-dialog-package-01 (work in progress), March 1095 2003. 1097 Authors' Addresses 1099 Alan Johnston 1100 MCI 1101 100 South 4th Street 1102 St. Louis, MO 63102 1104 EMail: alan.johnston@mci.com 1106 Orit Levin 1107 RADVISION 1108 266 Harristown Road 1109 Glen Rock, NJ 75024 1111 EMail: orit@radvision.com 1113 Intellectual Property Statement 1115 The IETF takes no position regarding the validity or scope of any 1116 intellectual property or other rights that might be claimed to 1117 pertain to the implementation or use of the technology described in 1118 this document or the extent to which any license under such rights 1119 might or might not be available; neither does it represent that it 1120 has made any effort to identify any such rights. Information on the 1121 IETF's procedures with respect to rights in standards-track and 1122 standards-related documentation can be found in BCP-11. Copies of 1123 claims of rights made available for publication and any assurances of 1124 licenses to be made available, or the result of an attempt made to 1125 obtain a general license or permission for the use of such 1126 proprietary rights by implementors or users of this specification can 1127 be obtained from the IETF Secretariat. 1129 The IETF invites any interested party to bring to its attention any 1130 copyrights, patents or patent applications, or other proprietary 1131 rights which may cover technology that may be required to practice 1132 this standard. Please address the information to the IETF Executive 1133 Director. 1135 Full Copyright Statement 1137 Copyright (C) The Internet Society (2003). All Rights Reserved. 1139 This document and translations of it may be copied and furnished to 1140 others, and derivative works that comment on or otherwise explain it 1141 or assist in its implementation may be prepared, copied, published 1142 and distributed, in whole or in part, without restriction of any 1143 kind, provided that the above copyright notice and this paragraph are 1144 included on all such copies and derivative works. However, this 1145 document itself may not be modified in any way, such as by removing 1146 the copyright notice or references to the Internet Society or other 1147 Internet organizations, except as needed for the purpose of 1148 developing Internet standards in which case the procedures for 1149 copyrights defined in the Internet Standards process must be 1150 followed, or as required to translate it into languages other than 1151 English. 1153 The limited permissions granted above are perpetual and will not be 1154 revoked by the Internet Society or its successors or assignees. 1156 This document and the information contained herein is provided on an 1157 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1158 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1159 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1160 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1161 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1163 Acknowledgment 1165 Funding for the RFC Editor function is currently provided by the 1166 Internet Society.