Hello team, A related comment about unicast is that with the general increase in background chatter on networks, it is likely that any form of videoconferencing is likely to suffer from momentary delays and/or packet loss, depending on network configurations. We've certainly seen that develop on our own systems.
A separate VLAN for videoconferencing would seem to be the obvious path. We've been running AG and ConferenceXP( which we use internally for interlinking lecture theatres) on our multicast VLAN for a few years, and have recently moved some H.323 and similar video conferencing to that VLAN. Prior to that our Lifesize H.323 units had started showing packet loss of a few thousand in 5 minutes; after moving the Lifesize's to the multicast VLAN (they are running unicast) the figure was 1-2 per hour. We've also had significant packet loss showing on AG running via the bridge at Auckland uni. Their staff have advised the problem is an overloaded firewall at Auckland, which at times is running at 800Mb/s but sometimes causing 20% packet loss. They are in the process of upgrading their capacity to a 10Gb/s structure I believe. They have made some modifications to the system so the AG packet loss on unicast has dropped from 10-30% to 1-2% which usually causes little problem. Those venues on multicast have 0% showing. Within New Zealand, all the universities are running AG on Windows XP or Windows 7, but all are running on the basic low resolution. The HD version would be hugely preferable but with 8 uni's running 1-2 cams each, the decoding for 720p is beyond most PC's running Windows. (I'd love to hear there is a way around that!) AG is still seen as being labour-intensive, and there are currently discussions in NZ that AG should be dropped due to this. There have been rumours of multi-camera versions Seevogh, Scopia (which is used heavily in NZ) and others, but we're still waiting....... Regards, Lloyd Pearson eConferencing Specialist Teaching & Learning Facilities, ITS University of Otago Dunedin New Zealand Ph +64 3 479 8997 lloyd.pear...@otago.ac.nz -----Original Message----- From: John I Quebedeaux Jr [mailto:jo...@lsu.edu] Sent: Wednesday, 5 June 2013 12:48 a.m. To: Christoph Willing; Tim Salmon Cc: 'accessgrid-tech@lists.sourceforge.net' Subject: Re: [AG-TECH] unicast bridge I'd like to echo Chris' comment about letting admins know if there is an issue with a bridge (for me this list is fine for that). In my case, we have reliable multicast in across our statewide fiber network that just a few of our sites need to use our unicast bridge - which is there mostly for emergency problems and sometimes i won't notice if there is an issue with it right awayŠ. -John Q. -- John I. Quebedeaux, Jr. Louisiana State University; Biological Sciences Computer Manager LBRN; 437 Life Sciences Bldg. Baton Rouge, LA 70803; 225-578-0062; http://lbrn.lsu.edu On 6/4/13 3:07 AM, "Christoph Willing" <c.will...@uq.edu.au> wrote: > >On 04/06/2013, at 5:01 PM, Tim Salmon <t...@unsw.edu.au> wrote: > >> Is it appropriate for us at UNSW with our unicast-only network to set >>up a unicast bridge or is this more appropriately set up in a multicast >>environment to assist those that are stranded, like us, in a unicast >>world? >> >> P.S. anyone else in the Australia/AP area noticed general problems with >>reliability of bridges lately? > >Very broadly, the second option (bridge set up in multicast environment) >is the most useful and intended scenario. > >However its a free world and there is at least one use case where a >bridge setting up a bridge in a unicast environment could be appropriate. >In that case, all participants in your meetings would/should connect via >that same bridge. Connections via other bridges or via multicast wouldn't >work or, at best, would work only by chance. This is similar to >traditional multipoint VC meetings where participants connect to a common >MCU. This technique wouldn't be useful as a day to day mechanism to >connect to meetings though. > >About bridge reliability in general, if you experience problems its >better to tell its admins about it - either directly or via the >appropriate list (this list for APAG & AccessGrid.org bridges) - straight >away so the problem can be fixed. We'd rather have these services running >smoothly rather than have people stewing about things not working. > >chris > > >Christoph Willing +61 7 3365 8316 >Research Computing Centre >University of Queensland > > > > >-------------------------------------------------------------------------- >---- >How ServiceNow helps IT people transform IT departments: >1. A cloud service to automate IT design, transition and operations >2. Dashboards that offer high-level views of enterprise services >3. A single system of record for all IT processes >http://p.sf.net/sfu/servicenow-d2d-j >_______________________________________________ >accessgrid-tech mailing list >accessgrid-tech@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/accessgrid-tech > ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ accessgrid-tech mailing list accessgrid-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/accessgrid-tech ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ accessgrid-tech mailing list accessgrid-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
