idnits 2.17.1 draft-levin-sipping-conferencing-requirements-02.txt: -(213): 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-levin-sipping-conferencing-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-levin-sipping-conferencing-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-levin-sipping-conferencing-', but the file name used is 'draft-levin-sipping-conferencing-requirements-02' == There are 11 instances of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 498 has weird spacing: '...haining of co...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '5' on line 348 looks like a reference -- Missing reference section? '8' on line 493 looks like a reference -- Missing reference section? '1' on line 534 looks like a reference Summary: 5 errors (**), 1 flaw (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft O. Levin/RADVISION 3 Document: R. Even/Polycom 4 draft-levin-sipping-conferencing- P. Koskelainen/Columbia U. 5 requirements-02.txt S. Sen/Nortel 7 November 2002 Expires: May 2003 9 Requirements for Tightly Coupled SIP Conferencing 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 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document examines a wide range of conferencing requirements 34 being applied to a tightly coupled SIP Star conference. 36 Separate documents will map the requirements to existing protocol 37 primitives, define new protocol extensions, and introduce new 38 protocols. 40 Together, these documents would provide a guide for building 41 interoperable SIP conferencing applications. 43 Requirements for Tightly Coupled SIP Conferencing 45 Table of Contents 46 1. SCOPE............................................................3 48 2. TIGHTLY COUPLED SIP CONFERENCING FRAMEWORK.......................3 50 3. DISCOVERY PHASE REQUIREMENTS.....................................4 51 SIP ENTITY CONFERENCING CAPABILITIES DISCOVERY..............................4 52 A PARTICULAR CONFERENCE LOCATION AND INFORMATION DISCOVERY.....................4 53 4. BASIC CONFERENCING REQUIREMENTS..................................5 54 PARTICIPATION OF RFC 3261 COMPLIANT ONLY (I.E. BASIC) USER AGENT...............5 55 CONFERENCE ESTABLISHMENT IN DIAL-OUT SCENARIOS..............................5 56 CONFERENCE ESTABLISHMENT IN DIAL-IN SCENARIOS...............................5 57 THIRD PARTY INVITATION TO A CONFERENCE.....................................6 58 DISCONNECTION OF CONFERENCE MEMBERS AND CONFERENCE TERMINATION..................6 59 CONFERENCE MEMBER PRIVACY................................................7 60 5. CONFERENCE STATE DISSEMINATION REQUIREMENTS......................7 61 REPORT OF CHANGES......................................................7 62 ON-DEMAND DISSEMINATION.................................................7 63 6. MISCELLANEOUS REQUIREMENTS.......................................8 65 7. MEDIA CONTROL REQUIREMENTS.......................................8 67 8. CONFERENCE ACCESS CONTROL LIST (ACL).............................9 69 9. CONFERENCE PARTICIPANT PRIVILEGES................................9 70 MODEL................................................................9 71 REQUIREMENTS.........................................................10 72 10. FLOOR CONTROL..................................................10 74 11. CASCADING OF CONFERENCES.......................................10 76 12. SIDE-BAR CONFERENCES...........................................11 78 13. SIMPLE AND SIP CONFERENCING COORDINATION.......................11 80 14. CONVENTIONS USED IN THIS DOCUMENT..............................11 82 15. SECURITY CONSIDERATIONS........................................11 84 16. AUTHOR'S ADDRESSES.............................................11 86 17. REFERENCES.....................................................12 87 Requirements for Tightly Coupled SIP Conferencing 89 1. Scope 91 This document examines a wide range of conferencing requirements 92 being applied to a tightly coupled SIP Star conference. 94 The requirements are grouped according to their topics in order to 95 define solutions to different topics in parallel. 97 Separate documents will map the requirements to existing protocol 98 primitives, define new protocol extensions, and introduce new 99 protocols. 101 Together, these documents would provide a guide for building 102 interoperable SIP conferencing applications. 104 2. Tightly Coupled SIP Conferencing Framework 106 SIP conference is an association of SIP User Agents (e.g. conference 107 members) with a central member (e.g. a conference focus), which has 108 a direct peer-wise relationship with each other member by means of a 109 SIP dialog. Each dialog can belong to a different SIP session. 111 Focus is a SIP UA which has abilities to host SIP conferences 112 including its creation, maintenance and manipulation using SIP call 113 control means. 115 In this framework, the SIP conference graph is always a star. The 116 conference focus maintains the correlation among conference's 117 dialogs internally. 119 The conference state is defined by a set of information describing 120 the conference in progress. This MAY include the following: all or 121 some participant information such as dialog-ids, media sessions in 122 progress, etc. A complete conference state definition can be found 123 in [5]. 125 The conference can be hosted either by a participating entity (e.g. 126 terminal) or by a separate application server. 128 Typically to the first case, a terminal is capable of hosting a 129 limited ad hoc conference. Such conference may be established using 130 basic call control primitives. 132 Editor�s Note: This is similar to traditional offering from PSTN 133 service providers in audio conferencing such as being able to join 134 independent calls into a multiparty conference. 136 Application server offers more robust options including reservation, 137 large conferences, and managed conferences. In addition to the basic 138 Requirements for Tightly Coupled SIP Conferencing 140 functionality, the conferencing server supports any subset of 141 advanced conferencing features, presented in this document. In this 142 case, the focus is one of the logical entities comprising the 143 conferencing application server. 145 The conference properties are defined by a list of configuration 146 parameters (e.g., maximum number of ports/participants, needs chair- 147 person supervision or not, password protected or not, duration, 148 etc.) that a conference creator can request from the conference 149 service. Conference properties are configured at the onset of a 150 conference and, typically, need special privileges to be changed. 152 Conference participants MAY have different roles or privileges in a 153 conference. For example, a conference Chair MAY have the right to 154 disconnect users from a conference, or terminate the conference. 156 SIP conference MAY have media sessions similarly to standard two- 157 party SIP calls. The conference media graph is constructed 158 independently from the SIP star conference. For example, it can be 159 centralized (e.g. following the star graph of the SIP conference) or 160 it can be de-centralized (such as multicast mesh among the 161 participating entities). As it can be seen from the examples, the 162 function of the media processing can be performed either by the 163 conference focus alone or by each one of the participating entities. 165 3. Discovery Phase Requirements 167 SIP Entity Conferencing Capabilities Discovery 169 Editor�s Note: The following requirements can always be achieved by 170 configuration means or/and human agreement. Nevertheless, we feel 171 that automatic means MUST be defined. 173 CAPD-1: A standard means MUST be defined for automatic discovery of 174 location of conferencing application server(s). 176 CAPD-2: A standard format for expressing UA�s conferencing 177 capabilities MUST be defined. Each SIP entity MUST be able to 178 independently express its capabilities as a conference member only 179 and as a conference focus. 181 CAPD-3: A standard means MUST be defined for retrieving conferencing 182 capabilities of a known SIP entity. In this regard, the SIP entity 183 can be either a user device (e.g. a terminal) or a dedicated 184 conferencing server. 186 A Particular Conference Location and Information Discovery 188 CNFD-1: Given a global identifier of a particular conference, a 189 standard means MUST be defined for locating the hosting entity of 190 this conference. 192 Requirements for Tightly Coupled SIP Conferencing 194 CNFD-2: Given a global identifier of a particular conference, a 195 standard means MUST be defined for obtaining the conference 196 properties. 198 CNFD-3: Given a global identifier of a particular conference, a 199 standard means MUST be defined for obtaining the conference state 200 information. 202 4. Basic Conferencing Requirements 204 Participation of RFC 3261 compliant only (i.e. basic) User Agent 206 BSC-1: A conference focus MUST be able to invite and disconnect an 207 RFC 3261 compliant only SIP UA to and from a SIP conference. 209 BSC-2: RFC 3261 compliant only SIP UA�s MUST be able to dial-in a 210 particular SIP conference. In this case, only the user behind its UA 211 knows that he dials into the conference. 213 Editor�s Note: In this case, the conference can be identified either 214 by manually populating the Request-URI field with the conference 215 identifier or, alternatively, by using an IVR service. 217 Conference Establishment in Dial-Out Scenarios 219 DOUT-1: A means MUST be defined for a conference focus to invite a 220 User Agent to one of its active conferences (specified by a 221 conference identifier) over an existing SIP dialog between the two. 222 As a result, the dialog becomes a part of the conference. 224 DOUT-2: A means MUST be defined for a conference focus to invite a 225 User Agent by establishing a new SIP dialog between the two together 226 with specifying the identifier of the conference. The dialog belongs 227 to the conference. 229 Conference Establishment in Dial-In Scenarios 231 DIN-1: Provided desired conference properties and the hosting entity 232 location (as per DS-1 and DS-2), a means MUST be defined for a UA to 233 create an ad-hoc conference and to become its member. A means MUST 234 be defined for creating a global conference identifier for this ad- 235 hoc scenario. 237 DIN-2: Provided a reserved conference identifier, a means MUST be 238 defined for a UA to activate the conference and to become its 239 member. 241 Requirements for Tightly Coupled SIP Conferencing 243 DIN-3: Provided a reserved conference identifier, a means MUST be 244 defined for a UA to dial-in an active conference and to become its 245 member. 247 DIN-4: Provided one of the dialogs ID, belonging to a particular 248 active conference, a means MUST be defined for a UA to dial-in an 249 active conference and to become its member. 251 Third Party Invitation to a Conference 253 THIP-1: Provided a conference identifier, a means MUST be defined 254 for a UA to invite another UA to this conference. 256 THIP-2: Provided one of the dialogs ID, belonging to a particular 257 active conference, a means MUST be defined for a UA to invite 258 another UA to this conference. 260 THIP-3: Provided a conference identifier, a means MAY be defined for 261 a UA to invite a list of UAs to this conference (a so-called "mass 262 invitation"). 264 Disconnection of Conference Members and Conference Termination 266 TERM-1: A means MUST be defined for a conference focus to disconnect 267 a conference member from an active conference. 269 TERM-2: A means MAY be defined for a conference focus to revert a 270 two-party conference to a basic SIP point-to-point session (and 271 releasing internal conferencing resources). 273 TERM-3: Provided a conference identifier, a means MUST be defined 274 for a UA to disconnect another UA from this conference. 276 TERM-4: Provided one of the dialogs ID, belonging to a particular 277 active conference, a means MAY be defined for a UA to disconnect 278 another UA from this conference. 280 TERM-5: Provided a conference identifier, a means MAY be defined for 281 a UA to disconnect a list of UAs from this conference (a so-called 282 "mass feature"). 284 TERM-6: Provided a conference identifier, a means MUST be defined 285 for a UA to disconnect all members from this conference. 287 TERM-7: Provided a conference identifier, a means MAY be defined for 288 a UA to terminate this conference by disconnection all the members, 289 releasing conference resources together with the conference 290 identifier. 292 Editor�s note: Some of the requirements above overlap with each 293 other. 295 Requirements for Tightly Coupled SIP Conferencing 297 Conference Member Privacy 299 The following features depend both on focus�s capabilities and 300 policies and on members� capabilities. 302 A conference focus SHOULD support these. A conference member MAY 303 support these. 305 PRV-1: A conference member participates in a conference 306 "anonymously", meaning that its presence is known and can be 307 announced but without disclosing its identity. 309 PRV-2: A conference member requests anonymous participation from the 310 focus. 312 PRV-3: A conference member participates in a conference "in a hidden 313 mode", meaning that both its presence and its identity are not 314 disclosed. 316 PRV-4: A conference member requests participation in a hidden mode. 318 5. Conference State Dissemination Requirements 320 Report of Changes 322 CNG-1: It is expected that the set of events related a conference 323 state and required to be reported would grow with time. Therefore, a 324 mechanism for extensible definition/registration of new conference 325 state changes MUST be defined. 327 CNG-2: A means MUST be defined for reporting the conference state 328 changes to interested parties (including conference members) in a 329 timely manner. The report MAY include more than one change. 331 CNG-3: A means MUST be defined for a SIP UA to express its interest 332 in selected state changes only. 334 CNG-4: A means MUST be defined for a SIP UA to express the minimum 335 interval between receiving state change reports. 337 A means MUST be defined for reporting at least the following changes 338 in a conference state: 340 CNG-5: A new conference member joined the conference. 342 CNG-6: A Particular conference member left the conference. 344 On-demand Dissemination 345 Requirements for Tightly Coupled SIP Conferencing 347 ODD-1: A means MUST be defined to disseminate any conference state 348 information (as per [5]) to interested parties (i.e. SIP UAs) on- 349 demand. 351 ODD-2: A means MUST be defined for a SIP UA to request a conference 352 state information of a particular conference defined by the 353 conference identifier. 355 ODD-3: A means MUST be defined for a SIP UA to specify the subset of 356 the conference state information, it wants and capable to receive. 358 6. Miscellaneous Requirements 360 MISC-1: A procedure for delegating of a focus role by the current 361 focus to another member MUST be defined. 363 MISC-2: A procedure for requesting a conference focus to transfer 364 its role to another conference member MUST be defined. 366 MISC-3: A procedure for on-demand unconditional transfer of the 367 focus role to a different member MUST be defined. 369 MISC-4: A detection procedure for a conference focus failure 370 condition MUST be defined. 372 MISC-5: In case a conference focus failure, a procedure for 373 assigning a new conference focus MUST be defined. 375 Editor�s Note: This is a difficult for standardization requirement. 377 7. Media Control Requirements 379 This section is left for future study. 380 To this point, the listed below requirements have been identified: 382 MEDI-1: Each media session between the conference Server and a 383 participant in a conference MUST have a unique identity in the 384 conference space 386 MEDI-2: It MUST be possible for a user to participate in a sub-set 387 of media sessions of a conference 389 MEDI-3: It MUST be possible to modify media sessions of certain 390 subset of the participants without impacting the sessions of other 391 participants (e.g., introduce side-bar conversations between two 392 participants). 394 MEDI-4: It MUST be possible to modify a subset of the media sessions 395 of a participant during the conference (e.g., swap in and out 396 video). 398 Requirements for Tightly Coupled SIP Conferencing 400 MEDI-5: A media session of a participant MUST be in one of the 401 following states: 402 - Inactive : SDP attribute=inactive 403 - Active : opposite of inactive 404 - On-hold : SDP attribute=sendonly 405 - Disabled : media port = 0 407 MEDI-6: It MUST be possible for the conference server to mix a sub- 408 set of the active media sessions in a conference (e.g., mix audio 409 from two most audible speakers). 411 MEDI-7: It SHOULD be possible for a participant with appropriate 412 privileges to add (and delete) conference-wide media sessions into 413 (from) the conference, or modify their properties. 415 8. Conference Access Control List (ACL) 417 The purpose of the Access Control List is to define who is allowed 418 (or not allowed) to join the conference. If there is user�s join 419 attempt, but user is not in the ACL then (depending on the 420 conference policy), the conference chair MAY be consulted whether 421 the user can be accepted to join the conference. 423 ACL-1: There MUST be a mechanism to define Access Control List (ACL) 424 so that user�s joins can be pre-authorized (or denied). 426 ACL-2: It MUST be possible to add and delete users to/from ACL. 428 ACL-3: It MUST be possible to consult a user with appropriate 429 privileges (such as chair) when an unknown user tries to join the 430 conference. The chair may accept or deny the join attempt. 432 9. Conference Participant Privileges 434 Model 436 Conference participants MAY have different privileges. 438 In the simplest case, only two kinds of participants exist: the 439 conference Chair (with all the privileges), and normal Participants 440 (without any privileges). 442 For example, following privileges MAY be supported: 443 - Right to terminate a conference 444 - Right to disconnect participants 445 - Right to manage general conference properties 446 - Right to manage conference access control list (ACL) 447 - Right to manage conference-wide media sessions (e.g. add audio 448 session into conference) 449 - Right to manage other participant's session parameters (such as 450 media) 451 Requirements for Tightly Coupled SIP Conferencing 453 - Right to make real-time authorization (for join attempts) 454 - Right to hand-off all (or some of) the above privileges to 455 another participant 457 Some conferences may utilize more complex privilege definition and 458 hierarchy; such as guru-participants have the right to disconnect 459 participants. 461 Therefore, protocol mechanisms MUST be in place to translate these 462 rights into actions. 464 Requirements 466 PRIV-1: It MUST be possible to define different privileges to 467 different participants. 469 PRIV-2: It MAY be possible that different participant levels are 470 defined (e.g. senior-member, panelist). 472 PRIV-3: Rules MUST be defined for special cases, such as if chair 473 leaves suddenly, or chair tries to take privileges away from all 474 privilege holders. 476 10. Floor Control 478 Conference applications often have shared resources such as the 479 right to talk, input access to a limited-bandwidth video channel, or 480 a pointer or input focus in a shared application. 482 In many cases, it is desirable to be able to control who can provide 483 input (send/write/control, depending on the application) to the 484 shared resource. 486 Floor control enables applications or users to gain safe and 487 mutually exclusive or non-exclusive input access to the shared 488 object or resource. 490 This is an optional feature for conferencing applications. SIP 491 conferencing applications may decide not to implement this feature. 493 For detailed floor control requirements refer to [8]. 495 11. Cascading of Conferences 497 Cascading of conferences can be used for different purposes: 498 - Peer-to-peer chaining of conferencing applications 499 - Hierarchal relations among conferencing applications 500 - Distribution of media "mixers" 501 - Etc. 503 Requirements for Tightly Coupled SIP Conferencing 505 The three presented applications would result in conceptually 506 different sets of requirements. 508 Currently this work requires further study. 510 12. Side-bar Conferences 512 The 00 version of this draft suggests that side-bar conversations 513 within a conference are achieved as a part of Media Policy. 515 Currently this work requires further study. 517 13. SIMPLE and SIP Conferencing Coordination 519 SMPL-1: SIMPLE-based Presence and Instant Messaging architecture 520 SHOULD fit into general SIP Conferencing architecture. 522 SMPL-2: A scenario where a multimedia SIP conference and a 523 multiparty IM conversation takes place among the same group of 524 participants SHOULD be addressed. 526 SMPL-3: A scenario where a side-bar or/and a sub-IM-conference is 527 being held as a part of SIP conference SHOULD be addressed. 529 14. Conventions used in this document 531 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 532 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 533 this document are to be interpreted as described in RFC-2119 [1]. 535 15. Security Considerations 536 Security requirements will be addressed in the next version of this 537 document. 539 16. Author's Addresses 541 Orit Levin 542 RADVISION Inc. 543 266 Harristown Road, 544 Suite 201, 545 Glen Rock, NJ 07452 Phone: +1-201-689-6330 546 USA Email: orit@radvision.com 548 Roni Even 549 Polycom 550 94 Derech Em Hamoshavot 551 Petach Tikva Phone: +972-3-925-1200 552 Israel Email: roni.even@polycom.co.il 553 Requirements for Tightly Coupled SIP Conferencing 555 Petri Koskelainen 556 Dept. of Computer Science 557 Columbia University 558 1214 Amsterdam Avenue, 559 MC 0401 New York, 560 NY 10027 561 USA Email: petkos@cs.columbia.edu 563 Sanjoy Sen 564 Nortel Networks Email: sanjoy@nortelnetworks.com 566 17. References 568 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 569 Levels", BCP 14, RFC 2119, March 1997. 570 2 J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation 571 Protocol", RFC 3261. 572 3 J. Rosenberg, "A Framework for Conferencing with the Session 573 Initiation Protocol", draft-rosenberg-sipping-conferencing- 574 framework-00.txt, Oct 2002, IETF Draft. Work in progress. 575 4 Mahy/Cambell/Johnston/Petrie/Rosenberg/Sparks, "A Multi-party 576 Application Framework for SIP", draft-ietf-sipping-cc-framework- 577 00.txt, Feb 2002, IETF Draft. Work in progress. 578 5 J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) 579 Event Package for Conference State", draft-ietf-sipping- 580 conference-package-00.txt, June 2002, IETF Draft. Work in 581 progress. 582 6 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description 583 Protocol", draft-ietf-mmusic-sdp-new-08.txt, Apr 2002, IETF Draft. 584 Work in progress. 585 7 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in 586 SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work in 587 progress. 588 8 Koskelainen/Schulzrinne, "Requirements for Floor Control", draft- 589 koskelainen-mmusic-floor-req-01.txt, Nov 2002. Work in progress. 590 9 Johnston/Levin, "Session Initiation Protocol Call Control - 591 Conferencing for User Agents,"draft-johnston-sipping-cc- 592 conferencing-00.txt, IETF Draft, Internet Engineering Task Force, 593 Oct. 2002. Work in progress.