Requirements for Conference Control

1. Requirements for Conference Control Xiaotao Wu Petri Koskelainen Clayton C. Chen Columbia University/Nokia Henning Schulzrinne 53rd IETF - March 2002

2. Conference Control • Focus on media-independent control (see Orit Levin’s talk for media issues) • Conference models: • centralized: lowest-hanging fruit • centralized with replication: seems similar • fully meshed: probably same mechanisms, but harder to coordinate (distributed system) • multicast: may also work for SSM • Core property: single media “choke point” 53rd IETF - March 2002

3. Taxonomy of functions (incomplete) • 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 sip:my-new-conference@server)? • 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?) • Shared resource access, aka floor control 53rd IETF - March 2002

4. 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” 53rd IETF - March 2002

5. Floor control • General: management of shared resources • audio channel (typically, one) • video (limited by bandwidth, screen) • whiteboard and shared applications (one, but also multiple pointers) • 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 53rd IETF - March 2002

6. 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 53rd IETF - March 2002

7. 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 53rd IETF - March 2002

8. 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) 53rd IETF - March 2002

9. Summary • Conference control probably misnomer • Keep media stream control separate – may be needed for unicast just as much • Don’t require event subscription for participation (except maybe for moderator) • Divide into components, possibly prioritize: • conference creation and deletion • user admission • resource management 53rd IETF - March 2002