SIP Conferencing

April 22, 2023 SIP conferencing 1

SIP Conferencing

Henning Schulzrinne


Outline

Conference models Conference functions needed:

– create conferences– add and delete members– floor control– media control (freeze frame, update,

camera control, ...)


Focus on media-independent control Conference models:

– centrally-signaled = single conference URI• "focus" of conference• media mixer associated with conference server• central signaling + distributed mixing

– third-party call control for multicast or multi-unicast• dial-in or dial-out

– distributed signaling• anybody can invite new members• multicast data or• full mesh

Core property: single media “choke point”

Conference Control


End system mixing

classical three-way calling transparent to B, C RTCP indicates parties (SDES) departure of participant partition users can join GUI issue

A+C

A+B

B

C

ARTP mixer

INVITE B


Multicast conference

INVITE contains multicast group pair-wise signaling relationships no BYE is needed

A C

multicast group


Dial-in conference

Conferences identified by SIP URI ad-hoc (new URI) and pre-arranged

RTP mixer

[email protected]

INVITE conf42A B

C

A

B+C

REFER DRefer-To: conf42D


Dial-out conference

Similar to dial-in conference

RTP mixer

[email protected]

INVITE AFrom: conf42

A B

C

A

B+C

REFER conf42Refer-To: D

D


Centralized signaling, distributed media

uses third-party call control can use multicast for media

A

B C

D

conf42

A

D

A

D D

D


Centralized signaling, distributed media

A B C D EINV D

200 hold

INV 3held

200 3recv

INV +D1

200 +C3

INV +D2

200 +B3

INV +D3

200 +A3

INV A3,B3,C3

200


Full mesh

No central server Need SIP extensions to convey

membership view Can work even if some members leave

A

A

B

C

DE


Scaling

end system

multicast

dial-in/outUA/

CS-DM full mesh

inbound bandwidth

A A 1 / A A A

outboundbandwidth

N-1 1 1 / N N-1 N-1

encodings N-1 1 1 / N 1 1


Properties

end system

multicast dial in/out

CS-DM full mesh

conference ID

UA UA conference

conference

UA + ?

membership notification

RTCP RTCP RTCPNOTIFY

RTCPNOTIFY

INVITE list

invite to join

INVITE INVITE REFER REFER INVITE

join INVITE SAP INVITE INVITE INVITE


Non-SIP open issues

device control for remote devices (cameras)

freeze frame SDP (like hold) intraframe request RTCP? SDPng for description

– channel description– better capabilities


Taxonomy of conference control functions

Needed throughout conference life cycle Create new conference

– properties: duration, media, user limit, ...– mass-invitation– but: is this needed beyond the current ad-hoc

conference creation?

Invite users REFER Admit users

– similar to presence subscriber problem?• proactive policy (“don’t admit *.fbi.gov”) CPL?• individual decisions: “Alice wants to join”

Eject users (less important?)


More requirements

Anonymity?– request that presence not be

announced– requires trust in conference server

Get participant list Notification of members joining

and leaving sidebars – listen to main

conference in background


Functions Not every conference needs all functions Web interface can be done, but hard to script Don’t assume single person has multiple

roles– bouncer (sergeant-at-arms) vs. moderator

Need to deal with moderator failure– distributed leader election problem is hard– may want to punt

Provide mechanisms, avoid guessing at policy– “only admit Joe if fewer than 4 participants and if

65% of participants agree”


Conference events• SUBSCRIBE to conference, get NOTIFY'd• incremental or full state• user state: active, departed, booted, failed (dial-out)• dialog state• for each user, media status: media stream

• sending: received-by-all, muted• receiving: receiving-all, anchor-only

<conference-info version="0" state="full" entity="[email protected]"><user uri="sip:[email protected]" display-name="Jonathan Rosenberg"> <status>active</status> <media-status> <media-stream media-type="audio"/> </media-status> </user> <user uri="sip:[email protected]" display-name="Henning Schulzrinne"><status>active</status></user></conference-info>


Floor control

General: management of shared resources– audio channel (right to talk; typically,

one)– video (limited by bandwidth, screen)– pointer and input focus for whiteboard

and shared applications (one, but also multiple pointers)

= safe and mutually exclusive input access to shared resource


Floor control

Managed by– automated queuing

• policy can be messy (“priority to speakers that have talked for less than 5 minutes”)

• suggestion: punt on policy

– one or more moderators

control at signaling level– mute participants– cooperative users

may also control media resources (mixer)


Floor control requirements

Determine floor controlled sessions floor may encompass more than one media

session restrict creation of floor create and destroy floors dynamically moderator-controlled policy

– also automated policies (FCFS, random, least time held, ...)

multiple moderators participants can claim and release floor parameters such as time limits


Floor control proposal SDP for indication

a=type:moderateda=group:FL 1 2 4a=group:FL 3 5m=audio 10000 RTP/AVP 0a=mid:1m=video 20000 RTP/AVP 31a=mid:2m=application 30000 udp wba=mid:3m=control 80 HTTP SOAPa=mid:4m=control 5060 SIP SOAPa=mid:5

SOAP for requests SIP events for notification

– floorCreated, floorRemoved, configChanged, floorChanged, queueChanged

Uploaded policy document for policy decisions and configuration


Floor control operationsCreateFloor create a floor for some resource moderator

RemoveFloor remove the floor for some resource moderator

ChangeConfig

Change the configuration of a floor moderator

ClaimFloor Request a floor user

ReleaseFloor Give up the floor user

GrantFloor Grant floor to some users moderator

RevokeFloor Force release floor from some users moderator

RemoveClaims

Remove existing floor claims moderator

ReorderClaims

Reorder the claims in the queue moderator


Floor control requirements

Create a managed resource– zero, one or multiple media

Remove managed resource Change resource configuration

– moderator, users, concurrency

Request resource Grant resource Revoke resource

– including pending requests

Release resource Reorder resource claims


Commonalities across functionalities

Functions are largely orthogonal But share communication needs:

– asynchronous events• “Bob joined conference” (sip-call-

package)• “Carol has released floor”• “David has requested floor”

– commands to conference• avoid commands directly to participants


Suggested implementations

Floor and conference control commands SOAP

Events (floor control, join) SIP events

Merging and splitting conferences REFER


Questions

How hostile is the conference?– If participants basically trust each other,

moderator failure is much easier to deal with

– Define trusted subgroup?• Panel discussion model: panel vs. mob audience

Scaling requirements?– Primarily notifications are issue– Centralized conference model imposes

some limitations, but can still be hundreds REFER can provide some functionality

(invite, eject)


Current Conferencing Internet Drafts

Conference models– draft-ietf-sipping-conferencing-models-01

Event package– draft-ietf-sipping-conference-package-00

Floor control– draft-wu-sipping-floor-control-01

Requirements– draft-khartabil-sip-conferencing-00– draft-koskelainen-sipping-conf-requirements-

00– draft-levin-sipping-conferencing-

requirements-01


Summary

Conference control probably misnomer Keep media stream control separate –

may be needed for unicast just as much

Divide into components, possibly prioritize:– conference creation and deletion– user admission– resource management

Date post:	02-Feb-2016
Category:	Documents
Upload:	callia
View:	23 times
Download:	0 times

SIP Conferencing

Documents