1. VRVS Research Roadmap (Caltech)

2. VRVS Deployment and Usage

3. VRVS Reflectors Deployment

4. USA27 Spain5 Brazil5 Switzerland5 UK3 France3 Slovakia3 Canada2 Taiwan2 Greece2 Portugal2 Israel2 Japan2 Pakistan2 Italy1 Germany1 Chile1 Poland1 Venezuela1 Hungary1 China1 Ireland1 Russia1 Czech Republic 1 Belgium1 Romania1 Australia1 Finland1 78 reflectors Deployment World wide in 27 Different Countries

5. VRVS registered users and current usage USA2239 Spain1304 Italy 638 Switzerland 576 France 571 Brazil 479 Germany 476 UK 398 Japan 168 Canada 167 Taiwan, Greece, Argentina, Russia, Slovakia, etc… 9461 different Users Registered 104 Countries from 104 Countries

6. Machines and OS VRVS support different Operating Systems according to the need and the demand of the final users: 1 st : Windows 2 nd : Linux 3 rd : Macintosh 4 th : Other UNIX

7. Call Details Record (CDR) Number of VRVS Meetings Number of Participants Total number of Minutes of video/audio connection NOV 2003 6922951144 Days, 17h, 14mn (3473 hours, 14mn) DEC 2003 6562734129 Days, 18h, 57mn (3114 hours, 57mn) JAN 2004 6872980189 Days, 4h, 23mn (4540 hours, 23mn) FEB 2004 7422797175 Days, 8h, 48mn (4208 hours, 49mn) MAR 2004 8733461195 Days, 23 h, 17mn (4703 hours, 17mn)

8. VRVS R&D

9. VRVS v3.0 (Feb 03), v3.1 (May 03) R R R R R R R R RR R R Web Shared Desktop + chat Video + Audio Database Principal characteristics Centralized database to manage users/meetings Tunneling between reflectors using one port independently of number of parallel conferences or users connected Shared desktop and chat connection via the web server VRVS Reflectors are manually configured and started by an operator The VRVS network infrastructure configuration is static Principal limitations Any network break between reflectors needs manual rerouting configuration Centralized Web server and database is a potential point of failure Chat and shared desktop network traffic via Web server No control/monitoring between reflectors and between reflectors and end users. Reflectors

10. VRVS Main Technical Trend Evolution 3.0 3.x 4.0 End users/applications Reflectors V3.(0,1): VRVS core infrastructure is statically and manually configured and operated V3.(2,x): VRVS core infrastructure is automatically configured and monitored. The core software is self dependant and can take self decision to improve performance/quality without manual intervention V4.0 and beyond: This is a Globally Distributed Self Managed End2End Real-time Infrastructure. It provides the best quality/performance possible Extend the core intelligence to the edge. Have a full End2End control and monitoring The self managed infrastructure has a full knowledge of all the critical/sensitive parameters (all network layers, hardware and software at the end nodes, resources allocated and available,..) in order to take adequate decisions (alarms, automatic rerouting of traffic, disconnection, remove/add services,..) Administrator is fully aware of the operational status via constant feedback (via UI, email, phone,..) from the self managed core software Extend intelligence to the edge

11. Dynamic registration to high level directory services Automatic re-activation of components and services Automatic and secure code update Continuous monitoring of network quality (packet loss, jitter, latency) between its peers and its possible peers Automatic rerouting to obtain the best performance/quality Automatic Alarm notifications when monitored parameters (system or network) go beyond a preset threshold Dynamically provides services (video, audio, data,..) that matches the current resources/capabilities to the end users/applications Provides access to real-time and historical data VRVS Reflector functionalities

12. Encryption VideoAudioData SIP/SIMPLEH.323 Scheduling serviceLogging service VRVS Discovery/Registration/Configuration Others protocols Monitoring Services VideoAudioData VideoAudioData VRVS ProxyVRVS Router Quality Assurance Services Admin service VRVS Reflector Architecture

13. Globally Distributed Self Managed Real-time Infrastructure VRVS v3.2 (Dec 03), v3.x: VRVS Services evolution Globally Distributed Self Managed Real-time Infrastructure R R R R R R R R RR R R Web Shared Desktop + chat Video + Audio Database Lookup Service Register Reflector + Monalisa agent

14. Globally Distributed Self Managed End2End Real-time Infrastructure VRVS v4.0 (Oct 04) VRVS Services evolution: Globally Distributed Self Managed End2End Real-time Infrastructure R R R R R R R R RR R R Shared Desktop + chat Video + Audio Web Distributed Web servers and Database Lookup Services Register End client Web Logging, Access to Virtual Rooms Reflector + Monalisa agent

15. Dynamic registration to high level directory services Automatic detection of the system parameters (CPU, Memory,..), hardware components (Audio card, video card, …), services capabilities (video, audio, …), network environment and capabilities (wireless environment, DSL, available bandwidth, …) Automatic re-activation of components and services Automatic code update Continuous monitoring of network quality (packet loss, jitter, latency) to the attached reflector and possible others reflectors Automatic rerouting to obtain the best performance/quality (The communication between an end node could be rerouted transparently and automatically to an other reflector for performance optimization) End users/applications functionalities (1/2)

16. Automatic Alarm notifications when monitored parameters (system or network) go beyond a preset threshold. As example: if Desktop CPU is too high, the system will automatically try to perform the following: reduce services (video/audio/data/..) running in the machine and inform user of the change or if no improvement, inform the user of the problem and from where it comes from (if possible) and then propose a solution (ultimately reset the system) Keep inform the general system administrator Dynamically gets services (video, audio, data,..) that matches the current resources/capabilities to end users/applications Provides access to real-time and historical data End users/applications functionalities (2/2)

17. Why VRVS Unique and advanced Architecture ?

18. MCU New York Los Angeles Tokyo Conf A Conf B Gatekeeper ports Example: Current H.323 architecture (Hub & Spoke)

19. VRVS New York Los Angeles Tokyo Conf A VRVS WEB Conf C Conf B VRVS new and unique architecture (Peer-to-Peer)

20. VRVS WEB Scalability, Reliability Usability

21. Schools / Companies IP Network layer (VNP, Wireless, QoS,..) Real-time scalable content distribution (VRVS)

22. Users Requirements –System Easy to Use –Booking, Scheduling, Coordination, Access Control,.. –Full Documentation (Hardware, Software, Procedures, Advice…). No need for an administrator ! –System Easy to Replicate –Accessibility everywhere with IP connectivity (Office, Home, Hotel, Wireless,.) –Minimum requirement: Need an IP connection (with sufficient bandwidth) and a Web Browser. VRVS was initially built to provide a relatively low cost system for videoconferencing and remote collaboration over networks for the HENP community

23. System Features requirements –Unified Video, Audio, Shared Virtual Spaces and Data Applications –Point to Point and Multi-point communication –Multiple Architecture Support: UNIX’s, Linux, Windows95/NT/2K/XP…Macintosh… –Network optimization (Latency, routing, reliability) –Extensible worldwide (several thousand users). –Should work for a variety of multipoint working environments From the desktop to conference rooms to amphitheatres –Should be highly scalable and reliable

24. Today Current systems and standards are not well adapted for large and disperse collaborations –H.323: Heritage from ISDN (H.320 standard) System very complicated to operated (need MCU, Gatekeeper, Gateway…) Not scalable at all. People are happy when they run a 50 MCU ports What about the millions of desktops ? Still focus on conference rooms. People currently are migrating their ISDN conference rooms to IP – SIP (Session Initiation Protocol): The most promising standard. Driving by the VoIP and Microsoft/Messenger Still need some real end applications (in particular Video applications)

25. –MPEG MPEG2 encoder/decoder still expensive ( > 10K$) MPEG4 encoder/decoder very promising but still have licensing issues No real Multipoint capability –Multicast Based Systems Still lack of deployment within LAN Difficult to support and operate widely Still unreliable for business quality Not supported by most Commercial ISP Lack of security