SIP and SIPPING WGsMay, 6-7 2002 IETF Interim Meeting Orit levin [email protected] Conferencing...

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

Orit levin

[email protected]

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

White BoardT.120 BasedApplication

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

EDGE

SIP Dialog

EDGESIP Dialog

EDGE

SIP Dialog

UA

UA

UA

UA


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

EDGE

RTP/RTCP

SIP Dialog

EDGE

RTP/RTCP

SIP Dialog

EDGE

RTP/RTCP

SIP Dialog

UA

UA

UA

UA

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


C

A B

M+A+B

M+C

M

RTP

RTP

RTP

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”

M+B

A+B

RTPAudio Plane


A TypicalSIP Star RT Multimedia Conference

Center Participant Edge Participant

Basic UA Basic UAConferencingCenterLogic

ConferencingEdge Logic(Optional)

SIP

RTP/RTCP

RTP/RTCP

CONFERENCING/CALL PLANECONFERENCING/CALL PLANE

VIDEO DATA PLANEVIDEO DATA PLANE

AUDIO DATA PLANEAUDIO DATA PLANE

PresentationSpaces

Conferencing Extensions

MP

MP


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

SIP and SIPPING WGsMay, 6-7 2002 IETF Interim Meeting Orit levin [email protected] Conferencing...

Documents

Transcript of SIP and SIPPING WGsMay, 6-7 2002 IETF Interim Meeting Orit levin [email protected] Conferencing...