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/ge

neral/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 recommendationsThe 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