[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
                                                               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