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