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