idnits 2.17.1 draft-levin-sipping-conferencing-requirements-01.txt: 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-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 3) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 370 looks like a reference -- Missing reference section? '3' on line 256 looks like a reference -- Missing reference section? '8' on line 519 looks like a reference -- Missing reference section? '9' on line 520 looks like a reference -- Missing reference section? '10' on line 520 looks like a reference -- Missing reference section? '11' on line 520 looks like a reference -- Missing reference section? '12' on line 520 looks like a reference -- Missing reference section? '6' on line 548 looks like a reference -- Missing reference section? '7' on line 548 looks like a reference -- Missing reference section? '1' on line 631 looks like a reference Summary: 4 errors (**), 1 flaw (~~), 5 warnings (==), 11 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- A. Zmolek/Avaya 5 requirements-01.txt D. Petrie/Pingtel 6 July 2002 P. Koskelainen/Columbia U. 7 Expires: January 2003 S. Sen/Nortel 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. GENERAL DESIGN GUIDELINES........................................4 52 4. DISCOVERY PHASE REQUIREMENTS.....................................4 53 SIP ENTITY CONFERENCING CAPABILITIES DISCOVERY......................4 54 A PARTICULAR CONFERENCE LOCATION AND INFORMATION DISCOVERY..........5 55 5. BASIC CONFERENCING REQUIREMENTS..................................5 56 PARTICIPATION OF RFC 3261 COMPLIANT ONLY USER AGENT.................5 57 CONFERENCE ESTABLISHMENT IN DIAL-OUT SCENARIOS (AS PER [3]).........5 58 CONFERENCE ESTABLISHMENT IN DIAL-IN SCENARIOS (AS PER [3])..........6 59 THIRD PARTY INVITATION TO A CONFERENCE..............................6 60 DISCONNECTION OF CONFERENCE MEMBERS AND CONFERENCE TERMINATION......6 61 CONFERENCE MEMBER PRIVACY...........................................7 62 6. CONFERENCE STATE DISSEMINATION REQUIREMENTS......................7 63 REPORT OF CHANGES...................................................7 64 ON-DEMAND DISSEMINATION.............................................8 65 7. MISCELLANEOUS REQUIREMENTS.......................................8 67 8. MEDIA CONTROL REQUIREMENTS.......................................9 69 9. CONFERENCE ACCESS CONTROL LIST (ACL).............................9 71 10. CONFERENCE PARTICIPANT PRIVILEGES..............................10 72 MODEL..............................................................10 73 REQUIREMENTS.......................................................10 74 11. FLOOR CONTROL..................................................10 75 DEFINITIONS........................................................10 76 REQUIREMENTS.......................................................11 77 12. REQUIREMENTS BEYOND MANAGEMENT OF A SINGLE CONFERENCE..........12 79 13. CONVENTIONS USED IN THIS DOCUMENT..............................13 81 14. SECURITY CONSIDERATIONS........................................13 83 15. AUTHOR'S ADDRESSES.............................................13 85 16. REFERENCES.....................................................14 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 host), which has a 108 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 In this framework, the SIP conference graph is always a star. The 112 conference host maintains the correlation among conference's dialogs 113 internally. 115 The conference state is defined by a set of information describing 116 the conference in progress. This MAY include the following: all or 117 some participant information such as dialog-ids, media sessions in 118 progress, etc. A complete conference state definition can be found 119 in [5]. 121 The conference can be hosted either by a participating entity (e.g. 122 terminal) or by a separate application server. 124 Typically to the first case, a terminal is capable of hosing a 125 limited ad hoc conference. Such conference is established using 126 basic conferencing primitives. 128 Editor's Note: This is similar to traditional offering from PSTN 129 service providers in audio conferencing such as being able to join 130 independent calls into a multiparty conference. 132 Application server offers more robust options including reservation, 133 large conferences, and managed conferences. In addition to the basic 134 functionality, the conferencing server supports any subset of 135 advanced conferencing features, presented in this document. In this 136 case, the conference has a globally routable identifier, such as SIP 137 URI. 139 Requirements for Tightly Coupled SIP Conferencing 141 The conference properties are defined by a list of configuration 142 parameters (e.g., maximum number of ports/participants, needs chair- 143 person supervision or not, password protected or not, duration, 144 etc.) that a conference creator can request from the conference 145 service. Conference properties are configured at the onset of a 146 conference and, typically, need special privileges to be changed. 148 Conference participants MAY have different roles or privileges in a 149 conference. For example, a conference Chair MAY have the right to 150 disconnect users from a conference, or terminate the conference. 152 SIP conference MAY have media sessions similarly to standard two- 153 party SIP calls. The conference media graph is constructed 154 independently from the SIP star conference. For example, it can be 155 centralized (e.g. following the star graph of the SIP conference) or 156 it can be de-centralized (such as multicast mesh among the 157 participating entities). As it can be seen from the examples, the 158 function of the media processing can be performed either by the 159 conference host alone or by each one of the participating entities. 161 3. General Design Guidelines 163 GDG-1: Keep It Simple. 165 GDG-2: Low Bandwidth Consumption. 166 Mobile low-bandwidth devices represent large portion of user base. 167 Bandwidth consumption on the access link is the most important mobile 168 requirement. 170 GDG-3: MUST NOT assume IP Multicast. 171 The solution MUST NOT assume IP multicast since it is not widely 172 available in mobile networks or in residential environments (such as 173 PPPoE). 175 GDG-4: The design MUST allow for scalable architecture in order to 176 support large (but still tightly managed) conferences. 178 GDG-5: Since the request processing may take long time at the 179 server, the response mechanism SHOULD be asynchronous. 181 Editor's note: For example, if a conference creation includes long 182 list of dial-out participants, it may take a long time to have the 183 final response to the request. 185 4. Discovery Phase Requirements 187 SIP Entity Conferencing Capabilities Discovery 189 Requirements for Tightly Coupled SIP Conferencing 191 Editor's Note: The following requirements can always be achieved by 192 configuration means or/and human agreement. Nevertheless, we feel 193 that automatic means MUST be defined. 195 CAPD-1: A standard means MUST be defined for automatic discovery of 196 location of conferencing application server(s). 198 CAPD-2: A standard format for expressing UA's conferencing 199 capabilities MUST be defined. Each SIP entity MUST be able to 200 independently express its capabilities as a conference member only 201 and as a conference host. 203 CAPD-3: A standard means MUST be defined for retrieving conferencing 204 capabilities of a known SIP entity. In this regard, the SIP entity 205 can be either a user device (e.g. a terminal) or a dedicated 206 conferencing server. 208 A Particular Conference Location and Information Discovery 210 CNFD-1: Given a global identifier of a particular conference, a 211 standard means MUST be defined for locating the hosting entity of 212 this conference. 214 CNFD-2: Given a global identifier of a particular conference, a 215 standard means MUST be defined for obtaining the conference 216 properties. 218 CNFD-3: Given a global identifier of a particular conference, a 219 standard means MUST be defined for obtaining the conference state 220 information. 222 5. Basic Conferencing Requirements 224 Participation of RFC 3261 compliant only User Agent 226 BSC-1: A conference host MUST be able to invite and disconnect an 227 RFC 3261 compliant only SIP UA to and from a SIP conference. 229 BSC-2: RFC 3261 compliant only SIP UA's MUST be able to dial-in a 230 particular SIP conference (as per [3]). In this case, only the user 231 behind its UA knows that he dials into the conference. 233 Editor's Note: In this case, the conference can be identified either 234 by manually populating the Request-URI field with the conference 235 identifier or, alternatively, by using an IVR service. 237 Conference Establishment in Dial-Out Scenarios (as per [3]) 239 DOUT-1: A means MUST be defined for a conference host to invite a 240 User Agent to one of its active conferences (specified by a 242 Requirements for Tightly Coupled SIP Conferencing 244 conference identifier) over an existing SIP dialog between the two. 245 As a result, the dialog becomes a part of the conference. 247 DOUT -2: A means MUST be defined for a conference host to invite a 248 User Agent by establishing a new SIP dialog between the two together 249 with specifying the identifier of the conference. The dialog belongs 250 to the conference. 252 Conference Establishment in Dial-In Scenarios (as per [3]) 254 DIN-1: Provided desired conference properties and the hosting entity 255 location (as per DS-1 and DS-2), a means MUST be defined for a UA to 256 create an ad-hoc conference [3] and to become its member. A means 257 MUST be defined for creating a global conference identifier for this 258 ad-hoc scenario. 260 DIN-2: Provided a reserved conference identifier, a means MUST be 261 defined for a UA to activate the conference and to become its 262 member. 264 DIN-3: Provided a reserved conference identifier, a means MUST be 265 defined for a UA to dial-in an active conference and to become its 266 member. 268 DIN-4: Provided one of the dialogs ID, belonging to a particular 269 active conference, a means MUST be defined for a UA to dial-in an 270 active conference and to become its member. 272 Third Party Invitation to a Conference 274 THIP-1: Provided a conference identifier, a means MUST be defined 275 for a UA to invite another UA to this conference. 277 THIP-2: Provided one of the dialogs ID, belonging to a particular 278 active conference, a means MUST be defined for a UA to invite 279 another UA to this conference. 281 THIP-3: Provided a conference identifier, a means MAY be defined for 282 a UA to invite a list of UAs to this conference (a so-called "mass 283 invitation"). 285 Disconnection of Conference Members and Conference Termination 287 TERM-1: A means MUST be defined for a conference host to disconnect 288 a conference member from an active conference. 290 TERM-2: A means MAY be defined for a conference host to revert a 291 two-party conference to a basic SIP point-to-point session (and 292 releasing internal conferencing resources). 294 Requirements for Tightly Coupled SIP Conferencing 296 TERM-3: Provided a conference identifier, a means MUST be defined 297 for a UA to disconnect another UA from this conference. 299 TERM-4: Provided one of the dialogs ID, belonging to a particular 300 active conference, a means MAY be defined for a UA to disconnect 301 another UA from this conference. 303 TERM-5: Provided a conference identifier, a means MAY be defined for 304 a UA to disconnect a list of UAs from this conference (a so-called 305 "mass feature"). 307 TERM-6: Provided a conference identifier, a means MUST be defined 308 for a UA to disconnect all members from this conference. 310 TERM-7: Provided a conference identifier, a means MAY be defined for 311 a UA to terminate this conference by disconnection all the members, 312 releasing conference resources together with the conference 313 identifier. 315 Editor's note: Some of the requirements above overlap with each 316 other. 318 Conference Member Privacy 320 The following features depend both on host's capabilities and 321 policies and on members' capabilities. 323 A conference host SHOULD support these. A conference member MAY 324 support these. 326 PRV-1: A conference member participates in a conference 327 "anonymously", meaning that its presence is known and can be 328 announced but without disclosing its identity. 330 PRV-2: A conference member requests anonymous participation from the 331 host. 333 PRV-3: A conference member participates in a conference "in a hidden 334 mode", meaning that both its presence and its identity are not 335 disclosed. 337 PRV-4: A conference member requests participation in a hidden mode. 339 6. Conference State Dissemination Requirements 341 Report of Changes 343 CNG-1: It is expected that the set of events related a conference 344 state and required to be reported would grow with time. Therefore, a 345 mechanism for extensible definition/registration of new conference 346 state changes MUST be defined. 348 Requirements for Tightly Coupled SIP Conferencing 350 CNG-2: A means MUST be defined for reporting the conference state 351 changes to interested parties (including conference members) in a 352 timely manner. The report MAY include more than one change. 354 CNG-3: A means MUST be defined for a SIP UA to express its interest 355 in selected state changes only. 357 CNG-4: A means MUST be defined for a SIP UA to express the minimum 358 interval between receiving state change reports. 360 A means MUST be defined for reporting at least the following changes 361 in a conference state: 363 CNG-5: A new conference member joined the conference. 365 CNG-6: A Particular conference member left the conference. 367 On-demand Dissemination 369 ODD-1: A means MUST be defined to disseminate any conference state 370 information (as per [5]) to interested parties (i.e. SIP UAs) on- 371 demand. 373 ODD-2: A means MUST be defined for a SIP UA to request a conference 374 state information of a particular conference defined by the 375 conference identifier. 377 ODD-3: A means MUST be defined for a SIP UA to specify the subset of 378 the conference state information, it wants and capable to receive. 380 7. Miscellaneous Requirements 382 MISC-1: A procedure for delegating of a host role by the current 383 host to another member MUST be defined. 385 MISC-2: A procedure for requesting a conference host to transfer its 386 role to another conference member MUST be defined. 388 MISC-3: A procedure for on-demand unconditional transfer of the host 389 role to a different member MUST be defined. 391 MISC-4: A detection procedure for a conference host failure 392 condition MUST be defined. 394 MISC-5: In case a conference host failure, a procedure for assigning 395 a new conference host MUST be defined. 397 Editor's Note: This is a difficult for standardization requirement. 399 Requirements for Tightly Coupled SIP Conferencing 401 8. Media Control Requirements 403 This section is left for future study. 404 To this point, the listed below requirements have been identified: 406 MEDI-1: Each media session between the conference Server and a 407 participant in a conference MUST have a unique identity in the 408 conference space 410 MEDI-2: It MUST be possible for a user to participate in a sub-set 411 of media sessions of a conference 413 MEDI-3: It MUST be possible to modify media sessions of certain 414 subset of the participants without impacting the sessions of other 415 participants (e.g., introduce side-bar conversations between two 416 participants). 418 MEDI-4: It MUST be possible to modify a subset of the media sessions 419 of a participant during the conference (e.g., swap in and out 420 video). 422 MEDI-5: A media session of a participant MUST be in one of the 423 following states: 424 - Inactive : SDP attribute=inactive 425 - Active : opposite of inactive 426 - On-hold : SDP attribute=sendonly 427 - Disabled : media port = 0 429 MEDI-6: It MUST be possible for the conference server to mix a sub- 430 set of the active media sessions in a conference (e.g., mix audio 431 from two most audible speakers). 433 MEDI-7: It SHOULD be possible for a participant with appropriate 434 privileges to add (and delete) conference-wide media sessions into 435 (from) the conference, or modify their properties. 437 9. Conference Access Control List (ACL) 439 The purpose of the Access Control List is to define who is allowed 440 (or not allowed) to join the conference. If there is user's join 441 attempt, but user is not in the ACL then (depending on the 442 conference policy), the conference chair MAY be consulted whether 443 the user can be accepted to join the conference. 445 ACL-1: There MUST be a mechanism to define Access Control List (ACL) 446 so that user's joins can be pre-authorized (or denied). 448 ACL-2: It MUST be possible to add and delete users to/from ACL. 450 Requirements for Tightly Coupled SIP Conferencing 452 ACL-3: It MUST be possible to consult a user with appropriate 453 privileges (such as chair) when an unknown user tries to join the 454 conference. The chair may accept or deny the join attempt. 456 10. Conference Participant Privileges 458 Model 460 Conference participants MAY have different privileges. 462 In the simplest case, only two kinds of participants exist: the 463 conference Chair (with all the privileges), and normal Participants 464 (without any privileges). 466 For example, following privileges MAY be supported: 467 - Right to terminate a conference 468 - Right to disconnect participants 469 - Right to manage general conference properties 470 - Right to manage conference access control list (ACL) 471 - Right to manage conference-wide media sessions (e.g. add audio 472 session into conference) 473 - Right to manage other participant's session parameters (such as 474 media) 475 - Right to make real-time authorization (for join attempts) 476 - Right to hand-off all (or some of) the above privileges to 477 another participant 479 Some conferences may utilize more complex privilege definition and 480 hierarchy; such as guru-participants have the right to disconnect 481 participants. 483 Therefore, protocol mechanisms MUST be in place to translate these 484 rights into actions. 486 Requirements 488 PRIV-1: It MUST be possible to define different privileges to 489 different participants. 491 PRIV-2: It MAY be possible that different participant levels are 492 defined (e.g. senior-member, panelist). 494 PRIV-3: Rules MUST be defined for special cases, such as if chair 495 leaves suddenly, or chair tries to take privileges away from all 496 privilege holders. 498 11. Floor Control 500 Definitions 502 Requirements for Tightly Coupled SIP Conferencing 504 Conference applications often have shared resources such as the 505 right to talk, input access to a limited-bandwidth video channel, or 506 a pointer or input focus in a shared application. 508 In many cases, it is desirable to be able to control who can provide 509 input (send/write/control, depending on the application) to the 510 shared resource. 512 Floor control enables applications or users to gain safe and 513 mutually exclusive or non-exclusive input access to the shared 514 object or resource. 516 This is an optional feature for conferencing applications. SIP 517 conferencing applications may decide not to implement this feature. 519 Floor control has been studied extensively over the years (e.g. [8], 520 [9], [10], [11], and [12]) therefore earlier work can be utilized 521 here. 523 A floor control protocol is used to convey the floor control 524 messages among the floor chairs (moderators) of the conference, the 525 conference server and the participants of the conference. 527 The centralized conference server controls the floors at least in 528 the signaling level. Controlling also the actual (physical) media 529 resources (e.g. audio mixer) is highly recommended, but beyond the 530 scope of this document. 532 Note that the floor is a concept coupled with one or more media 533 sessions. 534 The creation of the media session itself is defined elsewhere. 535 A participant with appropriate privileges may create a floor by 536 defining that existing media session(s) is now floor-controlled. 538 Requirements 540 FLO-1: It MUST be possible to announce that one or more conference's 541 media sessions are floor-controlled. This means that, unless 542 otherwise defined, all floor participants are in passive receive- 543 only mode. It MUST also be possible to group more than one media 544 sessions together so that one floor applies to the group of media 545 sessions. 547 Editor's note: This announcement can be done e.g. via SDP "fid" 548 extensions ([6] and [7]). 550 FLO-2: It MUST be possible to define who is allowed to create a 551 floor in a conference. 553 Editor's note: This may be a conference chair, or a participant 554 authorized by conference chair. 556 Requirements for Tightly Coupled SIP Conferencing 558 FLO-3: It MUST be possible for a participant with appropriate 559 privileges to create a floor with specific parameters, such as how 560 many simultaneous users are allowed. Similarly, floor modification 561 and termination MUST be supported. 563 Example of this is that chair creates a floor (for existing audio 564 session) and defines that max two users are allowed to hold the 565 floor at the same time. The server can then take care of this. 567 FLO-4: It MUST be possible to use moderator-controlled floor policy 568 in which the server notifies the floor moderator and waits for the 569 moderator to make decisions. This enables the moderator to fully 570 control who has the floor. The server MAY forward all requests 571 immediately to moderator, or it may do filtering and send only 572 occasional notifications to moderator. 574 FLO-5: It MAY be possible that several users are acting as floor 575 moderators. The centralized server may send floor request 576 notifications either sequentially, or at the same time. 578 FLO-6: The moderator actions (e.g. floor grant) MUST be atomic and 579 the server MUST cope with "simultaneous write" problem in which many 580 moderators try to make conflicting decisions at the same time. 582 FLO-7: Participants MUST be able to request (claim) a floor. 584 FLO-8: It MUST be possible (for a floor holder) to release a floor. 586 FLO-9: It MUST be possible (for a server or participant with 587 appropriate privileges) to revoke a floor from its current holder. 589 FLO-10: It MUST be possible to grant a floor to a participant. 591 Floor control related parameters are defined when the controlled 592 floor is created, or modified. 594 FLO-11: It MUST be possible to manipulate at least the following 595 floor parameters: 597 - Floor control chair (this does not have to be the conference 598 chair) 599 - Floor control policy (such as moderator-controlled, FCFS, Random) 600 - Number of simultaneous floor holders 602 FLO-12: it MAY be possible to manipulate additional parameters, such 603 as time limits. 605 12. Requirements Beyond Management of a Single Conference 607 Requirements for Tightly Coupled SIP Conferencing 609 This section is left for future study. 610 To this point, the listed below requirements have been identified: 612 MET-1: It SHOULD be possible to merge two existing conferences to 613 form a single conference. 615 MET-2: It SHOULD be possible to split an active conference into two 616 or more conferences. 618 MET-3: It SHOULD be possible to daisy-chain multiple ongoing 619 conferences. 621 Editor's Note: In general, conferencing split and merge operations 622 are extremely difficult. We may consider achieving this 623 functionality by transferring individual participants to other 624 conference using simple SIP means. 626 13. Conventions used in this document 628 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 629 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 630 this document are to be interpreted as described in RFC-2119 [1]. 632 14. Security Considerations 633 Security requirements will be addressed in the next version of this 634 document. 636 15. Author's Addresses 638 Orit Levin 639 RADVISION Inc. 640 266 Harristown Road, 641 Suite 201, 642 Glen Rock, NJ 07452 Phone: +1-201-689-6330 643 USA Email: orit@radvision.com 645 Roni Even 646 Polycom 647 94 Derech Em Hamoshavot 648 Petach Tikva Phone: +972-3-925-1200 649 Israel Email: roni.even@polycom.co.il 651 Andy Zmolek 652 Avaya 653 8740 Lucent Blvd. 403E273 654 Highlands Ranch, CO 80129 Phone: +1-720-444-4001 655 USA Email: zmolek@avaya.com 657 Requirements for Tightly Coupled SIP Conferencing 659 Daniel G. Petrie 660 Pingtel Corp. 661 400 W. Cummings Park 662 Suite 2200 663 Woburn, MA 01801 Phone: +1 781 938 5306 664 USA Email: dpetrie@pingtel.com 666 Petri Koskelainen 667 Dept. of Computer Science 668 Columbia University 669 1214 Amsterdam Avenue, 670 MC 0401 New York, 671 NY 10027 672 USA Email: petkos@cs.columbia.edu 674 Sanjoy Sen 675 Nortel Networks Email: sanjoy@nortelnetworks.com 677 16. References 679 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 680 Levels", BCP 14, RFC 2119, March 1997. 681 2 J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation 682 Protocol", RFC 3261. 683 3 J. Rosenberg, H. Schulzrinne, "Models for Multi Party 684 Conferencing in SIP", draft-ietf-sipping-conferencing-models- 685 00.txt, Nov 2001, IETF Draft. Work in progress. 686 4 Mahy/Cambell/Johnston/Petrie/Rosenberg/Sparks, "A Multi-party 687 Application Framework for SIP", draft-ietf-sipping-cc-framework- 688 00.txt, Feb 2002, IETF Draft. Work in progress. 689 5 J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) 690 Event Package for Conference State", draft-ietf-sipping- 691 conference-package-00.txt, June 2002, IETF Draft. Work in 692 progress. 693 6 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description 694 Protocol", draft-ietf-mmusic-sdp-new-08.txt, Apr 2002, IETF Draft. 695 Work in progress. 696 7 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in 697 SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work in 698 progress. 699 8 Dommel, H-P. and Garcia-Luna-Aceves, J., "Floor control for 700 activity coordination in networked multimedia applications." In 701 Proc. of 2nd Asian-Pacic Conference on Communications (APCC) 702 (Osaka, Japan, June 1995). 704 Requirements for Tightly Coupled SIP Conferencing 706 9 Dommel, H-P. and Garcia-Luna-Aceves J., "Efficacy of Floor Control 707 Protocols in Distributed Multimedia Collaboration," Cluster 708 Computing Journal, Special issue on Multimedia Collaborative 709 Environments, Vol. 2, No.1, 1999. 710 10 Bormann, C., Kutscher, D., Ott, J., and Trossen, D. "Simple 711 conference control protocol service specifation." Mar. 2001, IETF 712 Draft,. Work in progress. 713 11 Koskelainen, P., Schulzrinne H., and Wu, X. "A SIP-based 714 Conference Control Framework," in Proc. International Workshop on 715 Network and Operating System Support for Digital Audio and Video 716 (NOSSDAV), (Miami Beach, Florida), May 2002. 717 12 Wu/Koskelainen/Schulzrinne/Chen, "Use SIP and SOAP for conference 718 floor control", draft-wu-sipping-floor-control-01.txt, Apr 719 2002,IETF Draft. Work in progress.