O. Levin Internet Draft RADVISION Document: draft-levin-sipping-conferencing- R. Even requirements-00.txt Polycom April 2002 A. Zmolek Expires: October 2002 Avaya D. Petrie Pingtel P. Koskelainen Columbia University Conferencing Requirements for SIP Based Applications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract At present, SIP signaling sessions under a conferencing application must rely on out-of-band signaling for participant information and conference manipulation. This document suggests an integrated approach that defines a Hierarchal Application Signaling Model and allows SIP to support both basic and complex applications based on more basic applications. As example conferencing applications, a general "SIP Star Conferencing Application" and a more specialized "SIP Star Real Time Multimedia Conferencing Application" are defined within this Hierarchical Application Signaling Model. This document identifies requirements for SIP entities that participate or host these applications. A future document will suggest the mapping of the requirements to corresponding protocols and their primitives. O. Levin et al. Expires: October 2002 Page 1 Conferencing Requirements for SIP Based Applications Table of Contents 1. INTRODUCTION.....................................................3 SCOPE................................................................3 HISTORY AND RELATED WORK................................................3 2. TERMINOLOGY......................................................3 3. HIERARCHAL APPLICATION SIGNALING MODEL...........................4 MODEL................................................................4 EXAMPLES..............................................................4 Example 1: Floor Control of Conferences............................4 Example 2: Sub-applications within a SIP Application...............5 Example 3: Remote Device Control Application.......................6 4. SIP STAR CONFERENCING APPLICATION................................7 MODEL................................................................7 REQUIREMENTS..........................................................7 General Design Guidelines..........................................7 Mandatory (Minimal) Participation Requirements for SIP Baseline Participants.......................................................8 Mandatory (Minimal) Participant Requirements.......................8 SIP Star Conferencing Requirements.................................8 5. SIP STAR REAL TIME MULTIMEDIA CONFERENCING APPLICATION...........9 MODEL................................................................9 MEDIA PLANE..........................................................10 Model.............................................................10 Presentation Space................................................10 Media Processor...................................................11 MEDIA CONTROL SUB-APPLICATION...........................................12 General Design Guidelines.........................................12 Conferencing Application Requirements.............................12 Point-to-Point Capabilities Related Requirements..................13 Point-to-Point "Autonomous" Media Control.........................13 Point-to-Point Application Driven Media Control...................14 Roadmap...........................................................15 6. CONVENTIONS USED IN THIS DOCUMENT...............................15 7. SECURITY CONSIDERATIONS.........................................15 8. AUTHOR'S ADDRESSES..............................................15 9. REFERENCES......................................................16 O. Levin et al. Expires: October 2002 Page 2 Conferencing Requirements for SIP Based Applications 1. Introduction Scope This document defines a Hierarchal Application Signaling Model allowing for building integrated applications based on more basic applications. Terminology is also defined in order to describe this model and related application requirements. When coordination of multiple applications is necessary, a Meta Application is needed. This document addresses the notion of building a Meta Application and specific applications using SIP. Nevertheless, the Application Signaling Hierarchal Model doesn't preclude from using applications based on other protocols. Specifically, this document defines a general-purpose "SIP Star Conferencing Application" and a more specific "SIP Star Real Time Multimedia Conferencing Application" as the applications fitting the defined model. This document identifies requirements for SIP entities in order to participate and optionally host these applications in a standard interoperable manner. A future document will provide both the mapping from the requirements to existing protocols' primitives (whenever possible) and suggest directions for required extensions (whenever the desired functionality doesn't exist). Together, both documents would provide a guide for building interoperable SIP Star Real Time Multimedia Conferencing Applications. History and Related Work Editor's Note: Refer to documents [6-10], [16], and [21]. Add text. 2. Terminology Editor's Note: Currently, the definitions, listed below, appear in the body of the document. They will be reproduced here in the next version of the document. Hierarchal Application Signaling Model Application Sub-application Meta Application Meta Database Data Plane SIP Star Conferencing Application SIP Star Real Time Multimedia Conferencing Application Conference Role Center Participant Edge Participant Conference Chair (Moderator) Call/Conferencing Plane Media Plane Media Processor O. Levin et al. Expires: October 2002 Page 3 Conferencing Requirements for SIP Based Applications Presentation Space MCU GW CODEC (CODer DECoder) 3. Hierarchal Application Signaling Model Model This document defines a Hierarchal Application Signaling Model, which has a Meta Application at its root. The Meta Application is a template for building any complex free-style applications that make use of more basic, usually standard, applications. The Application model doesn't preclude the use of non-SIP applications. A Meta Application maintains a Meta Database containing information about associated applications and their respective participants. Participant's Meta information might include, among others, various URI schemes including SIP URL. Each application may contain zero or more Data Planes. Data Plane is an application "product" that spans across the network. For example, the RTP [15] streams, established by a conferencing (signaling) application, define its media Data Plane. Usually, a Data Plane is produced upon a request from an application that is higher in the signaling hierarchy. The Data Plane is created and controlled by the application it belongs to. Each application may contain Sub-applications. Sub-application is a signaling application that is lower to the application in the signaling hierarchy. Sub-application is used by the (higher) application for control of its (that of the higher application) internal Data Base and Data Planes. This model allows for component- based approach, i.e. this allows for implementing of relevant components only, adding more advanced components (such as floor control) at later stage, and replacing existing components. Examples Examples below illustrate the defined Hierarchal Application Signaling Model. The signaling hierarchy and its (sub-) applications are shown by "\" and "---". The Data Planes and the Databases together with their relations to the applications are shown by "====" and "\\". Example 1: Floor Control of Conferences Meta Application ------------------------------------------------ / \ \ \\ / \ \ \\ Voice Conference IM Application Chair Control Meta DB O. Levin et al. Expires: October 2002 Page 4 Conferencing Requirements for SIP Based Applications ---------------- -------------- ------------- ======= / \ \\ / \ \\ Floor Media Audio Control Control Plane ------- ------- ===== This example makes use of a Meta Application with two specific multiparty applications sharing a common group of participants. One application is a centralized SIP voice conference and the other one is a full mesh instant messaging application using some proprietary protocol. The two applications are being established and terminated, with the help of the Meta Application, independently from each other. The Meta Application may add and delete participants of either application in an abstract way. A Chair Control Application is responsible for arbitration of a Conference Chair role. In this example, only the Conference Chair is responsible for adding and deleting conferencing participants "to" and "from" both of the conferences. In this case, the single Chair Control Application is a Sub-application of the Meta application. If a Floor Control, managing groups of media streams or other shared resources within a conference, is required [15], such Floor Control Application would be a Sub-application of the SIP voice conference and as such would be able to reference conferencing internal shared resources. Note that in this application hierarchy, the Voice Conferencing Application SHOULD have means to convey the identity of the Conference Chair from the Meta Application to the Conferencing Floor Control Application. Example 2: Sub-applications within a SIP Application In this example, the Meta Application consists of two specific multiparty applications sharing a common group of participants. One application is a centralized SIP voice and video conferencing and the other is a White Board T.120 based application. T.120 protocol [2] defines a Star topology and conferencing primitives of its own. In this case two possibilities exist. Meta Application ---------------------------- / \ / \ SIP Voice and Video Conference White Board T.120-based ------------------------------ ----------------------- // \ // \ Media Plane Media Control O. Levin et al. Expires: October 2002 Page 5 Conferencing Requirements for SIP Based Applications =========== ------------- In the first case, the Meta Application enables the SIP Conferencing and the White Board applications to be established independently from each other. Therefore, both applications are Sub-applications of the Meta Application. They may have same or different participants. The Meta Application can directly access each of the applications, but needs to be able to reach the participants of either application by separate means. Meta Application ---------------------------- / \ / \ SIP Voice and Video Conference \ ------------------------------ \ // \ \\ \ // \ \\ \ Media Plane Media Control White Board T.120-based =========== ------------- ======================= ----------------------- In the second case, the SIP Conferencing Application is established first. Then, upon the Meta Application request, the T.120 [2] addresses and parameters are signaled to SIP Conferencing participants by the SDP means [12] within the SIP sessions of the SIP conferencing application. In this case, the White Board Application is one of the Data Planes of the SIP conferencing application. White Board participants are a subset of the SIP conference participants. The Meta Application was able to reach the participants by SIP means, and still can access the White Board Application directly. As such, the White Board Application is a Sub- application of the Meta Application. Example 3: Remote Device Control Application An example of remote device control is Far End Camera Control. This is an important feature in video conferencing. This feature enables the remote user to control the remote camera (Zoom and Pan). The feature is used, for example, in medical application when the remote viewer can control the view without having to interrupt the people doing the operation. The requirement is to enable interoperability of the feature between end user videoconferencing equipment from different vendors. Far End Camera Control is a private case of a general Remote Device Control. This kind of applications requires an ability to address the innate SIP/SDP objects (such as media streams). That is in order to associate a specific remote device (such as a camera) with specific media streams. O. Levin et al. Expires: October 2002 Page 6 Conferencing Requirements for SIP Based Applications We believe that the defined Hierarchal Application Signaling Model would help to define Remote Device Control applications in consistent manner. 4. SIP Star Conferencing Application SIP Star Conferencing Applications fit the Hierarchal Application Signaling Model defined above. SIP Star Conferencing Application is an association of SIP User Agents for providing a shared application in a star topology. Each User Agent in a Star Conference has a Conference Role: a Center Participant or an Edge Participant. At a certain point of time, SIP Star Conference has a single Center Participant and zero or more Edge Participants. Effectively, at a certain point of time, the Center Participant hosts the Star Conference. The Center Participant can be either an end user or an application server. The model doesn't preclude from any participant (including an Edge Participant) to have a role of Conference Chair. Editor's Note: Add definitions for Conference Chair (Moderator). Model A Center Participant has direct peer-wise relationships with each of the Edge Participants by means of a SIP dialog. Dialogs may belong to different or same SIP sessions. The Center Participant is a SIP User Agent that maintains correlation among conference's dialogs internally. From SIP Conference perspective, the Center Participant is a conference participant by itself. The SIP Star Conferencing Application MAY have zero or more Data Planes and Sub-applications in order to control or manage them. Requirements General Design Guidelines The goal is to define a tight conference control (in contrast to loose conference control). The goal is to define a framework for both pre-arranged (i.e. scheduled) and spontaneous conferencing modes. Simplicity is an important guideline. Conferencing framework SHOULD balance being powerful enough for most practical scenarios, yet avoid being too complex to be widely accepted and implemented on devices with limited computational resources and user interfaces. Solution SHOULD be mobile-friendly, since mobile low-bandwidth devices represent large portion of user base. Bandwidth consumption on the access link is the most important mobile requirement. It means O. Levin et al. Expires: October 2002 Page 7 Conferencing Requirements for SIP Based Applications that unnecessary (frequent) communication MUST be minimized. Notification frequency SHOULD be configurable by the user. Similarly, incremental modifications MUST be supported. The solution MUST NOT assume IP multicast since it is not widely available in mobile networks or in residential environments (such as PPPoE). Two kinds of operations SHOULD be defined for conference control: commands and informative notifications. Asynchronous commands mode SHOULD be defined. Commands execution may take a long time, especially if human intervention is required. Asynchronous Notifications (i.e. push mode) MUST be defined. Mandatory (Minimal) Participation Requirements for SIP Baseline Participants Each conference participant MUST support SIP baseline specifications [11]. SIP User Agents, that don't support Star Conferencing extensions, SHALL be able to participate in a SIP Star Conference as Edge Participants, although without benefiting from information and functionality that these extensions provide. Specifically, Center Participant SHALL be able to invite and disconnect SIP baseline Edge Participant to and from a SIP Star Conference. Mandatory (Minimal) Participant Requirements Center Participant MUST support SIP conference identification extensions and conventions. SIP Star Conferencing Requirements Conference identification SHALL be standardized. Global Conference Identifier allows for matching existing (active or reserved) conferences. One of the examples for using the Conference Identifier is upon joining a specific conference. The Conference Identifier SHALL be included in each conference-related primitive (such as commands and indications). Editor's Note: Open Issue - Shall the Conference Identifier be routable? Conference description SHOULD be standardized. Conference Description is a way of specifying a desired (but unknown) conference in terms of its capabilities, modes, location, etc. One of the examples for using a Conference Description is upon creating a new conference. Conference Participant SHOULD have means to express the level and the granularity of its support for SIP Star Conferencing extensions. O. Levin et al. Expires: October 2002 Page 8 Conferencing Requirements for SIP Based Applications Center Participant SHALL be able to convey a current Conference Role of each of the participants (i.e. Center Participant vs. Edge Participant) to other participants in the Conference. A procedure for moving a Center Participant role from a current Center to another Participant SHALL be defined. Standard way of implementing following procedures by both Center and Edge participants SHALL be defined: Create/Terminate Conference Invite/Disconnect Edge Participant Invite/Disconnect a list of Edge Participants (Mass-invitation) Each one of the conference participants (i.e. not the Center Participant only) MUST have an ability to be a Conference Chair. Standard means SHALL be defined in order to create a Data Plane of an application (including others then SIP-based) using SIP signaling. One of the examples of such application is the Data Conferencing protocol T.120 [2]. Please, refer to Example 2 of "Hierarchal Application Signaling Model" above. Editor's note: We don't believe that it is enough to have the association with T.120 by means of a Meta Application only. A means SHOULD be defined in order to convey the information listed below to any SIP entity that supports Conferencing extensions and complies with security policies: Conference's Details Participants' Details (Must not assume RTCP.) A Conference Participant SHOULD be able to define the level of the details it wants to receive as conference notifications or announcements (e.g. user may not want to receive informational notifications at all). It MUST be possible to participate anonymously in a conference. It MUST be possible to hide conferencing participants. We envision that additional requirements (such as floor control, conferencing management, etc.) will be grouped according to their subjects and defined as Sub-applications of the SIP Star Conferencing Application. 5. SIP Star Real Time Multimedia Conferencing Application SIP Star Real Time Multimedia Conferencing Application is a private case of the SIP Star Conferencing Application model as defined above. Model O. Levin et al. Expires: October 2002 Page 9 Conferencing Requirements for SIP Based Applications SIP Star Real Time Multimedia Conference is SIP Star Conferencing Application with one or more Media Planes. Media Plane is a private case of Data Plane. Media Plane is a subset of media streams established using SDP [12] (and its extensions) between a Center Participant and Edge Participants in a conference. These media streams flow between a Conference Center and an Edge Participant only. These streams may be unicast or multicast, depending on the SDP information, exchanged within SIP conferencing dialogs. SIP Star Real Time Multimedia Conference MAY have Data Planes that are not Media Planes. SIP Star Real Time Multimedia Conferencing application SHOULD contain Media Control Sub-application(s). Media Plane A Media Plane groups streams belonging to different SIP dialogs for various application reasons. The Media Plane content is an application matter. A certain stream MAY belong to more then a single Media Plane. Examples of Media Planes are a specific Audio Plane and a specific Video Plane. Within an SDP session, SDP extension [13] provides optional means for association among streams (i.e. m-lines) for various application reasons. Consequently, this mechanism MAY provide means for association among Media Planes. Model Media Plane consists of zero or more Media Processors. Media Processor consists of zero or more Presentation Spaces. Both, Presentation Spaces and Media Processors, SHALL be referable to Sub-conferencing applications (such as Media Control and Floor Control). Internal (local) communications between a SIP Star Call/Conferencing Application and its Media Plane are out of scope of this framework. Standard protocols (such as MEGACO [14] and MGCP [17]) and proprietary protocols MAY be used for this purpose. The Media Plane optional components are described below. Presentation Space O. Levin et al. Expires: October 2002 Page 10 Conferencing Requirements for SIP Based Applications Presentation Space is a data model comprised of a set of input (i.e. source) streams, a set of output streams, and processing logic (such as mixing or switching) performed inside the Presentation Space box. This model allows for both pre-defined (well-known) and customized Presentation Spaces. The well-known Presentation Spaces could be defined as follows: Audio Presentation Space An Audio Presentation Space is capable of mixing the incoming audio streams. An Audio Presentation Space is defined by the audio CODECs it supports and the number of sources it can mix in a single stream. Video Presentation Space A Video Presentation Space is capable of mixing one or more video streams. A mix of a single stream is also known as a video switch. A Video Presentation Space is defined by the CODECs it supports, the number of sources it can present in a single picture together with its layout. Customized Presentation Spaces may be pre-defined by an application or being defined by participants with right privileges. Media Processor Media Processor is a logical entity contained within a Media Plane and is responsible for manipulation of the media streams (such as mixing and switching). Media Processor behavior is defined by Presentation Spaces, it contains. A Media Processor may have zero or more Presentation Spaces. In a Star Conference, a Center Participant maintains (zero or more) Media Processors. Usually, streams flowing from Edge Participants are used as inputs to the Media Processor. The outputs of the Media Processor are sent back towards the Edge Participants. This model allows for both pre-defined (well-known) and customized Media Processors. The well-known Media Processors could be defined as follows: Default Audio Media Processor mixes a predefined number (n) of loudest speaking sources (usually n=3) and sends the resulting stream to the rest of the participants. Speakers do not hear themselves. This Media Processor has either n Presentation Spaces or (n+1) Presentation Spaces (if the number of participants is bigger then n). O. Levin et al. Expires: October 2002 Page 11 Conferencing Requirements for SIP Based Applications Default videoconferencing application has the audio of the default audio conferencing application. Default Video Media Processor sends the video of the loudest speaker (also known as an active speaker) is sent to all the participants. The active speaker sees the previous speaker. This Media Processor has two Video Presentation Spaces, each one performing a switching of a single video stream. Media Control Sub-application In a star topology, many of the Media Control requirements are achieved by exchanging of messages on point-to-point basis between a Center Participant and Edge Participants. Conferencing requirements, presented below in this section, refer to the multi-participant nature of the conferencing application. Point-to-point requirements, presented below in this section, are not unique for a conferencing application. Nevertheless, because the conferencing application is complex and involves User Agents with potentially different characteristics, their fulfillment is REQUIRED for enabling the multimedia conferencing application. The point-to-point requirements are equally applicable to all conference participants, including Edge Participants, and they are included here for completeness of the model. General Design Guidelines The defined model SHALL enable same architecture and same user experience for both audio only and multimedia conferencing. The defined model SHALL enable adding and removing Media Planes during a conference. Application driven requirements SHALL use reliable transport mechanism. Conferencing Application Requirements Standard way of conveying the following indications SHOULD be defined: Participant is presented to at least one other participant Participant is presented to all other participants Identification of a participant that is presented to you now Standard way of issuing the following presentation requests towards a Center Participant SHOULD be defined: Broadcast specific session (my or somebody's else) O. Levin et al. Expires: October 2002 Page 12 Conferencing Requirements for SIP Based Applications I am interested in a group of selected media streams only Point-to-Point Capabilities Related Requirements Default Capabilities' Profiles We expect that SIP Conferencing will be deployed in a broad variety of networks (with different characteristics and requirements). Therefore, in order to achieve basic CODEC interoperability, instead of defining the lowest common denominator for all networks, the framework SHOULD define a number of profiles. For example, a Basic LAN Profile could define G.711 for audio and H.261 [4] QCIF for video. Capabilities' Exchange A User Agent (such as a terminal, a gateway, or an MCU) can support one or more media streams and therefore MUST have means to specify alternate and simultaneous capabilities. A User Agent SHOULD have means to explicitly request symmetric CODECs in the send and receive path. This is important for gateways and MCUs that may need to work symmetrically on the legs (i.e. dialogs) of a session or a conference. An example is a gateway from SIP to H.320 [3]. These calls need symmetric CODECs on the switched network side. Video capabilities MUST include the following parameters: Algorithm (such as H.261, H.263, and MPEG) Maximum Bandwidth Supported Maximum Resolution Supported (QCIF, CIF, 4CIF, and custom formats) Maximum Video Frame Rate Point-to-Point "Autonomous" Media Control This includes indications exchanged between CODECs as a result of CODEC algorithms. In most cases it is performed independently from the call and conferencing applications. Applications involving video are particularly prone to frequent network changes causing packets lost, error conditions, etc. The video information includes full picture frames and frames that reflect changes from previous frames. Losing IP packets causes synchronization problem for the decoder. Various video specific techniques have been used in today's networks in order to cope with fluctuating conditions with minimum service degradation. The following indications SHOULD be supported: Video MB Not Decoded Indication O. Levin et al. Expires: October 2002 Page 13 Conferencing Requirements for SIP Based Applications This indication is used to inform the encoder not to use specific macro blocks for prediction. Lost Picture and Lost Partial Picture Indication These indications are used to inform the encoder that it should use an error resilience technique to solve the problem. Point-to-Point Application Driven Media Control Requesting a change of media stream and/or bandwidth during the session is typical for multiparty conferencing and gateway applications when there is a need to change CODECs and/or their parameters during the session. Additionally, changing of video stream bandwidth is used in order to adapt to a congestion situation by reducing the video rate. At the start of the session, it is REQUIRED to have an ability to specify the maximum (i.e. reserved) and the exact bandwidth to be used by the session. It is REQUIRED to have an ability to change the used bandwidth during the session. A Request mechanism is REQUIRED to ask a sender to send a stream with specified parameters. The parameters include algorithm, resolution, frame rate and specific CODEC algorithm parameters such as interlace picture for H.263 [5]. Video applications MUST have a clean deterministic method to switch between video sources. This requirement is crucial for any basic videoconferencing in order to achieve good user experience. Otherwise, when a decoder suddenly loses synchronization with the old video stream, a bad picture is presented to the user till complete synchronization with the new stream is achieved. In order to achieve this, the REQUIRED primitives are presented below: Video Full Picture Fast Update Request Video Update Slice Request These commands are to be sent from a decoder to an encoder. Video CODECs (such as H.261 [4] and H.263 [5]) have a notion of picture's building blocks: "full picture", and "slice". The decoder has an ability to recognize synchronization problem and MUST have an ability to explicitly request from an encoder for a "full picture", or a specific "slice" of the picture. In addition, when the application needs to start presenting a new video source, it MUST have ability to explicitly request from an encoder for a "full picture". Video Freeze Picture Request O. Levin et al. Expires: October 2002 Page 14 Conferencing Requirements for SIP Based Applications This command is to be sent from an encoder to a decoder. In case the encoder is aware of a change in the transmitted picture that would cause lost of synchronization, it MUST be able to request the decoding side to freeze the picture, i.e. to stop presenting the changes, until a new stable image is encoded and transmitted. Roadmap The requirements, presented above, may be partly achieved today by SDP [12] and [22] together with its extensions, and RTCP [15] together with its extensions. We envision that the Capabilities Related Requirements MAY be achieved using SDP with the help of [18] and [20]. We envision that the Point-to-Point "Autonomous" Media Control Requirements MAY be achieved using RTCP with the help of its extensions such as [19]. In order to achieve interoperable SIP implementations, each of the requirements MUST be mapped into a protocol primitive and a corresponding standard procedure. A future document will provide both the mapping from the requirements to existing protocols' primitives (whenever possible) and suggest directions for required extensions (whenever the desired functionality doesn't exist). Together, both documents would provide a guide for building interoperable SIP Star Real Time Multimedia Conferencing Applications. At this point of time, it is an Open Issue how the Conferencing Application Requirements are to be implemented by SIP multimedia applications. At this point of time, it is an Open Issue how the Application Driven Media Control Requirements are to be implemented by SIP multimedia applications. These requirements are a showstopper for implementation of video conferencing applications using SIP. 6. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 7. Security Considerations Security requirements will be addressed in the next version of this document. 8. Author's Addresses O. Levin et al. Expires: October 2002 Page 15 Conferencing Requirements for SIP Based Applications Orit Levin RADVISION Inc. 575 Corporate Drive Mahwah, NJ 07430 Phone: +1-201-529-4300x230 USA Email: orit@radvision.com Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva Phone: +972-3-925-1200 Israel Email: roni.even@polycom.co.il Andy Zmolek Avaya 8740 Lucent Blvd. 403E273 Highlands Ranch, CO 80129 Phone: +1-720-444-4001 USA Email: zmolek@avaya.com Daniel G. Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 Phone: +1 781 938 5306 USA Email: dpetrie@pingtel.com Petri Koskelainen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 Phone: USA Email: petkos@cs.columbia.edu 9. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 ITU-T Recommendation T.120 (1996), "Data protocols for multimedia conferencing". 3 ITU-T Recommendation H.320 (1997), "Narrow-band visual telephone systems and terminal equipment". O. Levin et al. Expires: October 2002 Page 16 Conferencing Requirements for SIP Based Applications 4 ITU-T Recommendation H.261 (1993), "Video codec for audiovisual services at p x 64 kbit/s". 5 ITU-T Recommendation H.263 (1998), "Video coding for low bit rate communication". 6 J. Rosenberg, H. Schulzrinne, "Models for Multi Party Conferencing in SIP", draft-ietf-sipping-conferencing-models- 00.txt, Nov 2001, IETF Draft. Work in progress. 7 H. Khartabil, "Conferencing using SIP", draft-khartabil-sip- conferencing-00.txt, Sep 2001, IETF Draft. Work in progress. 8 R. Mahy, D. Petrie, "The SIP Join and Fork Headers", draft-mahy- sipping-join-and-fork-00.txt, Nov 2001, IETF Draft. Work in progress. 9 I. Miladinovic, J. Stadler, "SIP Extension for Multiparty Conferencing", draft-miladinovic-sip-multiparty-ext-00.txt, Feb 2002, IETF Draft. Work in progress. 10 Wu/Koskelainen/Schulzrinne/Chen, "Use SIP and SOAP for conference floor control", draft-wu-sipping-floor-control-01.txt, Apr 2002,IETF Draft. Work in progress. 11 J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09.txt, Feb 2002, IETF Draft. Work in progress. 12 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-08.txt, Apr 2002, IETF Draft. Work in progress. 13 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work in progress. 14 Cuervo/Greene/Rayhan/Huitema/Rosen/Segers, "Megaco Protocol Version 1.0", RFC 3015, Proposed Standard, Nov 2000. 15 AVT WG, Schulzrinne/Casner/Frederick/Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, Proposed Standard, Jan 1996. 16 P. Koskelainen, H. Schulzrinne, and X. Wu, "A SIP-based Conference Control Framework", The 12nd International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Miami Beach, Florida), May 2002. 17 M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705 Informational, Oct 1999. 18 F. Andreasen, "SDP Simple Capability Declaration", draft- andreasen-mmusic-sdp-simcap-05.txt, Feb 2002, IETF Draft. Work in progress. 19 J. Ott et al., "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", draft-ietf-avt-rtcp-feedback-02.txt, Mar 2002, IETF Draft. Work in progress. O. Levin et al. Expires: October 2002 Page 17 Conferencing Requirements for SIP Based Applications 20 S. Casner, P. Hoschka,"MIME Type Registration of RTP Payload Formats", draft-ietf-avt-rtp-mime-06.txt, Nov 2001, IETF Draft. Work in progress. 21 C. Bormann, D. Kutscher, J. Ott, and D. Trossen, "Simple conference control protocol service specification", Mar 2001, IETF Draft. Work in progress. 22 J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP", draft-ietf-mmusic-sdp-offer-answer-02.txt, Feb 2002, IETF Draft. Work in progress. O. Levin et al. Expires: October 2002 Page 18