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