idnits 2.17.1 draft-ietf-sipping-cc-conferencing-03.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 6 instances of too long lines in the document, the longest one being 10 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 (February 15, 2004) is 7375 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 1292, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1353, 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-02 == Outdated reference: A later version (-03) exists of draft-ietf-sip-join-02 == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-00 == 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-01 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-03 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-05 == 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-03 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 2 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: August 15, 2004 O. Levin 5 Microsoft 6 February 15, 2004 8 Session Initiation Protocol Call Control - Conferencing for User 9 Agents 10 draft-ietf-sipping-cc-conferencing-03 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 August 15, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). 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 . . . . . . . . 10 64 4.3 Manually Creating a Conference by Dialing into a 65 Conferencing Application . . . . . . . . . . . . . . . . . . 12 66 4.4 Creating a Conference by a Conference-Unaware UA . . . . . . 14 67 4.5 Creating a Conference using Ad-Hoc SIP Methods . . . . . . . 16 68 4.6 Requesting the Focus Add a New Resource to a Conference . . 17 69 4.7 Adding a 3rd Party Using Conference URI . . . . . . . . . . 20 70 4.8 Adding a 3rd Party Using a Dialog Identifier . . . . . . . . 21 71 4.9 Changing User Agents within a Conference . . . . . . . . . . 23 72 4.10 Bringing a Point-to-Point Dialog into a Conference . . . . . 24 73 4.11 Requesting the Focus Remove a Participant from a 74 Conference . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 4.12 Discovery of Conferencing Capabilities using OPTIONS . . . . 27 76 5. Security Considerations . . . . . . . . . . . . . . . . . . 29 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 78 7. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 29 79 8. Changes since -01 . . . . . . . . . . . . . . . . . . . . . 30 80 9. Changes since -00 . . . . . . . . . . . . . . . . . . . . . 30 81 Normative References . . . . . . . . . . . . . . . . . . . . 30 82 Informative References . . . . . . . . . . . . . . . . . . . 31 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 84 Intellectual Property and Copyright Statements . . . . . . . 33 86 1. Introduction 88 This document uses the concepts and definitions from the high level 89 requirements [10] and the SIP conferencing framework [11] documents. 91 The approach described in this document implements key functions in 92 the conferencing framework using SIP primitives only. This allows for 93 conducting simple conferences with defined functionalities using SIP 94 mechanisms and conventions. Many other advanced functions can be 95 implemented using additional means but they are not in the scope of 96 this document. 98 This document presents the basic call control (dial-in and dial-out) 99 conferencing building blocks from the UA perspective. Possible 100 applications include ad-hoc conferences and scheduled conferences. 102 Note that a single conference can bridge participants having 103 different capabilities and who potentially have joined the conference 104 by different means (i.e. dial-in, dial-out, scheduled, and ad-hoc). 106 The call control and dialog manipulation approach is based on the 107 multiparty framework [12] document. That document defines the basic 108 approach of service design adopted for SIP which includes: 110 - Definition of primitives, not services 111 - Signaling model independent 112 - Invoker oriented 113 - Primitives make full use of URIs 114 - Include authentication, authorization, logging, etc. policies 115 - Define graceful fallback to baseline SIP. 117 The use of opaque URIs and the ability to communicate call control 118 context information within a URI (as opposed to service-related 119 header fields), as discussed in RFC 3087 [13], is fundamental to this 120 approach. 122 2. Usage of the 'isfocus' Feature Parameter 124 2.1 General 126 The main design guidelines for the development of SIP extensions and 127 conventions for conferencing are to define the minimum number of 128 extensions and to have seamless backwards compatibility with 129 conference-unaware SIP UAs. The minimal requirement for SIP is being 130 able to express that a dialog is a part of a certain conference 131 referenced to by a URI. As a result of these extensions, it is 132 possible to do the following using SIP: 134 - Create a conference 135 - Join a conference 136 - Invite a user to a conference 137 - Expel a user by third party 138 - Discover if a URI is a conference URI 140 The approach taken is to use the feature parameter "isfocus" to 141 express that a SIP dialog belongs to a conference. The use of 142 feature parameters in Contact header fields to describe the 143 characteristics and capabilities of a UA is described in the User 144 Agent Capabilities [7] document which includes the definition of the 145 "isfocus" feature parameter. 147 2.2 Session Establishment 149 In session establishment, a focus MUST include the "isfocus" feature 150 parameter in the Contact header field unless the focus wishes to hide 151 the fact that it is a focus. To a participant, the feature parameter 152 will be associated with the remote target URI of the dialog. It is 153 an indication to a conference-aware UA that the resulting dialog 154 belongs to a conference identified by the URI in the Contact header 155 field and that the call control conventions defined in this document 156 can be applied. 158 The Conference URI MUST meet the requirements to be a GRUU (Globally 159 Routable User Agent URI) as detailed in [9] 161 2.3 OPTIONS 163 Currently the only met requirement is: given an opaque URI, being 164 able to recognize whether it belongs to a certain conference (i.e. 165 meaning that it is a conference URI) or not. As with any other 166 OPTIONS request, it can be done either inside an active dialog or 167 outside a dialog. A focus MUST include the "isfocus" feature 168 parameter in a 200 OK response to an OPTIONS unless the focus wishes 169 to hide the fact that it is a focus. 171 3. SIP User Agent Conferencing Capability Types 173 From a conferencing perspective, the framework document outlines a 174 number of possible different SIP components such as 175 conference-unaware participant, conference-aware participant, and 176 focus. 178 This document applies the concepts above to the SIP call control part 179 of the conferencing components. It defines normative behavior of the 180 SIP UAs in various conferencing situations (referred later as 181 "scenarios"). 183 3.1 Focus UA 185 A focus, as defined in the framework, hosts a SIP conference and 186 maintains a SIP signaling relationship with each participant in the 187 conference. A focus contains a conference-aware user agent that 188 supports the conferencing call control conventions as defined in this 189 document. 191 A focus SHOULD support the conference package [5] and indicate so in 192 Allow-Events header fields in requests and responses. A focus MAY 193 include information about the conference in SDP message bodies sent. 195 A focus SHOULD support the Replaces [8] header field. 197 A user agent with focus capabilities could be implemented in end user 198 equipment and would be used for the creation of ad-hoc conferences. 200 A dedicated conferencing server, whose primary task is to 201 simultaneously host conferences of arbitrary type and size, may 202 allocate and publish a conference factory URI (as defined in the next 203 section) for creating an arbitrary number of ad-hoc conferences (and 204 subsequently their focuses) using SIP call control means. 206 3.2 Conference Factory URI 208 According to the framework, there are many ways in which a conference 209 can be created. These are open to the conferencing server 210 implementation policy and include non-automated means (such as IVR), 211 SIP, and a conference policy control protocol. 213 In order to automatically create an arbitrary number of ad-hoc 214 conferences (and subsequently their focuses) using SIP call control 215 means, a globally routable Conference Factory URI can be allocated 216 and published. 218 A successful attempt to establish a call to this URI would result in 219 the automatic creation a new conference and its focus. As a result, 220 note that the Conference Factory URI and the newly created focus URI 221 MAY resolve to different physical devices. 223 A scenario showing the use of the conference factory URI is shown in 224 Section 4.5. 226 3.3 Conference-Unaware UA 228 The simplest user agent can participate in a conference ignoring all 229 SIP conferencing-related information. The simplest user agent is able 230 to dial into a conference and to be invited to a conference. Any 231 conferencing information is optionally conveyed to/from it using 232 non-SIP means. Such a user agent would not usually host a conference 233 (at least, not using SIP explicitly). A conference-unaware UA needs 234 only to support RFC 3261 [2]. Call flows for conference-unaware UAs 235 are not shown in general in this document as they would be identical 236 to those in the SIP call flows [15] document. 238 3.4 Conference-Aware UA 240 A conference-aware user agent supports SIP conferencing call control 241 conventions defined in this document as a conference participant, in 242 addition to support of RFC 3261. 244 A conference-aware UA MUST recognize the "isfocus" feature parameter. 245 A conference-aware UA SHOULD support REFER [3], SIP events [4], and 246 the conferencing package [5]. 248 A conference-aware UA SHOULD subscribe to the conference package if 249 the "isfocus" parameter is in the remote target URI of a dialog and 250 if the conference package is listed by a focus in an Allow-Events 251 header field. 253 A conference-aware UA MAY render to the user any information about 254 the conference obtained from the SIP header fields and SDP fields 255 from the focus. 257 4. SIP Conferencing Primitives 259 The SIP conferencing call control flows presented in this section are 260 the call control building blocks for various SIP tight conferencing 261 applications as described in the conferencing requirements [10] and 262 framework [11] documents. The major design goal is that the same SIP 263 conferencing primitives would be used by user agents having different 264 conferencing capabilities and comprising different applications. 266 4.1 Joining a Conference using the Conference URI - Dial In 268 In this section a user knows the conference URI and "dials in" to 269 join this conference. 271 If the UA is the first participant of the conference to dial in, it 272 is likely that this INVITE will create the focus and hence the 273 conference. However, the conference URI must have been reserved 274 prior to its use. 276 If the conference is up and running already, the dialing-in 277 participant is joined to the conference by its focus. 279 To join an existing specific conference a UA SHOULD send an INVITE 280 with the Request-URI set to the conference URI. The focus MUST 281 include the "isfocus" feature parameter in the Contact header field 282 of the 200 OK response to the INVITE. 284 The SUBSCRIBE should be sent outside the INVITE-initiated dialog. 286 Participants leaving the conference send a BYE to the focus. If they 287 have a current subscription to the conference package, they also must 288 send a SUBSCRIBE with an Expires:0 header field to terminate both 289 dialogs. 291 An example call flow for joining a conference is shown in Figure 1. 293 Alice Focus Bob Carol 294 | | | 295 | | Carol joins the conference | 296 | | | 297 | | INVITE sip:Conf-ID F1 | 298 | |<----------------------------------------| 299 | | 180 Ringing F2 | 300 | |---------------------------------------->| 301 | | 200 OK Contact:Conf-ID;isfocus F3 | 302 | |---------------------------------------->| 303 | | ACK F4 | 304 | |<----------------------------------------| 305 | | RTP | 306 | |<=======================================>| 307 | | SUBSCRIBE sip:Conf-ID F5 | 308 | |<----------------------------------------| 309 | | 200 OK F6 | 310 | |---------------------------------------->| 311 | | NOTIFY F7 | 312 | |---------------------------------------->| 313 | | 200 OK F8 | 314 | |<----------------------------------------| 316 Figure 1. A Participant Joins a Conference using the Conference URI. 318 F1 INVITE sip:3402934234@example.com SIP/2.0 319 Via: SIP/2.0/UDP client.chicago.example.com 320 ;branch=z9hG4bKhjhs8ass83 321 Max-Forwards: 70 322 To: 323 From: Carol ;tag=32331 324 Call-ID: d432fa84b4c76e66710 325 CSeq: 45 INVITE 326 Contact: 327 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 328 SUBSCRIBE, NOTIFY 329 Allow-Events: dialog 330 Accept: application/sdp, message/sipfrag 331 Supported: replaces 332 Content-Type: application/sdp 333 Content-Length: 274 335 (SDP not shown) 337 F3 SIP/2.0 200 OK 338 Via: SIP/2.0/UDP client.chicago.example.com 339 ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 340 To: ;tag=733413 341 From: Carol ;tag=32331 342 Call-ID: d432fa84b4c76e66710 343 CSeq: 45 INVITE 344 Contact: ;isfocus 345 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 346 SUBSCRIBE, NOTIFY 347 Allow-Events: dialog, conference 348 Accept: application/sdp, application/conference-info+xml, 349 message/sipfrag 350 Supported: replaces, join, gruu 351 Content-Type: application/sdp 352 Content-Length: 274 354 v=0 355 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com 356 s=Example Subject 357 i=Example Conference Hosted by Example.com 358 u=http://conf.example.com/3402934234 359 e=3402934234@conf-help.example.com 360 p=+1-888-2934234 361 c=IN IP4 ms5.conf.example.com 362 t=0 0 363 m=audio 49170 RTP/AVP 0 364 m=video 51372 RTP/AVP 31 366 F5 SUBSCRIBE sip:3402934234@example.com SIP/2.0 367 Via: SIP/2.0/UDP client.chicago.example.com 368 ;branch=z9hG4bKdf334 369 Max-Forwards: 70 370 To: 371 From: Carol ;tag=43524545 372 Call-ID: k3l43id034ksereree 373 CSeq: 22 SUBSCRIBE 374 Contact: 375 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 376 SUBSCRIBE, NOTIFY 377 Event: conference 378 Accept: application/sdp, message/sipfrag 379 Supported: replaces 380 Content-Length: 0 382 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 383 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 384 Max-Forwards: 70 385 To: Carol ;tag=43524545 386 From: ;tag=a3343df32 387 Call-ID: k3l43id034ksereree 388 CSeq: 34321 NOTIFY 389 Contact: ;isfocus 390 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 391 SUBSCRIBE, NOTIFY 392 Event: conference 393 Accept: application/sdp, message/sipfrag 394 Subscription-State: active;expires=3600 395 Supported: replaces, join, gruu 396 Content-Type: application/conference-info+xml 397 Content-Length: ... 399 401 403 connected 404 dialed-in 405 406 RTP/AVP 407 583398 408 409 410 RTP/AVP 411 345212 412 413 414 tel:+18882934234 415 417 4.2 Adding a Participant by the Focus - Dial Out 419 To directly add a participant to a conference, a focus SHOULD send an 420 INVITE to the participant containing a Contact header field with the 421 conference URI and the "isfocus" feature parameter. 423 Note that a conference-unaware UA would simply ignore the 424 conferencing information and treat the session (from a SIP 425 perspective) as a point to point session. 427 An example call flow is shown in Figure 2. It is assumed that Alice 428 is already a participant of the conference. The focus invites Carol 429 to the conference by sending an INVITE. After the session is 430 established, Carol subscribes to the conference URI. It is important 431 to note that there is no dependency on Carol's SUBSCRIBE (F5) and the 432 NOTIFY to Alice (F9) - they occur asynchronously and independently. 434 Alice Focus Bob Carol 435 | | | | 436 |<==================>| | | 437 | | | 438 | Focus "dials out" to add Carol to the conference | 439 | | | 440 | | INVITE Contact:Conf-ID;isfocus F1 | 441 | |---------------------------------------->| 442 | | 180 Ringing F2 | 443 | |<----------------------------------------| 444 | | 200 OK F3 | 445 | |<----------------------------------------| 446 | | ACK F4 | 447 | |---------------------------------------->| 448 | | RTP | 449 | |<=======================================>| 450 | | SUBSCRIBE sip:Conf-ID F5 | 451 | |<----------------------------------------| 452 | | 200 OK F6 | 453 | |---------------------------------------->| 454 | | NOTIFY F7 | 455 | |---------------------------------------->| 456 | | 200 OK F8 | 457 | |<----------------------------------------| 458 | NOTIFY F9 | | 459 |<-------------------| | 460 | 200 OK F10 | | 461 |------------------->| | 463 Figure 2. A Focus "dials out" to Add a Participant to the Conference. 465 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 466 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 467 Max-Forwards: 70 468 To: Carol ;tag=43524545 469 From: ;tag=a3343df32 470 Call-ID: k3l43id034ksereree 471 CSeq: 34321 NOTIFY 472 Contact: ;isfocus 473 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 474 SUBSCRIBE, NOTIFY 475 Event: conference 476 Accept: application/sdp, message/sipfrag 477 Subscription-State: active;expires=3600 478 Supported: replaces, gruu 479 Content-Type: application/conference-info+xml 480 Content-Length: ... 482 484 486 connected 487 dialed-in 488 489 RTP/AVP 490 674231 491 492 493 RTP/AVP 494 213563 495 496 497 499 connected 500 dialed-out 501 502 RTP/AVP 503 583398 504 505 506 RTP/AVP 507 345212 508 509 510 tel:+18882934234 511 513 F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 514 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 515 Max-Forwards: 70 516 To: Alice ;tag=43524545 517 From: ;tag=a3343df32 518 Call-ID: 8820450524545 519 CSeq: 998 NOTIFY 520 Contact: ;isfocus 521 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 522 SUBSCRIBE, NOTIFY 523 Event: conference 524 Accept: application/sdp, message/sipfrag 525 Subscription-State: active;expires=2450 526 Supported: replaces, gruu 527 Content-Type: application/conference-info+xml 528 Content-Length: ... 530 532 534 connected 535 dialed-out 536 537 RTP/AVP 538 583398 539 540 541 RTP/AVP 542 345212 543 544 545 tel:+18882934234 546 548 4.3 Manually Creating a Conference by Dialing into a Conferencing 549 Application 551 In this section, a user sends an INVITE to a conference server 552 application. The application (such as an IVR system or a web page) 553 is implemented because the system requires additional input from the 554 user before it is able to create a conference. After a normal dialog 555 is established, additional information is received and the conference 556 together with its focus are created. At this point the conference 557 server MUST re-INVITE the user with the conference URI in Contact 558 with the "isfocus" feature parameter. 560 Alternatively, the additional information MAY be provided by the user 561 during an early dialog established. This could be accomplished by a 562 183 Session Progress response sent by the conferencing application. 563 After the conference is created, the conference URI MUST then be 564 returned in a Contact in the 200 OK. 566 An example call flow is shown in Figure 3. In this example, Alice 567 uses a conference application which is triggered when Alice sends an 568 INVITE to the conference application. In this example, Conf-App is 569 used to represent the conference application URI. Alice's 570 conference-aware UA learns of the existence of the conference from 571 the "isfocus" feature parameter and subscribes to the conference 572 package to receive notifications of the conference state. 574 Alice Focus Bob Carol 575 | | | | 576 | Alice establishes session with conference application. | 577 | | | | 578 | INVITE sip:Conf-App F1 | | 579 |------------------->| | | 580 | 180 Ringing F2 | | | 581 |<-------------------| | | 582 | 200 OK F3 | | | 583 |<-------------------| | | 584 | ACK F4 | | | 585 |------------------->| | | 586 | RTP | | | 587 |<==================>| | | 588 | | | | 589 | Alice uses the application to create the conference. | 590 | | | | 591 | INVITE Contact:Conf-ID;isfocus F5 | | 592 |<-------------------| | | 593 | 200 OK F6 | | | 594 |------------------->| | | 595 | ACK F7 | | | 596 |<-------------------| | | 597 | RTP | | | 598 |<==================>| | | 599 | | | | 600 | SUBSCRIBE sip:Conf-ID F8 | | 601 |------------------->| | | 602 | 200 OK F9 | | | 603 |<-------------------| | | 604 | NOTIFY F10 | | | 605 |<-------------------| | | 606 | 200 OK F11 | | | 607 |------------------->| | | 609 Figure 3. A Participant Creates a Conference using an Application. 611 4.4 Creating a Conference by a Conference-Unaware UA 613 It is a requirement that a user (human) be able to use a 614 conference-unaware UA to create and add participants to a conference. 616 A user (human) would choose a conference URI according to system 617 rules and insert it into the Request-URI of the INVITE. This same URI 618 is echoed by a focus adhering to certain addressing conventions 619 (discussed below) in the Contact header by the focus. Additional 620 participants could be added by non-SIP means (publication of the 621 chosen conference URI using web pages, email, IM, etc.). 622 Alternatively, the conference-unaware UA could then add other 623 participants to the conference using SIP call control by establishing 624 a session with them, then transferring [17] them to the conference 625 URI. Note that in this scenario only the user (human) is aware of 626 the conferencing application, and the conference-unaware UA only need 627 support RFC 3261 and optionally call transfer. 629 Making this work does impose certain addressing conventions on a 630 system. As a service/implementation choice, a system could allow the 631 creator of the conference to choose the user portion of the 632 conference URI. However, this requires the URI format to be agreed 633 upon between a user and the system. 635 For example, a service provider might reserve the domain 636 conf.example.com for all conference URIs. Any URI in the domain of 637 conf.example.com would resolve to the focus. The focus could be 638 configured to interpret an unknown user part in the conf.example.com 639 domain as a request for a conference to be created with the 640 conference URI as the Request-URI. For example, an INVITE sent with 641 a Request-URI of sip:k32934208ds72@conf.example.com could be routed 642 to the focus that would then create the conference. This conference 643 URI should be registered by the newly created focus to become 644 routable as a conference URI within the conf.example.com domain. The 645 returned Contact would look as follows: 647 Contact: ;isfocus 649 Note, however, that this approach relies on conventions adopted 650 between the user (human) and the focus. Also, the approach is not 651 robust against collisions in the conference names. If a second user 652 wishing to create a new conference happened to choose the same user 653 part as an existing conference, the result would be that the second 654 user would be added into the existing conference instead of creating 655 a new one. 657 As a result, methods of conference creation in which the conference 658 URI is an opaque URI generated by the focus are preferred. 660 An example call flow is shown in Figure 4. The participant Alice 661 creates the conference URI (using some convention agreed to with the 662 focus domain) and sends an INVITE to that URI which creates the 663 focus. The focus creates the conference and returns the same 664 conference URI in the 200 OK answer to the INVITE (which is ignored 665 by the conference-unaware UA). 667 Alice Focus Bob Carol 668 | | | | 669 | Alice creates the conference and chooses the conference URI. | 670 | | | | 671 | INVITE sip:Conf-ID F1 | | 672 |------------------->| | | 673 | 180 Ringing F2 | | | 674 |<-------------------| | | 675 | 200 OK Contact:Conf-ID;isfocus F3 | | 676 |<-------------------| | | 677 | ACK F4 | | | 678 |------------------->| | | 679 | RTP | | | 680 |<==================>| | | 682 Figure 4. A Conferencing Unaware Participant Creates a Conference 684 4.5 Creating a Conference using Ad-Hoc SIP Methods 686 This section addresses creating a conference by using ad-hoc SIP 687 means. The conference factory URI (as defined in Section 2.4) is 688 used to automatically create the conference in this example. 690 The benefit of this approach is that the conference URI need not be 691 known to the user - instead it is created by a focus and used by the 692 participants' UAs. The main difference between this scenario and 693 Section 4.3 is that no user intervention (IVR, web page form, etc.) 694 is required to create the conference. 696 The SIP URI of the conference factory can be provisioned in the UA 697 (as in a "create new conference" button on a SIP phone) or can be 698 discovered using other means. 700 A SIP entity (such as conferencing server) can distinguish this 701 INVITE request as a request to create a new ad-hoc conference from a 702 request to join an existing conference by the Request-URI. 704 Assuming that all security and policy requirements have been met, a 705 new conference will be created with the Contact URI returned in the 706 200 OK being the conference URI. The Contact header field MUST 707 contain the "isfocus" feature parameter to indicate that this URI is 708 for a conference. 710 An example call flow is shown in Figure 5. Note that Conf-Factory is 711 shorthand for the conference factory URI and Conf-ID Is short for the 712 conference URI. In this flow, Alice has a conference-aware UA and 713 creates a conference by sending an INVITE to the conference factory 714 URI. The conference factory application creates the conference and 715 redirects using a 302 Moved Temporarily response to the focus. Note 716 that with proxy recursion, Alice may never see the redirect but may 717 just receive the responses from the focus starting with message F5. 718 Once the media session is established, Alice subscribes to the 719 conference URI obtained through the Contact in the 200 OK response 720 from the focus. 722 Alice Conf-Factory App Focus Bob 723 | | | | 724 | Alice creates the conference. | | 725 | | | | 726 | INVITE sip:Conf-Factory F1 | | 727 |------------------->| | | 728 | 302 Moved Contact:Conf-ID;isfocus F2 | | 729 |<-------------------| | | 730 | ACK F3 | | | 731 |------------------->| | | 732 | INVITE sip:Conf-ID F4 | | 733 |---------------------------------------->| | 734 | 180 Ringing F5 | | 735 |<----------------------------------------| | 736 | 200 OK Contact:Conf-ID;isfocus F6 | | 737 |<----------------------------------------| | 738 | ACK F7 | | 739 |---------------------------------------->| | 740 | RTP | | 741 |<=======================================>| | 742 | | | 743 | Alice subscribes to the conference URI. | | 744 | | | 745 | SUBSCRIBE sip:Conf-ID F8 | | 746 |---------------------------------------->| | 747 | 200 OK F9 | | 748 |<----------------------------------------| | 749 | NOTIFY F10 | | 750 |<----------------------------------------| | 751 | 200 OK F11 | | 752 |---------------------------------------->| | 754 Figure 5. Creation of a Conference using SIP Ad-Hoc Methods. 756 4.6 Requesting the Focus Add a New Resource to a Conference 758 A SIP conference URI can be used to inject different kinds of 759 information into the conference. Examples include new participants, 760 new real-time media sources, new IM messages, and pointers to passive 761 information references (such as HTTP URIs). 763 To request the focus add a new information resource to the specified 764 conference, any SIP UA can send a REFER to the conference URI with a 765 Refer-To containing the URI of the new resource. Since this REFER is 766 sent to the conference URI and not the conference factory URI, the 767 semantics to the focus are to bring the resource into the conference 768 and make it visible to the conference participants. The resultant 769 focus procedures are dependant both on the nature of the new resource 770 (as expressed by its URI) and the own focus policies regarding IM, 771 central vs. distributed real time media processing, etc. 773 The scenario for adding a new UA participant is important to support 774 because it works even if the new participant does not support REFER 775 and transfer call control - only the requesting participant and the 776 focus need to support the REFER and transfer call control. 778 Upon receipt of the REFER containing a Refer-To header with a SIP 779 URI, the focus SHOULD send an INVITE to the new participant 780 identified by the Refer-To SIP URI containing a Contact header field 781 with the conference URI and the "isfocus" feature parameter. 783 A conference-unaware UA would simply ignore the conferencing 784 information and treat the session (from a SIP perspective) as a point 785 to point session. 787 An example call flow is shown in Figure 6. It is assumed that Alice 788 is already a participant of the conference. Alice sends a REFER to 789 the conference URI. The focus invites Carol to the conference by 790 sending an INVITE. After the session is established, Carol 791 subscribes to the conference URI. It is important to note that 792 there is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to 793 Alice (F15) - they occur asynchronously and independently. 795 Alice Focus Bob Carol 796 | | | | 797 |<==================>| | | 798 | REFER sip:Conf-ID Refer-To:Carol F1 | | 799 |------------------->| | 800 | 202 Accepted F2 | | 801 |<-------------------| | 802 | NOTIFY (Trying) F3 | 803 |<-------------------| | 804 | 200 OK F4 | | 805 |------------------->| | 806 | | | 807 | Focus "dials out" to join Carol to the conference | 808 | | | 809 | | INVITE Contact:Conf-ID;isfocus F5 | 810 | |---------------------------------------->| 811 | | 180 Ringing F6 | 812 | |<----------------------------------------| 813 | | 200 OK F7 | 814 | |<----------------------------------------| 815 | | ACK F8 | 816 | |---------------------------------------->| 817 | | RTP | 818 | |<=======================================>| 819 | NOTIFY (OK) F9 | | 820 |<-------------------| | 821 | 200 OK F10 | | 822 |------------------->| | 823 | | SUBSCRIBE sip:Conf-ID F11 | 824 | |<----------------------------------------| 825 | | 200 OK F12 | 826 | |---------------------------------------->| 827 | | NOTIFY F13 | 828 | |---------------------------------------->| 829 | | 200 OK F14 | 830 | |<----------------------------------------| 831 | NOTIFY F15 | | 832 |<-------------------| | 833 | 200 OK F16 | | 834 |------------------->| | 836 Figure 6. Participant Requests Focus add a Participant to the Conference. 838 F1 REFER sip:3402934234@example.com SIP/2.0 839 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 840 Max-Forwards: 70 841 To: 842 From: Alice ;tag=5534562 843 Call-ID: 849392fklgl43 844 CSeq: 476 REFER 845 Contact: 846 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 847 SUBSCRIBE, NOTIFY 848 Accept: application/sdp, message/sipfrag 849 Refer-To: 850 Supported: replaces 851 Content-Length: 0 853 4.7 Adding a 3rd Party Using Conference URI 855 A participant wishing to add a new participant will request this 856 participant to send an INVITE to the conference URI. This can be 857 done using a non-SIP means (such as passing or publishing the 858 conference URI in an email, IM, or web page). If a non-SIP means is 859 used, then the flow and requirements are identical to Section 4.1. 861 The SIP mechanism to do this utilizes the REFER method. 863 A UA wishing to add a new participant SHOULD send a REFER request to 864 the participant with a Refer-To header containing the conference URI. 866 The requirements are then identical to the "dial in" case of Section 867 4.1. The inviting participant MAY receive notification through the 868 REFER action that the new participant has been added in addition to 869 the notification received through the conference package. 871 An example is shown in Figure 7. In this call flow, it is assumed 872 that Alice is already a participant of the conference. Alice sends 873 Bob an "out of band" REFER - that is, a REFER outside of an 874 established dialog. Should Bob reject the REFER, Alice might try 875 sending an INVITE to Bob to establish a session first, then send a 876 REFER within the dialog, effectively transferring Bob into the 877 conference [17]. 879 Alice Focus Bob Carol 880 | | | | 881 |<==================>| | | 882 | | | | 883 | Alice adds Bob into conference | | 884 | | | | 885 | REFER Refer-To:Conf-ID F1 | | 886 |---------------------------------------->| | 887 | 202 Accepted F2 | | | 888 |<----------------------------------------| | 889 | NOTIFY (Trying) F3| | | 890 |<----------------------------------------| | 891 | 200 OK F4 | | | 892 |---------------------------------------->| | 893 | | INVITE sip:Conf-ID F5 | 894 | |<-------------------| | 895 | | 180 Ringing F6 | | 896 | |------------------->| | 897 | | 200 OK Contact:Conf-ID;isfocus F7 | 898 | |------------------->| | 899 | | ACK F8 | | 900 | |<-------------------| | 901 | | RTP | | 902 | |<==================>| | 903 | NOTIFY (OK) F9 | | | 904 |<----------------------------------------| | 905 | 200 OK F10 | | | 906 |---------------------------------------->| | 907 | NOTIFY F11 | | | 908 |<-------------------| | | 909 | 200 OK F12 | | | 910 |------------------->| | | 911 | | SUBSCRIBE sip:Conf-ID F13 | 912 | |<-------------------| | 913 | | 200 OK F14 | | 914 | |------------------->| | 915 | | NOTIFY F15 | | 916 | |------------------->| | 917 | | 200 OK F16 | | 918 | |<-------------------| | 920 Figure 7. Adding a Participant to an Existing Conference. 922 4.8 Adding a 3rd Party Using a Dialog Identifier 924 Under some circumstances, a participant wanting to join a conference 925 may only know a dialog identifier of one of the legs of the 926 conference. The information may have been learned using the dialog 927 package [18] or some non-SIP means to retrieve this information from 928 a conference participant. 930 A UA can request to be added to a conference by sending a request to 931 the focus containing a Join [6] header field containing a dialog ID 932 of one leg of the conference (a dialog between a participant and the 933 focus). 935 There are other scenarios in which a UA can use the Join header for 936 certain conferencing call control scenarios. See [6] for further 937 examples and details. 939 An example is shown in Figure 8. It is assumed that Alice is a 940 participant of the conference. The dialog identifier between Alice 941 and the focus is abbreviated as A-F and is known by Bob. Bob 942 requests to be added to the conference by sending an INVITE message 943 F1 to the focus containing a Join header which contains the dialog 944 identifier A-F. Bob is added into the conference by the focus. 946 Alice Focus Bob Carol 947 | | | | 948 |<==================>| | | 949 | | | | 950 | Bob requests to be added to the conference. | 951 | | | | 952 | | INVITE Join:A-F F1| | 953 | |<-------------------| | 954 | | 180 Ringing F2 | | 955 | |------------------->| | 956 | | 200 OK Contact:Conf-ID;isfocus F3 | 957 | |------------------->| | 958 | | ACK F4 | | 959 | |<-------------------| | 960 | | RTP | | 961 | |<==================>| | 962 | | SUBSCRIBE sip:Conf-ID F5 | 963 | |<-------------------| | 964 | | 200 OK F6 | | 965 | |------------------->| | 966 | | NOTIFY F7 | | 967 | |------------------->| | 968 | | 200 OK F8 | | 969 | |<-------------------| | 971 Figure 8. Adding a Participant to an Existing Conference using Join. 973 F1 INVITE sip:3402934234@example.com SIP/2.0 974 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832 975 Max-Forwards: 70 976 To: 977 From: Bob ;tag=32411 978 Call-ID: d432fa84b4c76e66710 979 CSeq: 8 INVITE 980 Contact: 981 Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331 982 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 983 SUBSCRIBE, NOTIFY 984 Allow-Events: dialog 985 Accept: application/sdp, message/sipfrag 986 Supported: replaces, join 987 Content-Type: application/sdp 988 Content-Length: 274 990 (SDP not shown) 992 4.9 Changing User Agents within a Conference 994 A participant in a conference may want to change the user agent with 995 which they participate in the conference. While this could be done 996 by simply sending a BYE from one user agent to leave the conference 997 and an INVITE from the other user agent to rejoin. However, the SIP 998 Replaces [6] primitive is perfectly suited to this operation. 1000 An example is shown in Figure 9. It is assumed that Alice is a 1001 participant of the conference using user agent #1. The dialog 1002 identifier between Alice's user agent #1 and the focus is abbreviated 1003 as A-F. Alice switches to user agent #2 and sends an INVITE message 1004 F1 to the focus containing a Replaces header which contains the 1005 dialog identifier A-F. Note that this dialog identifier could be 1006 learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY 1007 and the dialog event package [18]. Alice's user agent #2 is added 1008 into the conference by the focus. The focus sends a BYE to user 1009 agent #1. User agent #1 then automatically terminates the 1010 subscription by sending a SUBSCRIBE with Expires:0 to terminate the 1011 subscription. Note that as the participant list (roster) has not 1012 changed during this scenario, no NOTIFYs are sent by the focus to 1013 subscribers to the participant list. 1015 Alice UA#1 Focus Alice UA#2 Carol 1016 | | | | 1017 |<==================>| | | 1018 | | | | 1019 | Alice switches user agents during the conference. | 1020 | | | | 1021 | | INVITE sip:Conf-ID Replaces:A-F F1 | 1022 | |<-------------------| | 1023 | | 200 OK Contact:Conf-ID;isfocus F2 | 1024 | |------------------->| | 1025 | | ACK F3 | | 1026 | |<-------------------| | 1027 | | RTP | | 1028 | |<==================>| | 1029 | BYE F4 | | | 1030 |<-------------------| | | 1031 | 200 OK F5 | | | 1032 |------------------->| | | 1033 | SUBSCRIBE Expires:0 F6 | | 1034 |------------------->| | | 1035 | 200 OK F7 | | | 1036 |<-------------------| | | 1037 | NOTIFY Subscription-State:terminated F8 | | 1038 |<-------------------| | | 1039 | 200 OK F9 | | | 1040 |------------------->| | | 1041 | | SUBSCRIBE sip:Conf-ID F10 | 1042 | |<-------------------| | 1043 | | 200 OK F11 | | 1044 | |------------------->| | 1045 | | NOTIFY F12 | | 1046 | |------------------->| | 1047 | | 200 OK F13 | | 1048 | |<-------------------| | 1050 Figure 9. Adding a Participant to an Existing Conference using Join. 1052 4.10 Bringing a Point-to-Point Dialog into a Conference 1054 A focus is capable of bringing an existing point-to-point dialog with 1055 another UA to a conference that the focus hosts. The focus would do 1056 it by sending re-INVITE changing the Contact URI to the conference 1057 URI with the "isfocus" feature parameter. By doing this, the focus 1058 signals to the UA that it becomes a participant of the conference, 1059 specified in the Contact header. 1061 Currently, there is no way for a UA, being in an active 1062 point-to-point call with a focus, to express by SIP call control 1063 means a request to bridge its dialog with a specific conference or to 1064 create a new conference and include the dialog in this conference. 1065 Instead, a new dialog will need to be created. Even if the UA 1066 discovers that the other side has focus capabilities, the UA needs to 1067 close the old session and to establish a new session/dialog with the 1068 focus. 1070 4.11 Requesting the Focus Remove a Participant from a Conference 1072 To request the focus remove a participant from the specified 1073 conference, a properly authorized SIP UA (typically the conference 1074 owner) can send a REFER to the conference URI with a Refer-To 1075 containing the URI of the participant and with the method set to BYE. 1076 The requestor does not need to know the dialog information about the 1077 dialog between the focus and the participant who will be removed - 1078 the focus knows this information and fills it when it generates the 1079 BYE request. 1081 An example call flow is shown in Figure 10. It is assumed that Alice 1082 and Carol are already participants of the conference and that Alice 1083 is authorized to remove members from the conference. Alice sends a 1084 REFER to the conference URI with a Refer-To header containing a URI 1085 of the form <sip:carol@chicago.example.com&method=BYE>. 1087 Alice Focus Bob Carol 1088 | | | | 1089 |<==================>| | 1090 | REFER sip:Conf-ID Refer-To:Carol?method=BYE F1 | 1091 |------------------->| | 1092 | 202 Accepted F2 | | 1093 |<-------------------| | 1094 | NOTIFY (Trying) F3 | 1095 |<-------------------| | 1096 | 200 OK F4 | | 1097 |------------------->| | 1098 | | | 1099 | Focus removes Carol from the conference | 1100 | | | 1101 | | BYE sip:Carol F5 | 1102 | |---------------------------------------->| 1103 | | 200 OK F6 | 1104 | |<----------------------------------------| 1105 | | NOTIFY Subscription-State:terminated F7 | 1106 | |---------------------------------------->| 1107 | | 200 OK F8 | 1108 | |<----------------------------------------| 1109 | NOTIFY (OK) F9 | | 1110 |<-------------------| | 1111 | 200 OK F10 | | 1112 |------------------->| | 1113 | NOTIFY F11 | | 1114 |<-------------------| | 1115 | 200 OK F12 | | 1116 |------------------->| | 1118 Figure 10. Participant Requests Focus Remove a Participant from the Conference. 1120 F1 REFER sip:3402934234@example.com SIP/2.0 1121 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg45344 1122 Max-Forwards: 70 1123 To: 1124 From: Alice ;tag=5534562 1125 Call-ID: 849392fklgl43 1126 CSeq: 476 REFER 1127 Contact: 1128 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1129 SUBSCRIBE, NOTIFY 1130 Accept: application/sdp, message/sipfrag 1131 Refer-To: 1132 Supported: replaces 1133 Content-Length: 0 1135 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 1136 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 1137 Max-Forwards: 70 1138 From: ;tag=5393k2312 1139 To: Carol ;tag=32331 1140 Call-ID: d432fa84b4c76e66710 1141 CSeq: 78654 BYE 1142 Content-Length: 0 1144 4.12 Discovery of Conferencing Capabilities using OPTIONS 1146 A UA MAY send an OPTIONS request to discover if an opaque URI is a 1147 conference URI (resolves to a focus). In addition, the reply to the 1148 OPTIONS request can also indicate support for various SIP call 1149 control extensions used in this document. 1151 Note that the Allow, Accept, Allow-Events, and Supported header 1152 fields should be present in an INVITE from a focus or a 200 OK answer 1153 from the focus to an INVITE as a part of a normal dialog 1154 establishment process. 1156 An example is shown in Figure 11 where Alice sends an OPTIONS to a 1157 URI which resolves to a focus. 1159 Alice Focus Bob Carol 1160 | | | | 1161 | OPTIONS sip:Conf-ID F1 | | 1162 |------------------->| | | 1163 | 200 OK Contact:Conf-ID;isfocus F2 | | 1164 |<-------------------| | | 1166 Figure 11. Participant Queries Capabilities of URI which resolves to a Focus. 1168 Following is an example message detail of message F2 in Figure 11. 1169 Based on the response, Alice's UA learns that the URI is a conference 1170 URI and that the responding UA is focus that supports a number of SIP 1171 call control extensions. 1173 The response details are as follows: 1175 F2 SIP/2.0 200 OK 1176 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjhs8ass877 1177 ;received=192.0.2.4 1178 To: ;tag=93810874 1179 From: Alice ;tag=1928301774 1180 Call-ID: a84b4c76e66710 1181 CSeq: 63104 OPTIONS 1182 Contact: ;isfocus 1183 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 1184 SUBSCRIBE, NOTIFY 1185 Allow-Events: refer, conference 1186 Accept: application/sdp, application/conference-info+xml, 1187 message/sipfrag 1188 Accept-Language: en 1189 Supported: replaces, join, gruu 1190 Content-Type: application/sdp 1191 Content-Length: ... 1193 v=0 1194 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com 1195 s=Example Subject 1196 i=Example Conference Hosted by Example.com 1197 u=http://conf.example.com/3402934234 1198 e=3402934234@conf-help.example.com 1199 p=+18882934234 1200 c=IN IP4 ms5.conf.example.com 1201 t=0 0 1202 m=audio 49170 RTP/AVP 0 1 3 5 7 1203 m=video 51372 RTP/AVP 31 32 1205 Useful information from each of these headers is detailed in the next 1206 sections. 1208 Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY 1209 indicate that the user agent supports call control and SIP Events. 1211 Accept. The support of bodies such as message/sipfrag [14], 1212 application/conference-info+xml [5] also indicates support of call 1213 control and conferencing. 1215 Allow-Events. The support of event packages such as refer [3], 1216 conference [5]. 1218 Supported. The support of extensions such as replaces, join, and 1219 gruu. 1221 Contact. The presence of the "isfocus" feature parameter in the 1222 Contact header indicates that the URI is a conference URI and that 1223 the UA is a focus. 1225 5. Security Considerations 1227 This document discusses call control for SIP conferencing. Both call 1228 control and conferencing have specific security requirements which 1229 will be summarized here. Conferences generally have authorization 1230 rules about who may or may not join a conference, what type of media 1231 may or may not be used, etc. This information is used by the Focus 1232 to admit or deny participation in a conference. It is recommended 1233 that these types of authorization rules be used to provide security 1234 for a SIP conference. For this authorization information to be used, 1235 the focus needs to be able to authenticate potential participants. 1236 Normal SIP mechanisms including Digest authentication and 1237 certificates can be used. These conference specific security 1238 requirements are discussed further in the requirements and framework 1239 documents. 1241 For call control security, a user agent must maintain local policy on 1242 who is permitted to perform call control operations, initiate REFERs, 1243 and replace dialogs. Normal SIP authentication mechanisms are also 1244 appropriate here. The specific authentication and authorization 1245 schemes are described in the multiparty call control framework 1246 document. 1248 6. Contributors 1250 We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, 1251 Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others 1252 in list discussions. 1254 7. Changes since -02 1256 - Added reference and text about use of GRUUs. 1258 - Updated for latest version of conference package. 1260 - Clarified that conference package subscription should use a 1261 separate dialog from INVITE dialog. 1263 8. Changes since -01 1265 - Added messages details of selected INVITE, 200 OK, SUBSCRIBE, 1266 REFER, and NOTIFY messages. 1268 9. Changes since -00 1270 - Showed separation between conference factory application and focus 1271 by having the application redirect to the newly created focus in the 1272 ad-hoc creation scenario. 1274 - Removed inclusion of "isfocus" parameter in Refer-To header field - 1275 this may be a useful extension to the REFER mechanism in the future, 1276 however. 1278 - Updated reference from Caller Prefs document to the new 1279 Capabilities of User Agents document. 1281 - Added scenario of participant changing user agents during a 1282 conference. 1284 - Added requirement on focus to support Replaces header field. 1286 - Added discussion about termination of dialog using BYE and 1287 subscription using SUBSCRIBE/NOTIFY to flows involving termination of 1288 session with the focus. 1290 Normative References 1292 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1293 Levels", BCP 14, RFC 2119, March 1997. 1295 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1296 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1297 Session Initiation Protocol", RFC 3261, June 2002. 1299 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1300 Method", RFC 3515, April 2003. 1302 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1303 Notification", RFC 3265, June 2002. 1305 [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol 1306 (SIP) Event Package for Conference State", 1307 draft-ietf-sipping-conference-package-02 (work in progress), 1308 October 2003. 1310 [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 1311 'Join' Header", draft-ietf-sip-join-02 (work in progress), July 1312 2003. 1314 [7] Rosenberg, J., "Indicating User Agent Capabilities in the 1315 Session Initiation Protocol (SIP)", 1316 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 1318 [8] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation 1319 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-04 1320 (work in progress), August 2003. 1322 [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 1323 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 1324 draft-ietf-sip-gruu-00 (work in progress), January 2004. 1326 Informative References 1328 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 1329 Coupled SIP Conferencing", 1330 draft-ietf-sipping-conferencing-requirements-00 (work in 1331 progress), April 2003. 1333 [11] Rosenberg, J., "A Framework for Conferencing with the Session 1334 Initiation Protocol", 1335 draft-ietf-sipping-conferencing-framework-01 (work in 1336 progress), October 2003. 1338 [12] Mahy, R., "A Call Control and Multi-party usage framework for 1339 the Session Initiation Protocol (SIP)", 1340 draft-ietf-sipping-cc-framework-03 (work in progress), October 1341 2003. 1343 [13] Campbell, B. and R. Sparks, "Control of Service Context using 1344 SIP Request-URI", RFC 3087, April 2001. 1346 [14] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1347 November 2002. 1349 [15] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 1350 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 1351 Examples", BCP 75, RFC 3665, December 2003. 1353 [16] Johnston, A. and R. Sparks, "Session Initiation Protocol 1354 Service Examples", draft-ietf-sipping-service-examples-05 (work 1355 in progress), September 2003. 1357 [17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1358 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 1359 progress), February 2003. 1361 [18] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1362 Event Package for the Session Initiation Protocol (SIP)", 1363 draft-ietf-sipping-dialog-package-03 (work in progress), 1364 October 2003. 1366 Authors' Addresses 1368 Alan Johnston 1369 MCI 1370 100 South 4th Street 1371 St. Louis, MO 63102 1373 EMail: alan.johnston@mci.com 1375 Orit Levin 1376 Microsoft 1377 One Microsoft Way 1378 Redmond, WA 75024 1380 EMail: oritl@microsoft.com 1382 Intellectual Property Statement 1384 The IETF takes no position regarding the validity or scope of any 1385 intellectual property or other rights that might be claimed to 1386 pertain to the implementation or use of the technology described in 1387 this document or the extent to which any license under such rights 1388 might or might not be available; neither does it represent that it 1389 has made any effort to identify any such rights. Information on the 1390 IETF's procedures with respect to rights in standards-track and 1391 standards-related documentation can be found in BCP-11. Copies of 1392 claims of rights made available for publication and any assurances of 1393 licenses to be made available, or the result of an attempt made to 1394 obtain a general license or permission for the use of such 1395 proprietary rights by implementors or users of this specification can 1396 be obtained from the IETF Secretariat. 1398 The IETF invites any interested party to bring to its attention any 1399 copyrights, patents or patent applications, or other proprietary 1400 rights which may cover technology that may be required to practice 1401 this standard. Please address the information to the IETF Executive 1402 Director. 1404 Full Copyright Statement 1406 Copyright (C) The Internet Society (2004). All Rights Reserved. 1408 This document and translations of it may be copied and furnished to 1409 others, and derivative works that comment on or otherwise explain it 1410 or assist in its implementation may be prepared, copied, published 1411 and distributed, in whole or in part, without restriction of any 1412 kind, provided that the above copyright notice and this paragraph are 1413 included on all such copies and derivative works. However, this 1414 document itself may not be modified in any way, such as by removing 1415 the copyright notice or references to the Internet Society or other 1416 Internet organizations, except as needed for the purpose of 1417 developing Internet standards in which case the procedures for 1418 copyrights defined in the Internet Standards process must be 1419 followed, or as required to translate it into languages other than 1420 English. 1422 The limited permissions granted above are perpetual and will not be 1423 revoked by the Internet Society or its successors or assignees. 1425 This document and the information contained herein is provided on an 1426 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1427 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1428 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1429 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1430 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1432 Acknowledgment 1434 Funding for the RFC Editor function is currently provided by the 1435 Internet Society.