1. 8 December 2015SIP conferencing1 SIP Conferencing Henning Schulzrinne

2. 8 December 2015SIP conferencing2 Outline  Conference models  Conference functions needed: –create conferences –add and delete members –floor control –media control (freeze frame, update, camera control,...)

3. 8 December 2015SIP conferencing3  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

4. 8 December 2015SIP conferencing4 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 A RTP mixer INVITE B

5. 8 December 2015SIP conferencing5 Multicast conference  INVITE contains multicast group  pair-wise signaling relationships  no BYE is needed A C   multicast group

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

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

8. 8 December 2015SIP conferencing8 Centralized signaling, distributed media  uses third-party call control  can use multicast for media     A B C D conf42 A D A DD D

9. 8 December 2015SIP conferencing9 Centralized signaling, distributed media AB CDE INV D 200 hold INV 3held 200 3recv INV +D1 200 +C3 INV +D2 200 +B3 INV +D3 200 +A3 INV A3,B3,C3 200

10. 8 December 2015SIP conferencing10 Full mesh  No central server  Need SIP extensions to convey membership view  Can work even if some members leave A A B C D E    

11. 8 December 2015SIP conferencing11 Scaling end system multicastdial- in/out UA/  CS-DMfull mesh inbound bandwidth AA1 / AAA outbound bandwidth N-111 / NN-1 encodings N-111 / N11

12. 8 December 2015SIP conferencing12 Properties end system multicastdial in/outCS-DMfull mesh conference ID UA conference UA + ? membership notification RTCP NOTIFY RTCP NOTIFY INVITE list invite to join INVITE REFER INVITE join INVITE SAP INVITE

13. 8 December 2015SIP conferencing13 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

14. 8 December 2015SIP conferencing14 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?)

15. 8 December 2015SIP conferencing15 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

16. 8 December 2015SIP conferencing16 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”

17. 8 December 2015SIP conferencing17 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 active active

18. 8 December 2015SIP conferencing18 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

19. 8 December 2015SIP conferencing19 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)

20. 8 December 2015SIP conferencing20 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

21. 8 December 2015SIP conferencing21 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

22. 8 December 2015SIP conferencing22 Floor control operations CreateFloorcreate a floor for some resourcemoderator RemoveFloorremove the floor for some resourcemoderator ChangeConfigChange the configuration of a floormoderator ClaimFloorRequest a flooruser ReleaseFloorGive up the flooruser GrantFloorGrant floor to some usersmoderator RevokeFloorForce release floor from some usersmoderator RemoveClaimsRemove existing floor claimsmoderator ReorderClaimsReorder the claims in the queuemoderator

23. 8 December 2015SIP conferencing23 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

24. 8 December 2015SIP conferencing24 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

25. 8 December 2015SIP conferencing25 Suggested implementations  Floor and conference control commands  SOAP  Events (floor control, join)  SIP events  Merging and splitting conferences  REFER

26. 8 December 2015SIP conferencing26 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)

27. 8 December 2015SIP conferencing27 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

28. 8 December 2015SIP conferencing28 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