SIP and SIPPING WGsMay, 6-7 2002 IETF Interim Meeting Orit levin orit@radvision.com Conferencing...

transcript

May, 6-7 2002 IETF Interim MeetingSIP and SIPPING WGs

Orit levin

orit@radvision.com

Conferencing Requirements for SIP Based Applications

draft-levin-sipping-conferencing-requirements-00.txt

Levin/Even/Zmolek/Petrie/Koskelainen

RADVISION/Polycom/Avaya/Pingtel/Columbia University

The Outline of the Draft

•Hierarchal Application (Signaling) Model

•SIP Star Conferencing Application

•SIP Star Real Time Multimedia Conferencing Application

Reasons for Hierarchal Application Model

•A Means to Describe the Reality

•A Basis for Terminology Definition

•A Means to Understand Each Other’s Requirements

•A Means to Describe and Classify the Requirements

Meta Application Objectives

•Everything that is out of scope of standard applications

–Different Sets of Participants

•Everything that is out of scope of SIP Conferencing Application

–Bridging to PSTN End Users

Applications’ Reality

Example of a Complete Application

•Members’ Management

•Applications’ Coordination

Real Time(Voice and Video)Star ConferencingApplication

Instant MessagingFull MeshApplication

White BoardT.120 BasedApplication

Chair ControlApplicationin the Roadmap

PresenceSIMPLE BasedApplication

The Hierarchal Application ModelExample 2

Meta Application

SIP VoiceConferencingApplication

Media ControlVoice (Data) Plane

The Hierarchal Application ModelExample 2

Meta Application

SIP VoiceConferencingApplication

Media ControlVoice (Data) Plane

SIP Star Conferencing Application Model

•An Association of SIP User Agents for providing a shared application in Star Topology

•Center Participant vs. Edge Participants

•A Center Participant has a SIP Dialog with each one of Edge Participants and internally maintains correlation among the dialogs

•Both Center and Edge Participants are capable of being a Conference Chair

SIP Star Conferencing Application

SIP Star Conference

CENTER

SIP Dialog

EDGESIP Dialog

SIP Dialog

SIP Star Conferencing ApplicationMain Requirements’ Guidelines

•Tight Conference Control (in contrast to loose)

•Pre-arranged and Spontaneous Conferencing Support

•Center Participant SHALL be able to add and disconnect SIP baseline Participants

SIP Star RT MultimediaConferencing Application Model

•SIP Star Conferencing Application with one or more RT Media (Data) Planes

•RT Media Plane is a subset of RTP media streams established by SDP means

•SHOULD contain Media Control Sub-application(s)

•May have Data Planes that are not RT Media Planes

SIP Star Real Time MultimediaReal Time Multimedia Conferencing ApplicationSIP Star Conference

CENTER

RTP/RTCP

SIP Dialog

RTP/RTCP

SIP Dialog

RTP/RTCP

SIP Dialog

MediaProcessor

SIP Star RT MultimediaMedia Plane Model

•Media Plane groups RT media streams (belonging to different SIP dialogs) for various application reasons

•Media Plane contains zero or more Media Processors

•Media Processor contains zero or more Presentation Spaces

PresentationSpaces

Media Processor

Conference participants:Edge (Remote): A, B, CCenter (Local): MM, A, and B are the loudest speakers

Note: Each remote participant has an associated SIP dialog

Example: a Default Audio “Media Processor”

RTPAudio Plane

A TypicalSIP Star RT Multimedia Conference

Center Participant Edge Participant

Basic UA Basic UAConferencingCenterLogic

ConferencingEdge Logic(Optional)

RTP/RTCP

CONFERENCING/CALL PLANECONFERENCING/CALL PLANE

VIDEO DATA PLANEVIDEO DATA PLANE

AUDIO DATA PLANEAUDIO DATA PLANE

PresentationSpaces

Conferencing Extensions

SIP Star RT MultimediaConferencing Application Main Requirements

•Conferencing “Presentation” Requirements

–Identity of the user presented to you–Presentation status (list) of your media

•Point-to-Point Requirements–Capabilities

•Exchange Procedure•Expressiveness

–Autonomous Media Control•RTCP Feedback

–Application Driven Media Control•Open Issue

Issues We Need to Address First

–Do We Have a Clear Enough Terminology in order to Describe the Requirements?

–Conference Identification

–Scope of the Baseline Requirements

–Baseline Means for their Implementation

–Direction for Resolving Application Driven Media Control Issue

A Proposal :Separate the Work into Three Documents

Allowing for Moving Forward Simultaneously

–Definition and Examples

–Definition

–Requirements and their mapping to primitives

–Definition

–Requirements and their mapping to primitives

Backup Slides for Follow-up Discussion

•Conference Identification

•Application Driven Media Control

Conference Identification

•User Wants to Create a Conference with Certain Specifications

–“Conference Service” Description is Required

•User Wants to Join an Existing (or a Scheduled) Conference

–Global Conference Identification is Required

Implicitly: The URI Option

• “SIP URI Conventions for Media Servers” draft-burger-sipping-msuri-01.txt– The Request-URI of INVITE specifies a

Conference (rather then a User)– Registration with IANA

• Spontaneous Conference– The Initiator of the Conference Creates a

Unique Conference Identifier

– The New Conference Identifier Triggers

Conference Creation by the MCU

Explicitly: New Headers

• “The SIP Join and Fork Headers” draft-mahy-sipping-join-and-fork-00.txt

– New Headers Used with INVITE to– Explicitly Join a Dialog (specified by Call-ID)

Application Driven Media Control

•Request for maximum (reserved) bandwidth

•Request for specific (current) bandwidth

•Request for using specific parameters:

–CODEC and its Params, Resolution, Frame Rate, etc.

•A Showstopper: Video Conferencing Applications MUST have deterministic way to switch between video sources