idnits 2.17.1 draft-ietf-sipping-conferencing-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1247. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 (May 27, 2005) is 6908 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: '13' is defined on line 1198, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-09 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-04 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-06 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-05 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: November 28, 2005 May 27, 2005 6 A Framework for Conferencing with the Session Initiation Protocol 7 draft-ietf-sipping-conferencing-framework-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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 27 http://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 November 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Session Initiation Protocol (SIP) supports the initiation, 41 modification, and termination of media sessions between user agents. 42 These sessions are managed by SIP dialogs, which represent a SIP 43 relationship between a pair of user agents. Because dialogs are 44 between pairs of user agents, SIP's usage for two-party 45 communications (such as a phone call), is obvious. Communications 46 sessions with multiple participants, generally known as conferencing, 47 are more complicated. This document defines a framework for how such 48 conferencing can occur. This framework describes the overall 49 architecture, terminology, and protocol components needed for multi- 50 party conferencing. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview of Conferencing Architecture . . . . . . . . . . . . 6 57 3.1 Usage of URIs . . . . . . . . . . . . . . . . . . . . . . 9 58 4. Functions of the Elements . . . . . . . . . . . . . . . . . . 10 59 4.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.2 Conference Policy Server . . . . . . . . . . . . . . . . . 11 61 4.3 Mixers . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.4 Conference Notification Service . . . . . . . . . . . . . 12 63 4.5 Participants . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.6 Conference Policy . . . . . . . . . . . . . . . . . . . . 12 65 5. Common Operations . . . . . . . . . . . . . . . . . . . . . . 13 66 5.1 Creating Conferences . . . . . . . . . . . . . . . . . . . 13 67 5.2 Adding Participants . . . . . . . . . . . . . . . . . . . 14 68 5.3 Removing Participants . . . . . . . . . . . . . . . . . . 14 69 5.4 Destroying Conferences . . . . . . . . . . . . . . . . . . 15 70 5.5 Obtaining Membership Information . . . . . . . . . . . . . 15 71 5.6 Adding and Removing Media . . . . . . . . . . . . . . . . 15 72 5.7 Conference Announcements and Recordings . . . . . . . . . 16 73 6. Physical Realization . . . . . . . . . . . . . . . . . . . . . 18 74 6.1 Centralized Server . . . . . . . . . . . . . . . . . . . . 18 75 6.2 Endpoint Server . . . . . . . . . . . . . . . . . . . . . 19 76 6.3 Media Server Component . . . . . . . . . . . . . . . . . . 21 77 6.4 Distributed Mixing . . . . . . . . . . . . . . . . . . . . 22 78 6.5 Cascaded Mixers . . . . . . . . . . . . . . . . . . . . . 24 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 81 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 83 11. Informative References . . . . . . . . . . . . . . . . . . . 27 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 28 85 Intellectual Property and Copyright Statements . . . . . . . . 29 87 1. Introduction 89 The Session Initiation Protocol (SIP) [1] supports the initiation, 90 modification, and termination of media sessions between user agents. 91 These sessions are managed by SIP dialogs, which represent a SIP 92 relationship between a pair of user agents. Because dialogs are 93 between pairs of user agents, SIP's usage for two-party 94 communications (such as a phone call), is obvious. Communications 95 sessions with multiple participants, however, are more complicated. 96 SIP can support many models of multi-party communications. One, 97 referred to as loosely coupled conferences, makes use of multicast 98 media groups. In the loosely coupled model, there is no signaling 99 relationship between participants in the conference. There is no 100 central point of control or conference server. Participation is 101 gradually learned through control information that is passed as part 102 of the conference (using the Real Time Control Protocol (RTCP) [2], 103 for example). Loosely coupled conferences are easily supported in 104 SIP by using multicast addresses within its session descriptions. 106 In another model, referred to as fully distributed multiparty 107 conferencing, each participant maintains a signaling relationship 108 with each other participant, using SIP. There is no central point of 109 control; it is completely distributed amongst the participants. This 110 model is outside the scope of this document. 112 In another model, sometimes referred to as the tightly coupled 113 conference, there is a central point of control. Each participant 114 connects to this central point. It provides a variety of conference 115 functions, and may possibly perform media mixing functions as well. 116 Tightly coupled conferences are not directly addressed by RFC 3261, 117 although basic participation is possible without any additional 118 protocol support. 120 This document presents the overall framework for tightly coupled SIP 121 conferencing, referred to simply as "conferencing" from this point 122 forward. This framework presents a general architectural model for 123 these conferences and presents terminology used to discuss such 124 conferences. It also discusses the ways in which SIP itself is 125 involved in conferencing. The aim of the framework is to meet the 126 general requirements for conferencing that are outlined in [3]. This 127 specification alludes to non-SIP-specific mechanisms for achieving 128 several conferencing functions. Those are outside the scope of this 129 specification. 131 2. Terminology 132 Conference: Conference is an overused term which has different 133 meanings in different contexts. In SIP, a conference is an 134 instance of a multi-party conversation. Within the context of 135 this specification, a conference is always a tightly coupled 136 conference. 138 Loosely Coupled Conference: A loosely coupled conference is a 139 conference without coordinated signaling relationships amongst 140 participants. Loosely coupled conferences frequently use 141 multicast for distribution of conference memberships. 143 Tightly Coupled Conference: A tightly coupled conference is a 144 conference in which a single user agent, referred to as a focus, 145 maintains a dialog with each participant. The focus plays the 146 role of the centralized manager of the conference, and is 147 addressed by a conference URI. 149 Focus: The focus is a SIP user agent that is addressed by a 150 conference URI and identifies a conference (recall that a 151 conference is a unique instance of a multi-party conversation). 152 The focus maintains a SIP signaling relationship with each 153 participant in the conference. The focus is responsible for 154 ensuring, in some way, that each participant receives the media 155 that make up the conference. The focus also implements conference 156 policies. The focus is a logical role. 158 Conference URI: A URI, usually a SIP URI, which identifies the focus 159 of a conference. 161 Participant: The software element that connects a user or automata to 162 a conference. It implements, at a minimum, a SIP user agent, but 163 may also implement non-SIP-specific mechanisms for additional 164 functionality. 166 Conference State: The state of the conference includes the state of 167 the focus, the set of participants connected to the conference, 168 and the state of their respective dialogs. 170 Conference Notification Service: A conference notification service is 171 a logical function provided by the focus. The focus can act as a 172 notifier [4], accepting subscriptions to the conference state, and 173 notifying subscribers about changes to that state. 175 Conference Policy Server: A conference policy server is a logical 176 function which can store and manipulate the conference policy. 177 This logical function is not specific to SIP, and may not 178 physically exist. It refers to the component that interfaces a 179 protocol to the conference policy. 181 Conference Policy: The complete set of rules governing a particular 182 conference. 184 Mixer: A mixer receives a set of media streams of the same type, and 185 combines their media in a type-specific manner, redistributing the 186 result to each participant. This includes media transported using 187 RTP [2]. As a result, the term defined here is a superset of the 188 mixer concept defined in RFC 3550, since it allows for non-RTP- 189 based media such as instant messaging sessions [5]. 191 Conference-Unaware Participant: A conference-unaware participant is a 192 participant in a conference that is not aware that it is actually 193 in a conference. As far as the UA is concerned, it is a point-to- 194 point call. 196 Cascaded Conferencing: A mechanism for group communications in which 197 a set of conferences are linked by having their focuses interact 198 in some fashion. 200 Simplex Cascaded Conferences: a group of conferences which are linked 201 such that the user agent which represents the focus of one 202 conference is a conference-unaware participant in another 203 conference. 205 Conference-Aware Participant: A conference-aware participant is a 206 participant in a conference that has learned, through automated 207 means, that it is in a conference, and that can use the conference 208 notification service or additional non-SIP-specific mechanisms for 209 additional functionality. 211 Conference Server: A conference server is a physical server which 212 contains, at a minimum, the focus. It may also include a 213 conference policy server and mixers. 215 Mass Invitation: An attempt to add a large number of users into a 216 conference. 218 Mass Ejection: An attempt to remove a large number of users from a 219 conference. 221 Sidebar: A sidebar appears to the users within the sidebar as a 222 "conference within the conference". It is a conversation amongst 223 a subset of the participants to which the remaining participants 224 are not privy. 226 Anonymous Participant: An anonymous participant is one that is known 227 to other participants through the conference notification service, 228 but whose identity is being withheld. 230 3. Overview of Conferencing Architecture 232 +-----------+ 233 | | 234 | | 235 |Participant| 236 | 4 | 237 | | 238 +-----------+ 239 | 240 |SIP 241 |Dialog 242 |4 243 | 244 +-----------+ +-----------+ +-----------+ 245 | | | | | | 246 | | | | | | 247 |Participant|-----------| Focus |------------|Participant| 248 | 1 | SIP | | SIP | 3 | 249 | | Dialog | | Dialog | | 250 +-----------+ 1 +-----------+ 3 +-----------+ 251 | 252 | 253 |SIP 254 |Dialog 255 |2 256 | 257 +-----------+ 258 | | 259 | | 260 |Participant| 261 | 2 | 262 | | 263 +-----------+ 265 Figure 1 267 The central component (literally) in a SIP conference is the focus. 268 The focus maintains a SIP signaling relationship with each 269 participant in the conference. The result is a star topology, shown 270 in Figure Figure 1. 272 The focus is responsible for making sure that the media streams which 273 constitute the conference are available to the participants in the 274 conference. It does that through the use of one or more mixers, each 275 of which combines a number of input media streams to produce one or 276 more output media streams. The focus uses the media policy to 277 determine the proper configuration of the mixers. 279 The focus has access to the conference policy, an instance of which 280 exists for each conference. Effectively, the conference policy can 281 be thought of as a database which describes the way that the 282 conference should operate. It is the responsibility of the focus to 283 enforce those policies. Not only does the focus need read access to 284 the database, but it needs to know when it has changed. Such changes 285 might result in SIP signaling (for example, the ejection of a user 286 from the conference using BYE), and those changes with affect the 287 conference state will require a notification to be sent to 288 subscribers using the conference notification service. 290 The conference is represented by a URI, which identifies the focus. 291 Each conference has a unique focus and a unique URI identifying that 292 focus. Requests to the conference URI are routed to the focus for 293 that specific conference. 295 Users usually join the conference by sending an INVITE to the 296 conference URI. As long as the conference policy allows, the INVITE 297 is accepted by the focus and the user is brought into the conference. 298 Users can leave the conference by sending a BYE, as they would in a 299 normal call. 301 Similarly, the focus can terminate a dialog with a participant, 302 should the conference policy change to indicate that the participant 303 is no longer allowed in the conference. A focus can also initiate an 304 INVITE to bring a participant into the conference. 306 The notion of a conference-unaware participant is important in this 307 framework. A conference-unaware participant does not even know that 308 the UA it is communicating with happens to be a focus. As far as 309 it's concerned, its a UA just like any other. The focus, of course, 310 knows that its a focus, and it performs the tasks needed for the 311 conference to operate. 313 Conference-unaware participants have access to a good deal of 314 functionality. They can join and leave conferences using SIP, and 315 obtain more advanced features through stimulus signaling, as 316 discussed in [6]. However, if the participant wishes to explicitly 317 control aspects of the conference using functional signaling 318 protocols, the participant must be conference-aware. 320 ..................................... 321 . . 322 . . 323 . . 324 . . 325 . . 326 . . 327 . . 328 . +-----------+ //-----\\ . 329 . | | || || . 330 non-SIP . | Conference| \\-----// . 331 +---------------->| Policy | | | . 332 | . | Server |----> | | . 333 | . | | |Conference| . 334 | . +-----------+ | Policy | . 335 | . | | . 336 | . | | . 337 +-----------+ . +-----------+ | | . 338 | | . | | \ // . 339 | | . | | \-----/ . 340 |Participant|<--------->| Focus | | . 341 | | SIP . | | | . 342 | | Dialog . | |<-----------+ . 343 +-----------+ . |...........| . 344 ^ . | Conference| . 345 | . |Notification . 346 +------------>| Service | . 347 Subscription. +-----------+ . 348 . . 349 . . 350 . . 351 . . 352 ..................................... 354 Conference 355 Functions 357 Figure 2 359 A conference-aware participant is one that has access to advanced 360 functionality through additional protocol interfaces, which may 361 include access to the conference policy through non-SIP-specific 362 mechanisms. A model for this interaction is shown in Figure 363 Figure 2. The participant can interact with the focus using 364 extensions, such as REFER, in order to access enhanced call control 365 functions [7]. The participant can SUBSCRIBE to the conference URI, 366 and be connected to the conference notification service provided by 367 the focus. Through this mechanism, it can learn about changes in 368 participants - effectively, the state of the dialogs and the media. 370 The participant can communicate with the conference policy server 371 using some kind of non-SIP-specific mechanism by which it can affect 372 the conference policy. The conference policy server need not be 373 available in any particular conference, although there is always a 374 conference policy. 376 The interfaces between the focus and the conference policy, and the 377 conference policy server and the conference policy are non-SIP- 378 specific. For the purposes of SIP-based conferencing, they serve as 379 logical roles involved in a conference, as opposed to representing a 380 physical decomposition. The separation of these functions is 381 documented here to encourage clarity in the requirements. This 382 approach provides individual SIP implementations the flexibility to 383 compose a conferencing system in a scalable and robust manner without 384 requiring the complete development of these interfaces. 386 3.1 Usage of URIs 388 It is fundamental to this framework that a conference is uniquely 389 identified by a URI, and that this URI identifies the focus which is 390 responsible for the conference. The conference URI is unique, such 391 that no two conferences have the same conference URI. A conference 392 URI is always a SIP or SIPS URI. 394 The conference URI is opaque to any participants which might use it. 395 There is no way to look at the URI, and know for certain whether it 396 identifies a focus, as opposed to a user or an interface on a PSTN 397 gateway. This is in line with the general philosophy of URI usage 398 [8]. However, contextual information surrounding the URI (for 399 example, SIP header parameters) may indicate that the URI represents 400 a conference. 402 When a SIP request is sent to the conference URI, that request is 403 routed to the focus, and only to the focus. The element or system 404 that creates the conference URI is responsible for guaranteeing this 405 property. 407 The conference URI can represent a long-lived conference or interest 408 group, such as "sip:discussion-on-dogs@example.com". The focus 409 identified by this URI would always exist, and always be managing the 410 conference for whatever participants are currently joined. Other 411 conference URIs can represent short-lived conferences, such as an ad- 412 hoc conference. 414 Ideally, a conference URI is never constructed or guessed by a user. 415 Rather, conference URIs are learned through many mechanisms. A 416 conference URI can be emailed or sent in an instant message. A 417 conference URI can be linked on a web page. A conference URI can be 418 also be obtained from some non-SIP mechanism. 420 To determine that a SIP URI does represent a focus, standard 421 techniques for URI capability discovery can be used. Specifically, 422 the callee capabilities specification [9] provides the "isfocus" 423 feature tag to indicate that the URI is acting as focus in this 424 dialog. Callee capability parameters are also used to indicate that 425 a focus supports the conference notification service. This is done 426 by declaring support for the SUBSCRIBE method and the relevant 427 package(s) in the caller preferences feature parameters associated 428 with the conference URI. 430 Other functions in a conference may be represented by URIs. If the 431 conference policy is exposed through a web application, it is 432 identified by an HTTP URI. If it is accessed using an explicit 433 protocol, it is a URI defined for that protocol. 435 Starting with the conference URI, the URIs for the other logical 436 entities in the conference can be learned using the conference 437 notification service. 439 4. Functions of the Elements 441 This section gives a more detailed description of the functions 442 typically implemented in each of the elements. 444 4.1 Focus 446 As its name implies, the focus is the center of the conference. All 447 participants in the conference are connected to it by a SIP dialog. 448 The focus is responsible for maintaining the dialogs connected to it. 449 It ensures that the dialogs are connected to a set of participants 450 who are allowed to participate in the conference, as defined by the 451 membership policy. The focus also uses SIP to manipulate the media 452 sessions, in order to make sure each participant obtains all the 453 media for the conference. To do that, the focus makes use of mixers. 455 When a focus receives an INVITE, it checks the conference policy. 456 The policy might indicate that this participant is not allowed to 457 join, in which case the call can be rejected. It might indicate that 458 another participant, acting as a moderator, needs to approve this new 459 participant. In that case, the INVITE might be parked on a music-on- 460 hold server, or a 183 response might be sent to indicate progress. A 461 notification, using the conference notification service, would be 462 sent to the moderator. The moderator can then allow this new 463 participant to join, and the focus can then accept the INVITE (or 464 unpark it from the music-on-hold server). The interpretation of 465 policy by the focus is, itself, a matter of local policy, and not 466 subject to standardization. 468 When it is necessary to remove a SIP participant (with a confirmed 469 dialog) from a conference, the focus would send a BYE to that 470 participant to remove the participant. This is often referred to as 471 "ejecting" a user from the conference, and when done for many users, 472 is called "mass ejection". Similarly, if it is necessary to add a 473 new SIP participant to a conference, the focus would send an INVITE 474 request to that participant. When done for a large number of users, 475 this is called mass invitation. Finally, if it is necessary to 476 change the properties of the media of a session (for example to 477 remove video) for a SIP participant, the focus can send update the 478 session description for that participant by sending a re-INVITE or 479 UPDATE [16] request with a new offer to that participant. 481 In many cases, the signaling actions performed by the focus, such as 482 ejection or addition of a participant, will change the media 483 composition of the conference. To affect these changes, the focus 484 interacts with the mixer. Through that interaction, it makes sure 485 that all valid participants received a copy of the media streams, and 486 that each participant sends media to an IP address and port on the 487 mixer that cause it to be appropriately mixed with the other media in 488 the conference. The means by which the focus interacts with the 489 mixer are outside the scope of this specification. 491 4.2 Conference Policy Server 493 The conference policy server is a logical component of the system. 494 It represents the interface between clients and the conference policy 495 that governs the operation of the conference. Clients communicate 496 with the conference policy server using a non-SIP-specific mechanism. 498 4.3 Mixers 500 A mixer is responsible for combining the media streams that make up 501 the conference, and generating one or more output streams that are 502 distributed to recipients (which could be participants or other 503 mixers). The process of combining media is specific to the media 504 type, and is directed by the focus, under the guidance of the rules 505 described in the media policy. 507 A mixer is not aware of a "conference" as an entity, per se. A mixer 508 receives media streams as inputs, and based on directions provided by 509 the focus, generates media streams as outputs. There is no grouping 510 of media streams beyond the policies that describe the ways in which 511 the streams are mixed. 513 A mixer is always under the control of a focus, either directly or 514 indirectly. The focus is responsible for interpreting the media 515 policy, and then installing the appropriate rules in the mixer. If 516 the focus is directly controlling a mixer, the mixer can either be 517 co-resident with the focus, or can be controlled through some kind of 518 protocol. If the focus is indirectly controlling a mixer, it 519 delegates the mixing to the participants, each of which has their own 520 mixer. This is described in Section 6.4. 522 4.4 Conference Notification Service 524 The focus can provide a conference notification service. In this 525 role, it acts as a notifier, as defined in RFC 3265 [4]. It accepts 526 subscriptions from clients for the conference URI, and generates 527 notifications to them as the state of the conference changes. 529 The state of the conference includes the participants connected to 530 the focus, and information about the dialogs associated with them. 531 As new participants join, this state changes, and is reported through 532 the notification service. Similarly, when someone leaves, this state 533 also changes, allowing subscribers to learn about this fact. 535 If a participant is anonymous, the conference notification service 536 will either withhold the identity of a new participant from other 537 conference participants, or will neglect to inform other conference 538 participants about the presence of the anonymous participant. The 539 choice of approach depends on the level of anonymity provided to the 540 anonymous participant. 542 4.5 Participants 544 A participant in a conference is any SIP user agent that has a dialog 545 with the focus. This SIP user agent can be a PC application, a SIP 546 hardphone, or a PSTN gateway. It can also be another focus. A 547 conference which has a participant that is the focus of another 548 conference is called a simplex cascaded conference. They can also be 549 used to provide scalable conferences where there are regional sub- 550 conferences, each of which is connected to the main conference. 552 4.6 Conference Policy 554 The conference policy contains the rules that guide the operation of 555 the focus. The rules can be simple, such as an access list that 556 defines the set of allowed participants in a conference. The rules 557 can also be incredibly complex, specifying time-of-day based rules on 558 participation conditional on the presence of other participants. It 559 is important to understand that there is no restriction on the type 560 of rules that can be encapsulated in a conference policy. 562 The conference policy can be manipulated using web applications or 563 voice applications. It can also be manipulated with non-SIP-specific 564 standard or proprietary protocols. 566 5. Common Operations 568 There are a large number of ways in which users can interact with a 569 conference. They can join, leave, set policies, approve members, and 570 so on. This section is meant as an overview of the major 571 conferencing operations, summarizing how they operate. More detailed 572 examples of the SIP mechanisms can be found in [7]. 574 As well as providing an overview of the common conferencing 575 operations, each of the subsections in this section of the document 576 provides a description of the SIP mechanism for supporting the 577 operation. Non-SIP mechanisms are also possible, but not discussed 578 here. 580 5.1 Creating Conferences 582 There are many ways in which a conference can be created. The 583 creation of a conference actually constructs several elements all at 584 the same time. It results in the creation of a focus and a 585 conference policy. It also results in the construction of a 586 conference URI, which uniquely identifies the focus. Since the 587 conference URI needs to be unique, the element which creates 588 conferences is responsible for guaranteeing that uniqueness. This 589 can be accomplished deterministically, by keeping records of 590 conference URIs, or by generating URIs algorithmically, or 591 probabilistically, by creating random URI with sufficiently low 592 probabilities of collision. 594 When conference policy is created, it is established with default 595 rules that are implementation dependent. If the creator of the 596 conference wishes to change those rules, they would do so using a 597 non-SIP mechanism. 599 SIP can be used to create conferences hosted in a central server by 600 sending an INVITE to a conferencing application that would 601 automatically create a new conference and then place a user into it. 603 Creation of conferences where the focus resides in an endpoint 604 operates differently. There, the endpoint itself creates the 605 conference URI, and hands it out to other endpoints which are to be 606 the participants. What differs from case to case is how the endpoint 607 decides to create a conference. 609 One important case is the ad-hoc conference described in Section 6.2. 611 There, an endpoint unilaterally decides to create the conference 612 based on local policy. The dialogs that were connected to the UA are 613 migrated to the endpoint-hosted focus, using a re-INVITE or UPDATE to 614 pass the conference URI to the newly joined participants. 616 Alternatively, one UA can ask another UA to create an endpoint-hosted 617 conference. This is accomplished with the SIP Join header [10]. The 618 UA which receives the Join header in an invitation may need to create 619 a new conference URI (a new one is not needed if the dialog that is 620 being joined is already part of a conference). The conference URI is 621 then handed to the recently joined participants through a re-INVITE 622 or UPDATE. 624 5.2 Adding Participants 626 There are many mechanisms for adding participants to a conference. 627 In all cases, participant additions can be first party (a user adds 628 themself) or third party (a user adds another user). 630 First person additions using SIP are trivially accomplished with a 631 standard INVITE. A participant can send an INVITE request to the 632 conference URI, and if the conference policy allows them to join, 633 they are added to the conference. 635 If a UA does not know the conference URI, but has learned about a 636 dialog which is connected to a conference (by using the dialog event 637 package, for example [11]), the UA can join the conference by using 638 the Join header to join the dialog. 640 Third party additions with SIP are done using REFER [12]. The client 641 can send a REFER request to the participant, asking them to send an 642 INVITE request to the conference URI. Additionally, the client can 643 send a REFER request to the focus, asking it to send an INVITE to the 644 participant. The latter technique has the benefit of allowing a 645 client to add a conference-unaware participant that does not support 646 the REFER method. 648 5.3 Removing Participants 650 As with additions, there are several mechanisms for departures. 651 Removals can also be first person or third person. 653 First person departures are trivially accomplished by sending a BYE 654 request to the focus. This terminates the dialog with the focus and 655 removes the participant from the conference. The focus can also 656 remove a participant from the conference by sending it a BYE. In 657 either case, the focus interacts with the mixer to make sure that the 658 departed participant ceases receiving conference media, and that 659 media from that participant are no longer mixed into the conference. 661 Third person departures can also be done using SIP, through the REFER 662 method. 664 5.4 Destroying Conferences 666 Conferences can be destroyed in several ways. Generally, whether 667 those means are applicable for any particular conference is a 668 component of the conference policy. 670 When a conference is destroyed, the conference policy associated with 671 it is destroyed. Any attempts to read or write the policy results in 672 a protocol error. Furthermore, the conference URI becomes invalid. 673 Any attempts to send an INVITE to it, or SUBSCRIBE to it, would 674 result in a SIP error response. 676 Typically, if a conference is destroyed while there are still 677 participants, the focus would send a BYE to those participants before 678 actually destroying the conference. Similarly, if there were any 679 users subscribed to the conference notification service, those 680 subscriptions would be terminated by the server before the actual 681 destruction. 683 There is no explicit means in SIP to destroy a conference. However, 684 a conference may be destroyed as a by-product of a user leaving the 685 conference, which can be done with BYE. In particular, if the 686 conference policy states that the conference is destroyed once the 687 last user or a specific user leaves, when that user does leave (using 688 a SIP BYE request), the conference is destroyed. 690 5.5 Obtaining Membership Information 692 A participant in a conference will frequently wish to know the set of 693 other users in the conference. This information can be obtained many 694 ways. 696 The conference notification service allows a conference aware 697 participant to subscribe to it, and receive notifications that 698 contain the list of participants. When a new participant joins or 699 leaves, subscribers are notified. The conference notification 700 service also allows a user to do a "fetch" [4] to obtain the current 701 listing. 703 5.6 Adding and Removing Media 705 Each conference is composed of a particular set of media that the 706 focus is managing. For example, a conference might contain a video 707 stream and an audio stream. The set of media streams that constitute 708 the conference can be changed by participants. When the set of media 709 in the conference change, the focus will need to generate a re-INVITE 710 to each participant in order to add or remove the media stream to 711 each participant. When a media stream is being added, a participant 712 can reject the offered media stream, in which case it will not 713 receive or contribute to that stream. Rejection of a stream by a 714 participant does not imply that that the stream is no longer part of 715 the conference - just that the participant is not involved in it. 717 A SIP re-INVITE can be used by a participant to add or remove a media 718 stream. This is accomplished using the standard offer/answer 719 techniques for adding media streams to a session [14]. This will 720 trigger the focus to generate its own re-INVITEs. 722 5.7 Conference Announcements and Recordings 724 Conference announcements and recordings play a key role in many real 725 conferencing systems. Examples of such features include: 727 o Asking a user to state their name before joining the conference, 728 in order to support a roll call 730 o Allowing a user to request a roll call, so they can hear who else 731 is in the conference 733 o Allowing a user to press some keys on their keypad in order to 734 record the conference 736 o Allowing a user to press some keys on their keypad in order to be 737 connected with a human operator 739 o Allowing a user to press some keys on their keypad to mute or 740 unmute their line 741 User 1 742 +-----------+ 743 | | 744 | | 745 |Participant| 746 | 1 | 747 | | 748 +-----------+ 749 |SIP 750 |Dialog 751 Conference |1 752 Policy +---|--------+ 753 User 2 Server | | | Application 754 +-----------+ +-----------+ | non-SIP ************* 755 | | | | |-------- * * 756 | | | | | * * 757 |Participant|-----------| Focus |------------*Participant* 758 | 2 | SIP | | | SIP * 4 * 759 | | Dialog | |--+ Dialog * * 760 +-----------+ 2 +-----------+ 4 ************* 761 | 762 | 763 |SIP 764 |Dialog 765 |3 766 | 767 +-----------+ 768 | | 769 | | 770 |Participant| 771 | 3 | 772 | | 773 +-----------+ 774 User 3 776 Figure 3 778 In this framework, these capabilities are modeled as an application 779 which acts as a participant in the conference. This is shown 780 pictorially in Figure 3. The conference has four participants. 781 Three of these participants are end users, and the fourth is the 782 announcement application. 784 If the announcement application wishes to play an announcement to all 785 the conference members (for example, to announce a join), it merely 786 sends media to the mixer as would any other participant. The 787 announcement is mixed in with the conversation and played to the 788 participants. 790 Similarly, the announcement application can play an announcement to a 791 specific user by configuring the conference policy so that the media 792 it generates is only heard by the target user. The application then 793 generates the desired announcement, and it will be heard only by the 794 selected recipient. 796 The announcement application can also receive input from a specific 797 user through the conference. To do this, it can use the application 798 interaction framework [6]. This allows it to collect user input, 799 possibly through keypad stimulus, and take actions. 801 6. Physical Realization 803 In this section, we present several physical instantiations of these 804 components, to show how these basic functions can be combined to 805 solve a variety of problems. 807 6.1 Centralized Server 809 In the most simplistic realization of this framework, there is a 810 single physical server in the network which implements the focus, the 811 conference policy server, and the mixers. This is the classic "one 812 box" solution, shown in Figure 4. 814 Conference Server 815 ................................... 816 . . 817 . +------------+ . 818 . | Conference | . 819 . |Notification| . 820 . | Server | . 821 . +------------+ . 822 . +----------+ . 823 . |Conference| +-----+ . 824 . | Policy | +-------+ +-----+| . 825 . | Server | | Focus | |Mixer|+ . 826 . +----------+ +-------+ +-----+ . 827 ................//.\.....***....... 828 // \ *** * 829 // *** * RTP 830 SIP // *** \ * 831 // *** \SIP * 832 // *** RTP \ * 833 / ** \ * 834 +-----------+ +-----------+ 835 |Participant| |Participant| 836 +-----------+ +-----------+ 838 Figure 4 840 6.2 Endpoint Server 842 Another important model is that of a locally-mixed ad-hoc conference. 843 In this scenario, two users (A and B) are in a regular point-to-point 844 call. One of the participants (A) decides to conference in a third 845 participant, C. To do this, A begins acting as a focus. Its existing 846 dialog with B becomes the first dialog attached to the focus. A 847 would re-INVITE B on that dialog, changing its Contact URI to a new 848 value which identifies the focus. In essence, A "mutates" from a 849 single-user UA to a focus plus a single user UA, and in the process 850 of such a mutation, its URI changes. Then, the focus makes an 851 outbound INVITE to C. When C accepts, it mixes the media from B and C 852 together, redistributing the results. The mixed media is also played 853 locally. Figure 5 shows a diagram of this transition. 855 B B 856 +------+ +------+ 857 | | | | 858 | UA | | UA | 859 | | | | 860 +------+ +------+ 861 | . | . 862 | . | . 863 | . | . 864 | . Transition | . 865 | . ------------> | . 866 SIP| .RTP SIP| .RTP 867 | . | . 868 | . | . 869 | . | . 870 | . | . 871 | . +----------+ 872 +------+ | +------+ | SIP +------+ 873 | | | |Focus | |----------| | 874 | UA | | |C.Pol.| | | UA | 875 | | | |Mixers| |..........| | 876 +------+ | | | | RTP +------+ 877 | +------+ | 878 A | + | C 879 | + <..|....... 880 | + | . 881 | +------+ | . 882 | |Parti-| | . 883 | |cipant| | . 884 | | | | . 885 | +------+ | . 886 +----------+ . 887 A . 888 . 890 Internal 891 Interface 893 Figure 5 895 It is important to note that the external interfaces in this model, 896 between A and B, and between B and C, are exactly the same to those 897 that would be used in a centralized server model. User A could also 898 implement a conference policy and a conference notification service, 899 allowing the participants to have access to them if they so desired. 900 Just because the focus is co-resident with a participant does not 901 mean any aspect of the behaviors and external interfaces will change. 903 6.3 Media Server Component 905 +------------+ +------------+ 906 | App Server| SIP |Conf. Cmpnt.| 907 | |-------------| | 908 | Focus | non-SIP | Focus | 909 | C.Pol |-------------| C.Pol | 910 | | | Mixers | 911 |Notification| | | 912 | | | | 913 +------------+ +------------+ 914 | \ .. . 915 | \\ RTP... . 916 | \\ .. . 917 | SIP \\ ... . 918 SIP | \\ ... .RTP 919 | ..\ . 920 | ... \\ . 921 | ... \\ . 922 | .. \\ . 923 | ... \\ . 924 | .. \ . 925 +-----------+ +-----------+ 926 |Participant| |Participant| 927 +-----------+ +-----------+ 929 Figure 6 931 In this model, shown in Figure 6, each conference involves two 932 centralized servers. One of these servers, referred to as the 933 "application server" owns and manages the membership and media 934 policies, and maintains a dialog with each participant. As a result, 935 it represents the focus seen by all participants in a conference. 936 However, this server doesn't provide any media support. To perform 937 the actual media mixing function, it makes use of a second server, 938 called the "mixing server". This server includes a focus, and 939 implements a conference policy, but has no conference notification 940 service. Its conference policy tells it to accept all invitations 941 from the top-level focus. The focus in the application server uses 942 third party call control to connect the media streams of each user to 943 the mixing server, as needed. If the focus in the application server 944 receives a conference policy control command from a client, it 945 delegates that to the media server by making the same media policy 946 control command to it. 948 This model allows for the mixing server to be used as a resource for 949 a variety of different conferencing applications. This is because it 950 is unaware of conference policy; it is merely a "slave" to the top- 951 level server, doing whatever it asks. 953 6.4 Distributed Mixing 955 In a distributed mixed conference, there is still a centralized 956 server which implements the focus, conference policy server, and 957 media policy server. However, there are no centralized mixers. 958 Rather, there are mixers in each endpoint, along with a conference 959 policy server. The focus distributes the media by using third party 960 call control [15] to move a media stream between each participant and 961 each other participant. As a result, if there are N participants in 962 the conference, there will be a single dialog between each 963 participant and the focus, but the session description associated 964 with that dialog will be constructed to allow media to be distributed 965 amongst the participants. This is shown in Figure 7. 967 +---------+ 968 |Partcpnt | 969 media | | media 970 ...............| |.................. 971 . | Mixers | . 972 . |C.Pol.Srv| . 973 . +---------+ . 974 . | . 975 . | . 976 . | . 977 . dialog | . 978 . | . 979 . | . 980 . | . 981 . +---------+ . 982 . |Cnf.Srvr.| . 983 . | | . 984 . | Focus | . 985 . |C.Pol.Srv| . 986 . / | | \ . 987 . / +---------+ \ . 988 . / \ . 989 . / \ . 990 . / dialog \ . 991 . / \ . 992 . /dialog \ . 993 . / \ . 994 . / \ . 995 . / \ . 996 . . 997 +---------+ +---------+ 998 |Partcpnt | |Partcpnt | 999 | | | | 1000 | | ......................... | | 1001 | Mixers | | Mixers | 1002 |C.Pol.Srv| media |C.Pol.Srv| 1003 +---------+ +---------+ 1005 Figure 7 1007 There are several ways in which the media can be distributed to each 1008 participant for mixing. In a multi-unicast model, each participant 1009 sends a copy of its media to each other participant. In this case, 1010 the session description manages N-1 media streams. In a multicast 1011 model, each participant joins a common multicast group, and each 1012 participant sends a single copy of its media stream to that group. 1013 The underlying multicast infrastructure then distributes the media, 1014 so that each participant gets a copy. In a single-source multicast 1015 model (SSM), each participant sends its media stream to a central 1016 point, using unicast. The central point then redistributes the media 1017 to all participants using multicast. The focus is responsible for 1018 selecting the modality of media distribution, and for handling any 1019 hybrids that would be necessitated from clients with mixed 1020 capabilities. 1022 When a new participant joins or is added, the focus will perform the 1023 necessary third party call control to distribute the media from the 1024 new participant to all the other participants, and vice-a-versa. 1026 The central conference server also exposes an interface to the 1027 conference policy. Of course, the central conference server cannot 1028 implement any of the media operations or policies directly. Rather, 1029 it would delegate the implementation to each participant. As an 1030 example, if a participant decides to switch the overall conference 1031 mode from "voice activated" to "continuous presence", they would 1032 communicate with the central conference policy server. The 1033 conference policy server, in turn, would communicate with the 1034 conference policy servers co-resident with each participant, using 1035 some non-SIP-specific mechanism, and instruct them to use "continuous 1036 presence". 1038 This model requires additional functionality in user agents, which 1039 may or may not be present. The participants, therefore, must be able 1040 to advertise this capability to the focus. 1042 6.5 Cascaded Mixers 1044 In very large conferences, it may not be possible to have a single 1045 mixer that can handle all of the media. A solution to this is to use 1046 cascaded mixers. In this architecture, there is a centralized focus, 1047 but the mixing function is implemented by a multiplicity of mixers, 1048 scattered throughout the network. Each participant is connected to 1049 one, and only one of the mixers. The focus uses some kind of control 1050 protocol to connect the mixers together, so that all of the 1051 participants can hear each other. 1053 +---------+ 1054 +-----------------------| |------------------------+ 1055 | ++++++++++++++++++++| |++++++++++++++++++ | 1056 | + +------| Focus |---------+ + | 1057 | + | | | | + | 1058 | + | +-| |--+ | + | 1059 | + | | +---------+ | | + | 1060 | + | | + | | + | 1061 | + | | + | | + | 1062 | + | | + | | + | 1063 | + | | +---------+ | | + | 1064 | + | | | | | | + | 1065 | + | | | Mixer 2 | | | + | 1066 | + | | | | | | + | 1067 | + | | +---------+ | | + | 1068 | + | |... . .... | | + | 1069 | + .|....| . .|.... | + | 1070 | + ...... | | . | ..|... + | 1071 | + ... | | . | | ....+ | 1072 | +---------+ | | +---------+ | | +---------+ | 1073 | | | | | | | | | | | | 1074 | | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | | 1075 | | | | | | | | | | | | 1076 | +---------+ | | +---------+ | | +---------+ | 1077 | . . | | . . | | . . | 1078 | . . | | .. . | | .. . | 1079 | . . | | . . | | . . | 1080 +---------+ . | +---------+ . | +---------+ . | 1081 | Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . | 1082 | 1 | . | | 3 | . | | 5 | . | 1083 +---------+ . | +---------+ . | +---------+ . | 1084 . | . | . | 1085 +---------+ +---------+ +---------+ 1086 | Prtcpnt | | Prtcpnt | | Prtcpnt | 1087 | 2 | | 4 | | 6 | 1088 +---------+ +---------+ +---------+ 1090 ------- SIP Dialog 1091 ....... Media Flow 1092 +++++++ Control Protocol 1094 Figure 8 1096 This architecture is shown in Figure 8. 1098 7. Security Considerations 1100 Conferences frequently require security features in order to properly 1101 operate. The conference policy may dictate that only certain 1102 participants can join, or that certain participants can create new 1103 policies. Generally speaking, conference applications are very 1104 concerned about authorization decisions. Mechanisms for establishing 1105 and enforcing such authorization rules is a central concept 1106 throughout this document. 1108 Of course, authorization rules require authentication. Normal SIP 1109 authentication mechanisms should suffice for the conference 1110 authorization mechanisms described here. 1112 Privacy is an important aspect of conferencing. Users may wish to 1113 join a conference without anyone knowing that they have joined, in 1114 order to silently listen in. In other applications, a participant 1115 may wish just to hide their identity from other participants, but 1116 otherwise let them know of their presence. These functions need to 1117 be provided by the conferencing system. 1119 8. IANA Considerations 1121 There are no IANA considerations associated with this specification. 1123 9. Contributors 1125 This document is the result of discussions amongst the conferencing 1126 design team. The members of this team include: 1128 Alan Johnston 1129 Brian Rosen 1130 Rohan Mahy 1131 Henning Schulzrinne 1132 Orit Levin 1133 Roni Even 1134 Tom Taylor 1135 Petri Koskelainen 1136 Nermeen Ismail 1137 Andy Zmolek 1138 Joerg Ott 1139 Dan Petrie 1141 10. Acknowledgements 1143 The authors would like to thank Mary Barnes, Chris Boulton and Rohan 1144 Mahy for their comments. Thanks to Allison Mankin for her comments 1145 and support of this work. 1147 11. Informative References 1149 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1150 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1151 Session Initiation Protocol", RFC 3261, June 2002. 1153 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1154 "RTP: A Transport Protocol for Real-Time Applications", 1155 RFC 3550, July 2003. 1157 [3] Levin, O. and R. Even, "High Level Requirements for Tightly 1158 Coupled SIP Conferencing", 1159 draft-ietf-sipping-conferencing-requirements-01 (work in 1160 progress), October 2004. 1162 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1163 Notification", RFC 3265, June 2002. 1165 [5] Campbell, B., "The Message Session Relay Protocol", 1166 draft-ietf-simple-message-sessions-09 (work in progress), 1167 October 2004. 1169 [6] Rosenberg, J., "A Framework for Application Interaction in the 1170 Session Initiation Protocol (SIP)", 1171 draft-ietf-sipping-app-interaction-framework-04 (work in 1172 progress), February 2005. 1174 [7] Johnston, A. and O. Levin, "Session Initiation Protocol Call 1175 Control - Conferencing for User Agents", 1176 draft-ietf-sipping-cc-conferencing-06 (work in progress), 1177 November 2004. 1179 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1180 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1181 January 2005. 1183 [9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1184 User Agent Capabilities in the Session Initiation Protocol 1185 (SIP)", RFC 3840, August 2004. 1187 [10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1188 "Join" Header", RFC 3911, October 2004. 1190 [11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 1191 the Session Initiation Protocol (SIP)", 1192 draft-ietf-sipping-dialog-package-05 (work in progress), 1193 November 2004. 1195 [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1196 Method", RFC 3515, April 2003. 1198 [13] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1199 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1200 Instant Messaging", RFC 3428, December 2002. 1202 [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1203 Session Description Protocol (SDP)", RFC 3264, June 2002. 1205 [15] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1206 "Best Current Practices for Third Party Call Control (3pcc) in 1207 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1208 April 2004. 1210 [16] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1211 Method", RFC 3311, October 2002. 1213 Author's Address 1215 Jonathan Rosenberg 1216 Cisco Systems 1217 600 Lanidex Plaza 1218 Parsippany, NJ 07054 1219 US 1221 Phone: +1 973 952-5000 1222 Email: jdrosen@cisco.com 1223 URI: http://www.jdrosen.net 1225 Intellectual Property Statement 1227 The IETF takes no position regarding the validity or scope of any 1228 Intellectual Property Rights or other rights that might be claimed to 1229 pertain to the implementation or use of the technology described in 1230 this document or the extent to which any license under such rights 1231 might or might not be available; nor does it represent that it has 1232 made any independent effort to identify any such rights. Information 1233 on the procedures with respect to rights in RFC documents can be 1234 found in BCP 78 and BCP 79. 1236 Copies of IPR disclosures made to the IETF Secretariat and any 1237 assurances of licenses to be made available, or the result of an 1238 attempt made to obtain a general license or permission for the use of 1239 such proprietary rights by implementers or users of this 1240 specification can be obtained from the IETF on-line IPR repository at 1241 http://www.ietf.org/ipr. 1243 The IETF invites any interested party to bring to its attention any 1244 copyrights, patents or patent applications, or other proprietary 1245 rights that may cover technology that may be required to implement 1246 this standard. Please address the information to the IETF at 1247 ietf-ipr@ietf.org. 1249 Disclaimer of Validity 1251 This document and the information contained herein are provided on an 1252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1254 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1255 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1256 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1259 Copyright Statement 1261 Copyright (C) The Internet Society (2005). This document is subject 1262 to the rights, licenses and restrictions contained in BCP 78, and 1263 except as set forth therein, the authors retain all their rights. 1265 Acknowledgment 1267 Funding for the RFC Editor function is currently provided by the 1268 Internet Society.