idnits 2.17.1 draft-ietf-sipping-conferencing-requirements-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. ** 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 : ---------------------------------------------------------------------------- ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 478, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group O. Levin 3 Internet-Draft Microsoft Corporation 4 Expires: March 2, 2005 R. Even 5 Polycom 6 September 2004 8 High Level Requirements for Tightly Coupled SIP Conferencing 9 draft-ietf-sipping-conferencing-requirements-01 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 2, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document examines a wide range of conferencing requirements for 45 tightly coupled SIP conferences. Separate documents will map the 46 requirements to existing protocol primitives, define new protocol 47 extensions, and introduce new protocols as needed. Together, these 48 documents will provide a guide for building interoperable SIP 49 conferencing applications. 51 Table of Contents 53 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. An Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. High Level Requirements . . . . . . . . . . . . . . . . . . . 4 56 3.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . 4 57 3.2 Conference Creation . . . . . . . . . . . . . . . . . . . 5 58 3.3 Conference Termination . . . . . . . . . . . . . . . . . . 5 59 3.4 Participants' Manipulations . . . . . . . . . . . . . . . 5 60 3.4.1 Participation of a Conference-unaware User Agent . . . 5 61 3.4.2 Dial-Out Scenarios . . . . . . . . . . . . . . . . . . 5 62 3.4.3 Dial-In Scenarios . . . . . . . . . . . . . . . . . . 6 63 3.4.4 Third Party Invitation to a Conference . . . . . . . . 6 64 3.4.5 Participants' Removal . . . . . . . . . . . . . . . . 6 65 3.4.6 Participants' Privacy . . . . . . . . . . . . . . . . 7 66 3.5 Conference State Information . . . . . . . . . . . . . . . 7 67 3.5.1 Description . . . . . . . . . . . . . . . . . . . . . 7 68 3.5.2 Dissemination of Changes . . . . . . . . . . . . . . . 8 69 3.5.3 On-demand Information Dissemination . . . . . . . . . 8 70 3.6 Focus Role Migration . . . . . . . . . . . . . . . . . . . 9 71 3.7 Side-bar Conferences . . . . . . . . . . . . . . . . . . . 9 72 3.8 Cascading of Conferences . . . . . . . . . . . . . . . . . 10 73 3.9 SIMPLE and SIP Conferencing Coordination . . . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 78 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . . 12 82 1. Scope 84 This document examines a wide range of conferencing requirements for 85 tightly coupled SIP (RFC 3261 [2]) conferencing. 87 The requirements are grouped by subjects in various areas allowing 88 solutions to progress in parallel. 90 Separate documents will map the requirements to existing protocol 91 primitives, define new protocol extensions, and introduce new 92 protocols as needed. 94 Together, these documents will provide a guide for building 95 interoperable SIP conferencing applications. 97 2. An Overview 99 A SIP conference is an association of SIP user agents (i.e. 100 conference participants) with a central point (i.e. a conference 101 focus) where the focus has direct peer-wise relationships with the 102 participants by maintaining a separate SIP dialog with each. 104 The focus is a SIP user agent which has abilities to host SIP 105 conferences including their creation, maintenance, and manipulation 106 using SIP call control means and potentially other non-SIP means. 108 In this tightly coupled model, the SIP conference graph is always a 109 star. The conference focus maintains the correlation among 110 conference's dialogs internally. 112 The conference focus can be implemented either by a participant or by 113 a separate application server. 115 In the first case, a focus is typically capable of hosting a simple 116 ad-hoc conference only. We envision that such basic conference can 117 be established using SIP call control primitives only. 119 A dedicated conference server, in addition to the basic features, 120 offers richer functionality including simultaneous conferences, large 121 scalable conferences, reserved conferences, and managed conferences. 122 A conferencing server can support any subset of the advanced 123 conferencing functions presented in this document. 125 The media graph of a SIP conference can be centralized, 126 de-centralized, or any combination of both and potentially differ per 127 media type. In centralized case, the media sessions are established 128 between the focus and each one of the participants. In 129 de-centralized (i.e. distributed) case, the media graph is a 130 (multicast or multi-unicast) mesh among the participants. 131 Consequently, the media processing (e.g. mixing) can be performed 132 either by the focus alone or by the participants. 134 Conference participants and third parties can have different roles 135 and privileges in a certain conference. For example, conferencing 136 policy can state that the rights to disconnect from and to invite to 137 a conference are limited to the conference chair only. 139 Throughout the document, by conference policies we mean a set of 140 parameters and rules (e.g. maximum number of participants, needs 141 chair-person supervision or not, password protected or not, duration, 142 a way of media mixing, etc.) that are defined at the onset of a 143 conference. Typically, conference policies would be specified by a 144 conference creator and need special privileges to be manipulated. 146 Throughout the document, by a conference state we mean a set of 147 information describing the conference in progress. This includes 148 participants' information (such as dialog identifiers), media 149 sessions in progress, the current loudest speaker, the current chair, 150 etc. 152 3. High Level Requirements 154 In addition to the requirements presented in this document, 155 supplementary requirements for conferencing policy, media mixing and 156 other manipulations, floor control, privileges control, etc. will be 157 discussed in separate documents. 159 3.1 Discovery Phase 161 Some of the requirements presented in this section can be met either 162 by configuration means or by using proprietary conventions. 163 Nevertheless, we feel that standard means for implementing these 164 functions by automata MUST be defined. 166 REQ-1: Discovery of a location of an arbitrary SIP conferencing 167 server(s). 169 REQ-2: Given a SIP AOR of a certain entity, resolution whether the 170 SIP entity has focus capabilities. 172 REQ-3: Given a global identifier of a particular conference, locating 173 the conference focus. 175 REQ-4: Given a global identifier of a particular conference, 176 obtaining the conference properties. 178 REQ-5: Given a global identifier of a particular conference, 179 obtaining the conference state information. 181 3.2 Conference Creation 183 Given a focus location, a means MUST be defined for an interested 184 entity (including a user agent) to implement the procedures below: 186 REQ-1: Creation of an ad-hoc conference identifier and the conference 187 with specified properties. 189 REQ-2: Creation of a reserved conference identifier for a conference 190 with specified properties. 192 REQ-3: Specifying properties upon conference creation in any of the 193 following ways: default, profiles and explicitly. 195 3.3 Conference Termination 197 REQ-1: Given a conference identifier, a means MUST be defined for a 198 user agent to disconnect all participants from the conference and 199 terminate the conference including the release of the associated 200 resources. 202 REQ-2: A means MAY be defined for requesting a focus to revert a 203 two-party conference to a basic SIP point-to-point session including 204 the release of the associated conferencing resources. 206 3.4 Participants' Manipulations 208 Some of the requirements presented in this section can be met by 209 human intervention, configuration means, or by using proprietary 210 conventions. Nevertheless, we feel that standard means for 211 implementing these functions by automata MUST be defined. 213 3.4.1 Participation of a Conference-unaware User Agent 215 REQ-1: Focus MUST be able to invite and disconnect an RFC 3261 216 compliant only SIP user agent to and from a SIP conference. 218 REQ-2: An RFC 3261 compliant only SIP user agent MUST be able to 219 dial-in to a particular SIP conference. In this case, only the human 220 knows that he/she is connected to the conference. 222 3.4.2 Dial-Out Scenarios 224 REQ-1: A means MUST be defined for a focus to invite another user 225 agent to one of the focus' conferences. This procedure MUST result 226 in the establishment of a single SIP dialog between the two. 228 REQ-2: Given an existing SIP dialog between two user agents, if at 229 least one User agent has focus capabilities, a means MUST be defined 230 for the conference focus to invite the other user agent to one of the 231 focus' conferences without additional SIP dialog establishment. 233 REQ-3: An invitation to a user agent to join a conference MUST 234 include a standard indication that it is a conference and the 235 conference identifier. 237 3.4.3 Dial-In Scenarios 239 REQ-1: A means MUST be defined for a user agent to create an ad-hoc 240 conference with default properties (as per "Conference Creation" 241 REQ-1 above) and to become a participant using a single SIP dialog. 243 REQ-2: Given a reserved conference identifier, a means MUST be 244 defined for a user agent to activate the conference and to become a 245 participant using a single SIP dialog. 247 REQ-3: Given a conference identifier of an active conference, a means 248 MUST be defined for a user agent to dial-in the conference and to 249 become a participant using a single SIP dialog between the two. 251 REQ-4: Given an identifier of one of the dialogs of a particular 252 active conference, a means MUST be defined for a user agent to 253 dial-in the conference and to become a participant. 255 3.4.4 Third Party Invitation to a Conference 257 REQ-1: Given a conference identifier, a means MUST be defined for a 258 user agent to invite another user agent to this conference. 260 REQ-2: Given an identifier of one of the dialogs of a particular 261 active conference, a means MUST be defined for a user agent to invite 262 another user agent to this conference. 264 REQ-3: Given a conference identifier, a means SHOULD be defined for a 265 user agent to invite a list of user agents to this conference (a 266 so-called "mass invitation"). 268 3.4.5 Participants' Removal 270 REQ-1: A means MUST be defined for a conference focus to remove a 271 conference participant from the conference. 273 REQ-2: Given a conference identifier, a means MUST be defined for a 274 user agent to remove a participant from the conference. 276 REQ-3: Given an identifier of one of the dialogs of a particular 277 active conference, a means MUST be defined for a user agent to remove 278 a participant from the conference. 280 REQ-4: Given a conference identifier, a means MUST be defined for a 281 user agent to remove all the participants from the conference. 283 REQ-5: Given a conference identifier and a sub-list of participants, 284 a means MAY be defined for a user agent to remove the specified 285 participants from the conference (a so-called "mass ejection"). 287 3.4.6 Participants' Privacy 289 A conference focus SHOULD support the procedures described in this 290 section. A conference participant MAY support the procedures 291 described in this section. The requirements imply that "anonymizing" 292 operations MUST be performed on all: the call control, the media 293 control and the media content when appropriate. 295 REQ-1: A conference participant joins the conference "anonymously", 296 i.e. his/her presence can be announced but without disclosing 297 his/her identity. 299 REQ-2: A conference participant requests a focus for anonymous 300 participation in the conference. 302 REQ-3: A conference participant joins a conference in a "hidden 303 mode", i.e. his/her both presence and identity are not to be 304 disclosed to other participants. 306 REQ-4: A conference participant requests a focus for participation in 307 the conference in a hidden mode. 309 3.5 Conference State Information 311 3.5.1 Description 313 By a conference state we mean a virtual database describing the 314 conference in progress. This includes different conference aspects - 315 participants' information (such as dialog identifiers and state), 316 media sessions in progress (such as current stream contributing 317 sources and encoding schemes), the current loudest speaker, the 318 current chair, etc. Conference state is the latest conference 319 snapshot triggered by changes in participants' state, conference 320 policy changes, etc. 322 REQ-1: A conference state virtual database MUST have a modular 323 definition, i.e. it MUST be possible to access different conference 324 aspects independently. 326 REQ-2: It MUST be possible to aggregate information relating to 327 different conference aspects in a single report. 329 REQ-3: A mechanism for extensible definition and registration of 330 conference state evolving aspects MUST be present. 332 REQ-4: A default conference state report MUST be defined. It SHOULD 333 contain A minimal useful set of information (e.g. a list of current 334 conference participants). 336 3.5.2 Dissemination of Changes 338 REQ-1: A means MUST be defined for reporting the conference state 339 changes to interested parties (including non-conference participants) 340 in a timely manner. 342 REQ-2: A means MUST be defined for a SIP user agent to express its 343 interest in selected state changes only. 345 REQ-3: A means MUST be defined for a SIP user agent to express the 346 minimum interval between receiving state change reports. 348 REQ-4: It MUST be possible to aggregate recent changes in a single 349 reporting event. 351 REQ-5: Default conference state change reports MUST be defined. They 352 SHOULD contain minimal useful to the participants information (e.g. 353 participants' joining and leaving the conference). 355 3.5.3 On-demand Information Dissemination 357 REQ-1: A means MUST be defined to disseminate any conference state 358 information to interested parties (including SIP user agents) 359 on-demand. 361 REQ-2: A means MUST be defined for an interested party (including a 362 SIP user agent) to request conference state information of a 363 particular conference defined by the conference identifier. 365 REQ-3: A means MUST be defined for an interested party (including a 366 SIP user agent) to specify the subset of the conference state 367 information it wants and capable to receive. 369 3.6 Focus Role Migration 371 REQ-1: A procedure for delegating a focus role by the current focus 372 to another participant MUST be defined. 374 REQ-2: A procedure for requesting a conference focus to transfer its 375 role to another participant MUST be defined. 377 REQ-3: A procedure for on-demand unconditional transfer of the focus 378 role to a different participant MUST be defined. 380 REQ-4: A detection procedure for a focus failure condition MUST be 381 defined. 383 3.7 Side-bar Conferences 385 A standard means MUST be defined in order to implement the operations 386 defined in this section below. 388 REQ-1: A user agent (not a conference participant) joins a side-bar 389 within the conference by SIP means. 391 REQ-2: A user agent (not a conference participant) is invited to a 392 side-bar within the conference by SIP means. 394 REQ-3: A conference participant creates a side-bar conference with 395 one or more participants in a conference by SIP means. 397 REQ-4: A conference participant joins a side-bar within the 398 conference by SIP means. 400 REQ-5: A conference participant is invited to a side-bar within the 401 conference by SIP means. 403 REQ-6: A conference-unaware user agent (a participant or not) creates 404 and participates in side-bar conferences. It MAY be achieved by 405 non-SIP means. 407 REQ-7: A conference participant creates side-bar conferences within 408 the conference without establishing any additional SIP dialogs with 409 the focus. It MAY be achieved by non-SIP means. 411 REQ-8: A conference participant joins any number of side-bars within 412 the conference without establishing any additional SIP dialogs with 413 the focus. It MAY be achieved by non-SIP means. 415 REQ-9: A conference participant is invited to any number of side-bars 416 within the conference without establishing any additional SIP dialogs 417 with the focus. It MAY be achieved by non-SIP means. 419 3.8 Cascading of Conferences 421 "Cascading of Conferences" is a term that has different meanings in 422 different contexts. Some examples are listed below: 424 - Peer-to-peer chaining of signaling. (Many ways exist to 425 build the media graph in this case.) 427 - Conferences have hierarchal signaling relations. (Many 428 ways exists to build the media graph in this case.) 430 - "Cascading" is used to distribute the media "mixing" 431 only. The distribution of signaling is not required. 433 As it can be seen from the examples, each will define a different set 434 of requirements. 436 3.9 SIMPLE and SIP Conferencing Coordination 438 REQ-1: SIMPLE-based Presence and Instant Messaging architecture 439 SHOULD fit into the general SIP Conferencing architecture. 441 REQ-2: A scenario where a multimedia SIP conference and a multiparty 442 IM conversation take place among the same group of participants MUST 443 be addressed. 445 REQ-3: A scenario where a side-bar or/and a sub-IM-conference is 446 being held as a part of SIP conference MUST be addressed. 448 4. Security Considerations 450 This document discusses high level requirements for SIP conferencing. 451 Conferencing has some specific security requirements which will be 452 summarized here at a very high level. 454 All of the operations and functions described in this document need 455 to be authorized by a focus or a participant. It is expected that 456 conferences will be governed by a set of authorization rules defined 457 as a part of the conference policy. In order for the conference 458 policy to be implemented, the focus needs to be able to authenticate 459 potential participants. Normal SIP mechanisms including Digest 460 authentication and certificates can be used. These conference 461 specific security requirements will be discussed in detail in the 462 protocol documents. 464 Conferencing also has privacy implications. Some of these are 465 discussed in this document. Standard SIP mechanisms for a user agent 466 to request privacy should be utilized by a focus and will be detailed 467 in the protocol documents. 469 5. Contributors 471 This work is based on the discussions among the members of the SIP 472 Conferencing design team. 474 6. References 476 6.1 Normative References 478 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 482 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 483 Session Initiation Protocol", RFC 3261, June 2002. 485 6.2 Informative References 487 Authors' Addresses 489 Orit Levin 490 Microsoft Corporation 491 One Microsoft Way 492 Redmond, WA 98052 494 EMail: oritl@microsoft.com 496 Roni Even 497 Polycom 498 94 Derech Em Hamoshavot 499 Petach Tikva, Israel 501 EMail: roni.even@polycom.co.il 503 Intellectual Property Statement 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org. 527 Disclaimer of Validity 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Copyright Statement 539 Copyright (C) The Internet Society (2004). This document is subject 540 to the rights, licenses and restrictions contained in BCP 78, and 541 except as set forth therein, the authors retain all their rights. 543 Acknowledgment 545 Funding for the RFC Editor function is currently provided by the 546 Internet Society.