Videoconferencing update

Videoconferencing update A. Flavell, Glasgow Univ. For HEPSYSMAN meeting Nov 2002

"Multi-Site videoconferencing for the UK e-Science Programme"report for Tony Hey (EPSRC) Now available in http://umbriel.dcs.gla.ac.uk/NeSC/general/technical_papers/

Videoconf report • Report written for Tony Hey • Structure had been pre-set, sadly: • Separate chapters for different studio techs (AccessGrid; VRVS; H.323….) • One chapter lumped all non-studio together • AJF was asked to do Studio VRVS (whereas most of our experience has been either non-studio or mixed)

Tech Coverage in the report • Access Grid (AG) • VRVS • H.323/IP now, growing in future; H.320/ISDN role trailing off • Interoperability • Data Sharing Plus non-technical aspects (user factors etc)

Initial discussions • VRVS team were very helpful – showed report and future plans, commented on initial drafts… • Discussions with report author team showed many misconceptions about VRVS • The pre-defined structure made discussion of mixed situations difficult; the studio supporters were resistant to non-studio participants.

The AG session • After the initial drafting, we had a ~3hr AG session. AJF at the Glasgow DCS node. • AJF's first experience of AG… • Quite good in its way, but a number of teething troubles. Discussion showed that these were not just local oddities.

Status of the Report • 'Final' version was submitted (end Aug) • The report strongly favoured studios (despite AJF's misgivings) • The report contained a number of other constructive proposals. • Feedback received – not enough coverage of non-studio and VRVS. • Revised version submitted Oct., and now on web. • Some later discussion in the form of addenda.

Some recommendations • does not favour one technology to the exclusion of others (H.320/ISDN will fade) • Identifies some shortcomings in each of the offerings and their interworking • supports a number of tech. developments to enhance interworking, including VRVS • Calls attention to booking systems, organisation clashes, and the lack of a protocol for booking systems to work together.

AJF’s reactions • Overall technically sound, of course, and lots of fine content from all contributors. • But still too much emphasis on studio i.m.o • My view: working users want videoconf from desktop, even if quality inferior; and ad hoc if possible. These got short shrift in the report. Quality studio nice if you can get it, but users find it a nuisance to have to book in advance, go to special room elsewhere… plus: unsocial hours.

AJF‘s reactions (2) • Some authors gave the impression that given a choice between non-studio vconf and nothing, they’d prefer nothing. Our users don't think that way, I reckon. • Little coverage of confs involving 1 or 2 centres and some remote desktop participants: AJF stressed this is a common pattern in our community (+ timezones). • Little consideration of scenarios like the ESnet ‘ad hoc’ H.323 facility. OK – so much for the report…

An apology • Videoconferencing options are complicated • This is not of my making: I'm doing my best to show ways through the maze • Conferencing is working well for some groups of users. And it's cheaper than the telephone, once you have the kit. So why not give it a try? • Don't overlook the benefits of data sharing…

And now, the:ESnet 'ad hoc' H.323 At pilot stage, moving towards production use www-staff.es.net/~mikep/index.html

ESnet 'ad hoc' H.323 • Users must register; AUP requires USA participation (fair enough) • Hardware codecs: lowest client is ViaVideo. (Gnomemeeting under study…) • Voice switched or 2x2 continuous presence • No transcoding: audio is G711, needing 64k, so not suitable for participants who use ISDN or dialup access to Internet. (DSL is OK) • T.120 datasharing not yet stable enough to offer. (However, ESnet has a separate datasharing service – see later.)

ESnet H.323 ad.hoc: user experience • Don't confuse this with the (bookable) DCS • Our CDF users regularly use this service and it almost always works well • Users in unaccustomed places (Cosener's!) encounter firewall problems • Poor video with Zydacron (under study!) • (A gateway to ISDN exists: awkward to use)

JANET IP VCS (H.323): JIPVCS • Just now being rolled-out • Aimed at high-end use (studios mostly) • QA testing in situ is mandatory • They want to QA-test at 2Mb/s • They grudgingly OK'ed our Zydacron at 768k, though it hadn't really passed • We have no production experience as yet – some booked usage for early December

Campus H.323 MCUs etc. • Some campuses are known to have H.323 MCUs, gateways etc. • No details here, as usage would need permission from their owners. • Of course for simple point to point you don't need access to an MCU !

Purchase recommendations The PPNCG recommendations have not been kept up to date, sorry… • ViaVideo can be recommended (we got a good price from EDAS): but use software version 2.2 - version 3 causes problems. • The Zydacron recommendation is 'on hold', various interworking problems under study • Thus there is no concrete recommendation for group-sized gear. Ask your campus support about calling-off from the JIPVCS procurement? (Tandberg)

Purchase (2) • If only VRVS is required then anything which supports vic/rat will do • For H.323 find out whether software codecs (e.g NetMeeting or GnomeMeeting) are acceptable to your MCU provider, or not. • Recent ESnet H.323 saturation test (USA) showed that the vast majority use ViaVideo. • Hardware codecs generally support only Windows OSes. • ViaVideo security alert.

VRVS - http://vrvs.org • Generally working well, vic/rat or H.323 • Most problems turn out to be at user end, especially new/infrequent users get hardware setup problems • ViaVideo software v3 no good – 2.2 OK • Zydacron video not too happy – workaround available • New VRVS server version now pre-production: no time to try it yet sorry.

Data sharing • Data sharing can enable arbitrary application window or an entire desktop to be shown to other conferees • Or even allow other conferees (one at a time) to explore menus for themselves • This seems to be a magical facility that is, as yet, hopelessly under-used by our community, maybe through disquiet about its complexity?

Data sharing… • OK, I can't deny that the various available options mean that there is complexity • But the benefits are considerable: indeed some users reported that they found data sharing so valuable that they shoved the video window(s) out of sight… • B.t.w, don't share video windows! • Let's look at what's available

Data sharing options • Point to point (p2p) is easy if you have NetMeeting and Windows. Unixoid data sharing can be done via e.g eXceed. • VNC is another way, and crossplatform • Multipoint is harder, but do-able: • ESnet data sharing server (AUP!) • VRVS data sharing • JVCS data sharing

VRVS data sharing • Implemented with VNC • Cross-platform • Available only in booked virtual rooms (not coffee-rooms) • Works well, but of course needs the client software installed.

ESnet data sharing • ESnet's offering is currently a proprietary(?) server, accessed via a web browser and Java applet… http://audiobridge.es.net/ - ESnet AUP applies (USA participation) • Independent of their audio/video offerings • Support emphasises Win/xx; if Linux then you're on your own • Definitely worth a try if you're in their catchment.

JVCS data sharinghttp://jvcsbook.ja.net/docs/datash/ • Officially meant to complement the supported JVCS videoconferencing service: other users seem welcome (unlike A/V !) • Basically just a directory server (ILS) to help Netmeeting users connect to each other • Works independently of audio/video (users of zydacron, viavideo etc. need to uncouple netmeeting from their a/v application) • Works well, but unix apps need to work via a Windows PC with eXceed etc.

The End

Videoconferencing update