idnits 2.17.1 draft-ietf-sipping-conferencing-requirements-00.txt: -(54): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(59): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(228): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(368): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(434): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(451): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 (April 23, 2003) is 7674 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 460, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group O. Levin 3 Internet-Draft RADVISION 4 Expires: October 22, 2003 R. Even 5 Polycom 6 April 23, 2003 8 High Level Requirements for Tightly Coupled SIP Conferencing 9 draft-ietf-sipping-conferencing-requirements-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as 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 http:// 26 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 October 22, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document examines a wide range of conferencing requirements for 40 tightly coupled SIP conferences. Separate documents will map the 41 requirements to existing protocol primitives, define new protocol 42 extensions, and introduce new protocols as needed. Together, these 43 documents will provide a guide for building interoperable SIP 44 conferencing applications. 46 Table of Contents 48 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. An Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. High Level Requirements . . . . . . . . . . . . . . . . . . 4 51 3.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2 Conference Creation . . . . . . . . . . . . . . . . . . . . 5 53 3.3 Conference Termination . . . . . . . . . . . . . . . . . . . 5 54 3.4 Participants� Manipulations . . . . . . . . . . . . . . . . 5 55 3.4.1 Participation of a Conference-unaware User Agent . . . . . . 5 56 3.4.2 Dial-Out Scenarios . . . . . . . . . . . . . . . . . . . . . 6 57 3.4.3 Dial-In Scenarios . . . . . . . . . . . . . . . . . . . . . 6 58 3.4.4 Third Party Invitation to a Conference . . . . . . . . . . . 6 59 3.4.5 Participants� Removal . . . . . . . . . . . . . . . . . . . 6 60 3.4.6 Participants� Privacy . . . . . . . . . . . . . . . . . . . 7 61 3.5 Conference State Information . . . . . . . . . . . . . . . . 7 62 3.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5.2 Dissemination of Changes . . . . . . . . . . . . . . . . . . 8 64 3.5.3 On-demand Information Dissemination . . . . . . . . . . . . 8 65 3.6 Focus Role Migration . . . . . . . . . . . . . . . . . . . . 9 66 3.7 Side-bar Conferences . . . . . . . . . . . . . . . . . . . . 9 67 3.8 Cascading of Conferences . . . . . . . . . . . . . . . . . . 10 68 3.9 SIMPLE and SIP Conferencing Coordination . . . . . . . . . . 10 69 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 70 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 71 Normative References . . . . . . . . . . . . . . . . . . . . 11 72 Informative References . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . 12 76 1. Scope 78 This document examines a wide range of conferencing requirements for 79 tightly coupled SIP (RFC 3261 [2]) conferencing. 81 The requirements are grouped by subjects in various areas allowing 82 solutions to progress in parallel. 84 Separate documents will map the requirements to existing protocol 85 primitives, define new protocol extensions, and introduce new 86 protocols as needed. 88 Together, these documents will provide a guide for building 89 interoperable SIP conferencing applications. 91 2. An Overview 93 A SIP conference is an association of SIP user agents (i.e. 94 conference participants) with a central point (i.e. a conference 95 focus) where the focus has direct peer-wise relationships with the 96 participants by maintaining a separate SIP dialog with each. 98 The focus is a SIP user agent which has abilities to host SIP 99 conferences including their creation, maintenance, and manipulation 100 using SIP call control means and potentially other non-SIP means. 102 In this tightly coupled model, the SIP conference graph is always a 103 star. The conference focus maintains the correlation among 104 conference's dialogs internally. 106 The conference focus can be implemented either by a participant or by 107 a separate application server. 109 In the first case, a focus is typically capable of hosting a simple 110 ad-hoc conference only. We envision that such basic conference can 111 be established using SIP call control primitives only. 113 A dedicated conference server, in addition to the basic features, 114 offers richer functionality including simultaneous conferences, large 115 scalable conferences, reserved conferences, and managed conferences. 116 A conferencing server can support any subset of the advanced 117 conferencing functions presented in this document. 119 The media graph of a SIP conference can be centralized, 120 de-centralized, or any combination of both and potentially differ per 121 media type. In centralized case, the media sessions are established 122 between the focus and each one of the participants. In de-centralized 123 (i.e. distributed) case, the media graph is a (multicast or 124 multi-unicast) mesh among the participants. Consequently, the media 125 processing (e.g. mixing) can be performed either by the focus alone 126 or by the participants. 128 Conference participants and third parties can have different roles 129 and privileges in a certain conference. For example, conferencing 130 policy can state that the rights to disconnect from and to invite to 131 a conference are limited to the conference chair only. 133 Throughout the document, by conference policies we mean a set of 134 parameters and rules (e.g. maximum number of participants, needs 135 chair-person supervision or not, password protected or not, duration, 136 a way of media mixing, etc.) that are defined at the onset of a 137 conference. Typically, conference policies would be specified by a 138 conference creator and need special privileges to be manipulated. 140 Throughout the document, by a conference state we mean a set of 141 information describing the conference in progress. This includes 142 participants� information (such as dialog identifiers), media 143 sessions in progress, the current loudest speaker, the current chair, 144 etc. 146 3. High Level Requirements 148 In addition to the requirements presented in this document, 149 supplementary requirements for conferencing policy, media mixing and 150 other manipulations, floor control, privileges control, etc. will be 151 discussed in separate documents. 153 3.1 Discovery Phase 155 Some of the requirements presented in this section can be met either 156 by configuration means or by using proprietary conventions. 157 Nevertheless, we feel that standard means for implementing these 158 functions by automata MUST be defined. 160 REQ -1: Discovery of a location of an arbitrary SIP conferencing 161 server(s). 163 Editor�s Note: No solution currently exists. 165 REQ -2: Given a SIP AOR of a certain entity, resolution whether the 166 SIP entity has focus capabilities. 168 Editor�s Note: No solution currently exists. 170 REQ -3: Given a global identifier of a particular conference, 171 locating the conference focus. 173 REQ -4: Given a global identifier of a particular conference, 174 obtaining the conference properties. 176 REQ -5: Given a global identifier of a particular conference, 177 obtaining the conference state information. 179 3.2 Conference Creation 181 Given a focus location, a means MUST be defined for an interested 182 entity (including a user agent) to implement the procedures below: 184 REQ -1: Creation of an ad-hoc conference identifier and the 185 conference with specified properties. 187 REQ -2: Creation of a reserved conference identifier for a conference 188 with specified properties. 190 REQ -3: Specifying properties upon conference creation in any of the 191 following ways: default, profiles and explicitly. 193 3.3 Conference Termination 195 REQ -1: Given a conference identifier, a means MUST be defined for a 196 user agent to disconnect all participants from the conference and 197 terminate the conference including the release of the associated 198 resources. 200 REQ -2: A means MAY be defined for requesting a focus to revert a 201 two-party conference to a basic SIP point-to-point session including 202 the release of the associated conferencing resources. 204 3.4 Participants� Manipulations 206 Some of the requirements presented in this section can be met by 207 human intervention, configuration means, or by using proprietary 208 conventions. Nevertheless, we feel that standard means for 209 implementing these functions by automata MUST be defined. 211 3.4.1 Participation of a Conference-unaware User Agent 213 REQ -1: Focus MUST be able to invite and disconnect an RFC 3261 214 compliant only SIP user agent to and from a SIP conference. 216 REQ -2: RFC 3261 compliant only SIP user agent MUST be able to 217 dial-in a particular SIP conference. In this case, only the human 218 knows that he/she is connected to the conference. 220 3.4.2 Dial-Out Scenarios 222 REQ -1: A means MUST be defined for a focus to invite another user 223 agent to one of the focus� conferences. This procedure MUST result in 224 establishing of a single SIP dialog between the two. 226 REQ -2: Given an existent SIP dialog between two user agents, where 227 at least one with focus capabilities, a means MUST be defined for the 228 conference focus to invite the other user agent to one of the focus� 229 conferences without additional SIP dialog establishment. 231 REQ -3: An invitation to a user agent to join a conference MUST 232 include a standard indication that it is "a conference" and the 233 conference identifier. 235 3.4.3 Dial-In Scenarios 237 REQ -1: A means MUST be defined for a user agent to create an ad-hoc 238 conference with default properties (as per "Conference Creation" REQ 239 -1 above) and to become its participant using a single SIP dialog. 241 REQ -2: Given a reserved conference identifier, a means MUST be 242 defined for a user agent to activate the conference and to become its 243 participant using a single SIP dialog. 245 REQ -3: Given a conference identifier of an active conference, a 246 means MUST be defined for a user agent to dial-in the conference and 247 to become its participant using a single SIP dialog between the two. 249 REQ -4: Given an identifier of one of the dialogs of a particular 250 active conference, a means MUST be defined for a user agent to 251 dial-in the conference and to become its participant. 253 3.4.4 Third Party Invitation to a Conference 255 REQ -1: Given a conference identifier, a means MUST be defined for a 256 user agent to invite another user agent to this conference. 258 REQ -2: Given an identifier of one of the dialogs of a particular 259 active conference, a means MUST be defined for a user agent to invite 260 another user agent to this conference. 262 REQ -3: Given a conference identifier, a means SHOULD be defined for 263 a user agent to invite a list of user agents to this conference (a 264 so-called "mass invitation"). 266 3.4.5 Participants� Removal 267 REQ -1: A means MUST be defined for a conference focus to remove a 268 conference participant from the conference. 270 REQ -2: Given a conference identifier, a means MUST be defined for a 271 user agent to remove a participant from the conference. 273 REQ -3: Given an identifier of one of the dialogs of a particular 274 active conference, a means MUST be defined for a user agent to remove 275 a participant from the conference. 277 REQ -4: Given a conference identifier, a means MUST be defined for a 278 user agent to remove all the participants from the conference. 280 REQ -5: Given a conference identifier and a sub-list of participants, 281 a means MAY be defined for a user agent to remove the specified 282 participants from the conference (a so-called "mass ejection"). 284 3.4.6 Participants� Privacy 286 A conference focus SHOULD support the procedures described in this 287 section. A conference participant MAY support the procedures 288 described in this section. The requirements imply that "anonymizing" 289 operations MUST be performed on all: the call control, the media 290 control and the media content when appropriate. 292 REQ -1: A conference participant joins the conference "anonymously", 293 i.e. his/her presence can be announced but without disclosing his/her 294 identity. 296 REQ -2: A conference participant requests a focus for anonymous 297 participation in the conference. 299 REQ -3: A conference participant joins a conference in a "hidden 300 mode", i.e. his/her both presence and identity are not to be 301 disclosed to other participants. 303 REQ -4: A conference participant requests a focus for participation 304 in the conference in a hidden mode. 306 3.5 Conference State Information 308 3.5.1 Description 310 By a conference state we mean a virtual database describing the 311 conference in progress. This includes different conference aspects - 312 participants� information (such as dialog identifiers and state), 313 media sessions in progress (such as current stream contributing 314 sources and encoding schemes), the current loudest speaker, the 315 current chair, etc. Conference state is the latest conference 316 snapshot triggered by changes in participants� state, conference 317 policy changes, etc. 319 REQ -1: Conference state virtual database MUST have a modular 320 definition, i.e. it MUST be possible to access different conference 321 aspects independently. 323 REQ -2: It MUST be possible to aggregate information relating to 324 different conference aspects in a single report. 326 REQ -3: A mechanism for extensible definition and registration of 327 conference state evolving aspects MUST be present. 329 REQ -4: A default conference state report MUST be defined. It SHOULD 330 contain minimal useful to participants information (e.g. a list of 331 current conference participants). 333 3.5.2 Dissemination of Changes 335 REQ -1: A means MUST be defined for reporting the conference state 336 changes to interested parties (including non-conference participants) 337 in a timely manner. 339 REQ -2: A means MUST be defined for a SIP user agent to express its 340 interest in selected state changes only. 342 REQ -3: A means MUST be defined for a SIP user agent to express the 343 minimum interval between receiving state change reports. 345 REQ -4: It MUST be possible to aggregate recent changes in a single 346 reporting event. 348 REQ -5: Default conference state change reports MUST be defined. They 349 SHOULD contain minimal useful to the participants information (e.g. 350 participants� joining and leaving the conference). 352 3.5.3 On-demand Information Dissemination 354 REQ -1: A means MUST be defined to disseminate any conference state 355 information to interested parties (including SIP user agents) 356 on-demand. 358 REQ -2: A means MUST be defined for an interested party (including 359 SIP user agents) to request conference state information of a 360 particular conference defined by the conference identifier. 362 REQ -3: A means MUST be defined for an interested party (including 363 SIP user agents) to specify the subset of the conference state 364 information it wants and capable to receive. 366 3.6 Focus Role Migration 368 Editor�s Note: We should decide whether the requirements below can be 369 met by using SIP or non-SIP means. 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) 404 creates and participates in side-bar conferences. It MAY be achieved 405 by 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 416 side-bars within the conference without establishing any additional 417 SIP dialogs 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 build the media 425 graph in this case.) 426 - Conferences have hierarchal signaling relations. (Many ways exists to 427 build the media graph in this case.) 428 - "Cascading" is used to distribute the media "mixing" only. The 429 distribution of signaling is not required. 431 As it can be seen from the examples, each will define a different set 432 of requirements. 434 Editor�s Note: We need to discuss which of the architectures require 435 our attention as a part of the SIP conferencing force. 437 3.9 SIMPLE and SIP Conferencing Coordination 439 REQ -1: SIMPLE-based Presence and Instant Messaging architecture 440 SHOULD fit into the general SIP Conferencing architecture. 442 REQ -2: A scenario where a multimedia SIP conference and a multiparty 443 IM conversation take place among the same group of participants MUST 444 be addressed. 446 REQ -3: A scenario where a side-bar or/and a sub-IM-conference is 447 being held as a part of SIP conference MUST be addressed. 449 4. Security Considerations 451 Editor�s Note: Will be provided in the next version of the document. 453 5. Contributors 455 This work is based on the discussions among the members of the SIP 456 Conferencing design team. 458 Normative References 460 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 461 Levels", BCP 14, RFC 2119, March 1997. 463 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 464 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 465 Session Initiation Protocol", RFC 3261, June 2002. 467 Informative References 469 Authors' Addresses 471 Orit Levin 472 RADVISION 473 266 Harristown Road 474 Glen Rock, NJ 75024 476 EMail: orit@radvision.com 478 Roni Even 479 Polycom 480 94 Derech Em Hamoshavot 481 Petach Tikva, Israel 483 EMail: roni.even@polycom.co.il 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 intellectual property or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; neither does it represent that it 492 has made any effort to identify any such rights. Information on the 493 IETF's procedures with respect to rights in standards-track and 494 standards-related documentation can be found in BCP-11. Copies of 495 claims of rights made available for publication and any assurances of 496 licenses to be made available, or the result of an attempt made to 497 obtain a general license or permission for the use of such 498 proprietary rights by implementors or users of this specification can 499 be obtained from the IETF Secretariat. 501 The IETF invites any interested party to bring to its attention any 502 copyrights, patents or patent applications, or other proprietary 503 rights which may cover technology that may be required to practice 504 this standard. Please address the information to the IETF Executive 505 Director. 507 Full Copyright Statement 509 Copyright (C) The Internet Society (2003). All Rights Reserved. 511 This document and translations of it may be copied and furnished to 512 others, and derivative works that comment on or otherwise explain it 513 or assist in its implementation may be prepared, copied, published 514 and distributed, in whole or in part, without restriction of any 515 kind, provided that the above copyright notice and this paragraph are 516 included on all such copies and derivative works. However, this 517 document itself may not be modified in any way, such as by removing 518 the copyright notice or references to the Internet Society or other 519 Internet organizations, except as needed for the purpose of 520 developing Internet standards in which case the procedures for 521 copyrights defined in the Internet Standards process must be 522 followed, or as required to translate it into languages other than 523 English. 525 The limited permissions granted above are perpetual and will not be 526 revoked by the Internet Society or its successors or assignees. 528 This document and the information contained herein is provided on an 529 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 530 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 531 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 532 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 533 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Acknowledgement 537 Funding for the RFC Editor function is currently provided by the 538 Internet Society.