1 © NOKIA IPTel2001.PPT/ / DOT Scalable Floor Control in Conferencing Environments : The RBone Approach Dirk Trossen Nokia Research Center Boston IP Telephony Workshop 2001

2 © NOKIA IPTel2001.PPT/ / DOT Outline Motivation Services Approach Protocol However, no detailed protocol description (see paper) Conclusion and Outlook

3 © NOKIA IPTel2001.PPT/ / DOT What Scenarios ? Enterprise scenarios Shared lectures Why Floor Control ? Regulating access to resources in conference scenarios, e.g., Right to speak Right to send video to common MC group Right to control shared application Motivation Map Social Protocols onto distributed environments (tight control) Connecting few multicast-capable LANs with possibly larger number of participants

4 © NOKIA IPTel2001.PPT/ / DOT What’s provided ? Provision of floors, identified by unique name Decimal naming recommended No temporary inconsistencies Provided services : Grab floor (exclusive use) Inhibit floor (non-exclusive use) Release floor Test floor status Ask current holder for floor Give floor to other user Query floor holder list very similar to T.122 services (except floor holder list)

5 © NOKIA IPTel2001.PPT/ / DOT Approach Related Work Tree-based approaches Multicast-based approaches Users are routing requests Multicast-routing is used Stars as simplest form Shortest-path routing (SCCS) Routing to topmost (ITU T.122) Tree of inter-connected users (not necessarily binary) Multicast each request reliably Large response time Temporary inconsistency (e.g., NTE) Resolve inconsistency on application level

6 © NOKIA IPTel2001.PPT/ / DOT Floor Control Island Conference Management Group Use multicast on local level Combine tree- and multicast-based approaches Approach Idea Use floor-control-specific unicast routing on global level Choose dedicated users to route requests RBone RBone provider

7 © NOKIA IPTel2001.PPT/ / DOT Assumptions Different multicast groups are known Using SDP for description Using SAP or similar for announcement Unicast Transport Connection failure indication provided Multicast transport Globally ordered messages Reliability Using local multicast scope only Each user maintains local floor context, i.e., name, status, and local holders for each floor

8 © NOKIA IPTel2001.PPT/ / DOT Protocol Functionality Environment Maintenance Global: Establish RBone Extend RBone Repair Rbone Local: Join FCI Heartbeat Service Requests Grab Inhibit Release Test Ask Give Holder List Routing of service requests: First, send request to local FCI if necessary, local RBone provider forwards request using Rbone decision based on local floor context if necessary, local RBone provider relays RBone messages on FCI

9 © NOKIA IPTel2001.PPT/ / DOT Example: Floor Asking Check Floor Context Send out locally Forward globally Relay locally

10 © NOKIA IPTel2001.PPT/ / DOT Failure Recovery RBone connection fails Both RBone providers start RBone extend operation Local RBone provider quits First, selection of new local RBone provider Second, new RBone provider starts RBone extend operation Local RBone provider fails Detected by heartbeat Selection of new RBone provider depending on age of local users New RBone provider starts RBone extend operation Service requests are handled appropriately during repair Floor holder fails (or quits without releasing) Currently not covered, but local heartbeat might be used

11 © NOKIA IPTel2001.PPT/ / DOT Conclusions Presented floor control protocol for conference course control Related approaches based on either unicast or multicast schemes Idea: Use multicast on local, unicast on global level Scenarios: Several MC-capable islands, e.g., –Enterprise meetings –Shared lectures Protocol includes maintenance & service request functionality Failure recovery also addressed

12 © NOKIA IPTel2001.PPT/ / DOT Future Work Naming scheme for floors Decimal numbers recommended Other failure modes Include floor holder failure … Protocol prototyping, simulations,…

13 © NOKIA IPTel2001.PPT/ / DOT Thank You ! For further information: