Advanced SIP Conferencing: Models, Functions, and Control Mechanisms

1. SIP Conferencing Henning Schulzrinne SIP conferencing

2. Outline • Conference models • Conference functions needed: • create conferences • add and delete members • floor control • media control (freeze frame, update, camera control, ...) SIP conferencing

3. Conference 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” SIP conferencing

4.  End system mixing INVITE B B • classical three-way calling • transparent to B, C • RTCP indicates parties (SDES) • departure of participant  partition • users can join  GUI issue A+C A RTP mixer A+B C SIP conferencing

5. Multicast conference C A • INVITE contains multicast group • pair-wise signaling relationships • no BYE is needed multicast group    SIP conferencing

6. Dial-in conference B+C RTP mixer • Conferences identified by SIP URI • ad-hoc (new URI) and pre-arranged INVITE conf42  A B A conf42@example.com REFER D Refer-To: conf42 C D SIP conferencing

7. Dial-out conference B+C RTP mixer • Similar to dial-in conference  A B INVITE A From: conf42 REFER conf42 Refer-To: D conf42@example.com A C D SIP conferencing

8. Centralized signaling, distributed media • uses third-party call control • can use multicast for media conf42  A A D  D A D C  B  D D SIP conferencing

9. INV D 200 hold INV 3held 200 3recv INV +D1 200 +C3 INV +D2 Centralized signaling, distributed media A B C D E 200 +B3 INV +D3 200 +A3 INV A3,B3,C3 200 SIP conferencing

10. Full mesh  B A • No central server • Need SIP extensions to convey membership view • Can work even if some members leave   A C   D E SIP conferencing

11. Scaling SIP conferencing

12. Properties SIP conferencing

13. 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 SIP conferencing

14. 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?) SIP conferencing

15. 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 SIP conferencing

16. 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” SIP conferencing

17. 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="conf233@example.com"> <user uri="sip:jdrosen@dynamicsoft.com" display-name="Jonathan Rosenberg"> <status>active</status> <media-status> <media-stream media-type="audio"/> </media-status> </user> <user uri="sip:hgs@cs.columbia.edu" display-name="Henning Schulzrinne"> <status>active</status> </user> </conference-info> SIP conferencing

18. 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 SIP conferencing

19. 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) SIP conferencing

20. 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 SIP conferencing

21. Floor control proposal • SDP for indication a=type:moderated a=group:FL 1 2 4 a=group:FL 3 5 m=audio 10000 RTP/AVP 0 a=mid:1 m=video 20000 RTP/AVP 31 a=mid:2 m=application 30000 udp wb a=mid:3 m=control 80 HTTP SOAP a=mid:4 m=control 5060 SIP SOAP a=mid:5 • SOAP for requests • SIP events for notification • floorCreated, floorRemoved, configChanged, floorChanged, queueChanged • Uploaded policy document for policy decisions and configuration SIP conferencing

22. Floor control operations SIP conferencing

23. 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 SIP conferencing

24. 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 SIP conferencing

25. Suggested implementations • Floor and conference control commands  SOAP • Events (floor control, join)  SIP events • Merging and splitting conferences  REFER SIP conferencing

26. 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) SIP conferencing

27. 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 SIP conferencing

28. 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 SIP conferencing