[AG-TECH] unicast bridge

[Tim Salmon]

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?

Regards,
Tim

__________________
***@unsw.edu.au<mailto:***@unsw.edu.au>
Mathematical Applications
School of Maths and Stats
UNSW

[Christoph Willing]

On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
Research Computing Centre
University of Queensland

[John I Quebedeaux Jr]

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" <***@uq.edu.au> wrote:

>
>On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>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-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>

[Lloyd Pearson]

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 [phone]
***@otago.ac.nz


-----Original Message-----
From: John I Quebedeaux Jr [mailto:***@lsu.edu]
Sent: Wednesday, 5 June 2013 12:48 a.m.
To: Christoph Willing; Tim Salmon
Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:

>
>On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>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-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>

[Tim Salmon]

Thanks Lloyd,
The perception of AG being labour-intensive is a problem here also. If our (bridging reliability?) issues can be resolved then that will reduce greatly.
Is there a contact list for admins of various bridges so that we can contact them directly?
Tim



-----Original Message-----
From: Lloyd Pearson [mailto:***@otago.ac.nz]
Sent: Wednesday, 5 June 2013 9:17 AM
To: 'accessgrid-***@lists.sourceforge.net'
Subject: Re: [AG-TECH] unicast bridge

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 [phone]
***@otago.ac.nz


-----Original Message-----
From: John I Quebedeaux Jr [mailto:***@lsu.edu]
Sent: Wednesday, 5 June 2013 12:48 a.m.
To: Christoph Willing; Tim Salmon
Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:

>
>On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>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-***@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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/accessgrid-tech

[Gurcharan S. Khanna]

all,

it seems appropriate for me to make just a brief comment here, having=
used the AG
for more than 10 years. and that is, without continued funding, the A=
G project just
has not been able to keep up with the overall technological advances =
in commercial
and competing research projects. even though AG provides some functio=
nality not
available in most other systems, few use cases demand these unique fe=
atures. so the
ability for AG to compete as a more general videoconferencing tool is=
diminished. and
it's value as a research project is an increasingly narrow one.

having said that, i continue to use vic (but not the rest of the AG p=
ackage) to encode
HD streams for a more kiosk/videowall type of scenario (The RIT Globa=
l Collaboration
Grid). but i am looking to replace it with something that is under co=
ntinuing active
development (like UltraGrid). so, this is my research use of the AG t=
ools, where ease of
use is not the issue but only performance is. but it has an end of li=
fe at some point.

for more general meeting purposes, i definitely vote for SeeVogh as t=
he most AG-like
in terms of functionality--esp. maintaining individual high quality s=
treams that i can
render on multiple displays. i run a development seevogh server here =
at RIT and i know
it can replicate the standard AG use case with better performance/fea=
tures given a similar
hardware infrastructure; and it has gone beyond in terms of user frie=
ndliness. it still
has a ways to go to replicate the unlimited performance possible with=
AG given enough
hardware, but i am hopeful that will change in the future. i would ho=
pe there will be a
merging of the easy to use meeting interface with the large scale dis=
play use a la AG
at some point in the future. that would be very nice.

also, we are continuing to develop 'grav' here at RIT, the OpenGL rep=
lacement viewer
for vic type streams, that eventually may integrated with UltraGrid (=
and SAGE). so the
research continues, but the everyday use cases demand a more ready to=
go solution
that doesn't require high maintenance.

just my two cents,

-gurcharan

PS oh regarding multicast bridges: i still like multicast a lot and a=
nd we assign each HD
stream its own unique multicast address so that we have maximum flexi=
bility in routing
streams where we want them to. unlike vic which aggregates all the st=
reams--that virtue
became a hindrance with the higher bandwidth now of each stream (our =
vic streams are
20 Mbps each; our UltraGrid streams will be higher). luckily, i can r=
un my own private
bridge to handle unicast connections so i control the bridge and an i=
nsure it's working.

PPS SeeVogh doesn't use multicast but given the typical meeting requi=
rements, it's not
a practical hindrance to just use unicast.

On 6/4/13 8:45 PM, Tim Salmon wrote:
> Thanks Lloyd,
> The perception of AG being labour-intensive is a problem here also.=
If our (bridging reliability?) issues can be resolved then that wil=
l reduce greatly.
> Is there a contact list for admins of various bridges so that we ca=
n contact them directly?
> Tim
>
>
>
> -----Original Message-----
> From: Lloyd Pearson [mailto:***@otago.ac.nz]
> Sent: Wednesday, 5 June 2013 9:17 AM
> To: 'accessgrid-***@lists.sourceforge.net'
> Subject: Re: [AG-TECH] unicast bridge
>
> Hello team,
>
> A related comment about unicast is that with the general increase i=
n background chatter on networks, it is likely that any form of video=
conferencing 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 internall=
y for interlinking lecture theatres) on our multicast VLAN for a few =
years, and have recently moved some H.323 and similar video conferenc=
ing 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 figu=
re was 1-2 per hour.
>
> We've also had significant packet loss showing on AG running via th=
e 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 unica=
st has dropped from 10-30% to 1-2% which usually causes little proble=
m. 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. Th=
e 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 (w=
hich 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 [phone]
> ***@otago.ac.nz
>
>
> -----Original Message-----
> From: John I Quebedeaux Jr [mailto:***@lsu.edu]
> Sent: Wednesday, 5 June 2013 12:48 a.m.
> To: Christoph Willing; Tim Salmon
> Cc: 'accessgrid-***@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 networ=
k 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=A9.
>
> -John Q.
>
> --
> John I. Quebedeaux, Jr.
> Louisiana State University; Biological Sciences Computer Manager LB=
RN; 437 Life Sciences Bldg.
> Baton Rouge, LA 70803; 225-578-0062; http://lbrn.lsu.edu
>
>
>
>
> On 6/4/13 3:07 AM, "Christoph Willing" <***@uq.edu.au> wrote:
>
>> On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 problem=
s
>>> 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 appro=
priate.
>> In that case, all participants in your meetings would/should conne=
ct
>> via that same bridge. Connections via other bridges or via multica=
st
>> wouldn't work or, at best, would work only by chance. This is simi=
lar
>> to traditional multipoint VC meetings where participants connect t=
o a
>> common MCU. This technique wouldn't be useful as a day to day mech=
anism
>> to connect to meetings though.
>>
>> About bridge reliability in general, if you experience problems it=
s
>> 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 th=
ings not working.
>>
>> chris
>>
>>
>> Christoph Willing [phone]
>> Research Computing Centre
>> University of Queensland
>>
>>
>>
>>
>> ------------------------------------------------------------------=
-----
>> ---
>> ----
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operation=
s 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-***@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/se=
rvicenow-d2d-j
> _______________________________________________
> accessgrid-tech mailing list
> accessgrid-***@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/se=
rvicenow-d2d-j
> _______________________________________________
> accessgrid-tech mailing list
> accessgrid-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/accessgrid-tech

--=20
Gurcharan S. Khanna, Ph.D.
Director of Research Computing
Office of the Vice President for Research
Assistant Research Professor, GCCIS Ph.D. Program
Director, Interactive Collaboration Laboratory
Rochester Institute of Technology
Phone: [phone] ~ Cell: 585-451-8370
http://rc.rit.edu http://rc.rit.edu/directions.html


CONFIDENTIALITY NOTE: The information transmitted, including attachme=
nts,
is intended only for the person(s) or entity to which it is addressed
and may contain confidential material. Any review, retransmission,
dissemination or other use of, or the taking of any action in relianc=
e
upon, this information by persons or entities other than the intended
recipient(s) is prohibited. If you received this information in error=
,
please contact the sender and immediately destroy any copies of this
information, including attachments

[Cook, Daniel (IHS/ALB)]

It may have a narrower scope than some videoconference platforms, but the free and open source Big Blue Button (bigbluebutton.org) video conferencing platform seems promising. The server can be in-house. With the right programming expertise, it can be adapted to suit wider needs.

-----Original Message-----
From: Gurcharan S. Khanna [mailto:***@rit.edu]
Sent: Wednesday, June 05, 2013 8:36 AM
To: Tim Salmon; 'Lloyd Pearson'; 'accessgrid-***@lists.sourceforge.net'
Subject: Re: [AG-TECH] unicast bridge

all,

it seems appropriate for me to make just a brief comment here, having used the AG for more than 10 years. and that is, without continued funding, the AG project just has not been able to keep up with the overall technological advances in commercial and competing research projects. even though AG provides some functionality not available in most other systems, few use cases demand these unique features. so the ability for AG to compete as a more general videoconferencing tool is diminished. and it's value as a research project is an increasingly narrow one.

having said that, i continue to use vic (but not the rest of the AG package) to encode HD streams for a more kiosk/videowall type of scenario (The RIT Global Collaboration Grid). but i am looking to replace it with something that is under continuing active development (like UltraGrid). so, this is my research use of the AG tools, where ease of use is not the issue but only performance is. but it has an end of life at some point.

for more general meeting purposes, i definitely vote for SeeVogh as the most AG-like in terms of functionality--esp. maintaining individual high quality streams that i can render on multiple displays. i run a development seevogh server here at RIT and i know it can replicate the standard AG use case with better performance/features given a similar hardware infrastructure; and it has gone beyond in terms of user friendliness. it still has a ways to go to replicate the unlimited performance possible with AG given enough hardware, but i am hopeful that will change in the future. i would hope there will be a merging of the easy to use meeting interface with the large scale display use a la AG at some point in the future. that would be very nice.

also, we are continuing to develop 'grav' here at RIT, the OpenGL replacement viewer for vic type streams, that eventually may integrated with UltraGrid (and SAGE). so the research continues, but the everyday use cases demand a more ready to go solution that doesn't require high maintenance.

just my two cents,

-gurcharan

PS oh regarding multicast bridges: i still like multicast a lot and and we assign each HD stream its own unique multicast address so that we have maximum flexibility in routing streams where we want them to. unlike vic which aggregates all the streams--that virtue became a hindrance with the higher bandwidth now of each stream (our vic streams are
20 Mbps each; our UltraGrid streams will be higher). luckily, i can run my own private bridge to handle unicast connections so i control the bridge and an insure it's working.

PPS SeeVogh doesn't use multicast but given the typical meeting requirements, it's not a practical hindrance to just use unicast.

On 6/4/13 8:45 PM, Tim Salmon wrote:
> Thanks Lloyd,
> The perception of AG being labour-intensive is a problem here also. If our (bridging reliability?) issues can be resolved then that will reduce greatly.
> Is there a contact list for admins of various bridges so that we can contact them directly?
> Tim
>
>
>
> -----Original Message-----
> From: Lloyd Pearson [mailto:***@otago.ac.nz]
> Sent: Wednesday, 5 June 2013 9:17 AM
> To: 'accessgrid-***@lists.sourceforge.net'
> Subject: Re: [AG-TECH] unicast bridge
>
> 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 [phone]
> ***@otago.ac.nz
>
>
> -----Original Message-----
> From: John I Quebedeaux Jr [mailto:***@lsu.edu]
> Sent: Wednesday, 5 June 2013 12:48 a.m.
> To: Christoph Willing; Tim Salmon
> Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:
>
>> On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>> 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-***@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-***@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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/accessgrid-tech

--
Gurcharan S. Khanna, Ph.D.
Director of Research Computing
Office of the Vice President for Research Assistant Research Professor, GCCIS Ph.D. Program Director, Interactive Collaboration Laboratory Rochester Institute of Technology
Phone: [phone] ~ Cell: 585-451-8370 http://rc.rit.edu http://rc.rit.edu/directions.html


CONFIDENTIALITY NOTE: The information transmitted, including attachments,
is intended only for the person(s) or entity to which it is addressed
and may contain confidential material. Any review, retransmission,
dissemination or other use of, or the taking of any action in reliance
upon, this information by persons or entities other than the intended
recipient(s) is prohibited. If you received this information in error,
please contact the sender and immediately destroy any copies of this
information, including attachments

[Tim Salmon]

[just found this in my drafts folder]
Thankyou Chris and also John for the detail.
It appears clear the right approach is to ensure that the multicast infrastructure is performing: are there definitive tests or measurements that we can perform that may help specify a bridge issue rather than a node problem?
We shall continue to look at bridging infrastructure that we can contribute.
Tim


Tim Salmon
Mathematical Applications Officer
School of Mathematics and Statistics
UNSW

________________________________________
From: John I Quebedeaux Jr [***@lsu.edu]
Sent: Tuesday, June 04, 2013 10:47 PM
To: Christoph Willing; Tim Salmon
Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:

>
>On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>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-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>

[John I Quebedeaux Jr]

Greetings again!

At LSU/Louisiana as part of our NIH grant (going on 11 years now - a
couple of renewals down the road) we're still utilizing the AG but
evaluating SeeVogh and other possibilities for all of the reasons brought
up.

Our success with AG has been entirely due to my supporting/training each
of our sites so that we have consistency with the experience and quality
(cue all the hard work Jason did with the QA) and having multicast support
across our statewide optical network.

I'm glad to see this discussion; i'm seeing commonality here and the
mention of SeeVogh repeatedly has strengthened that i might be going down
the right path for an alternative solution that can utilize our existing
hardware. Our testing is going well, except for some older CPU's bogging
down on the video display side due to how much i'm testing, it's going
well.

-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/5/13 9:35 AM, "Gurcharan S. Khanna" <***@rit.edu> wrote:

>all,
>
>it seems appropriate for me to make just a brief comment here, having
>used the AG
>for more than 10 years. and that is, without continued funding, the AG
>project just
>has not been able to keep up with the overall technological advances in
>commercial
>and competing research projects. even though AG provides some
>functionality not
>available in most other systems, few use cases demand these unique
>features. so the
>ability for AG to compete as a more general videoconferencing tool is
>diminished. and
>it's value as a research project is an increasingly narrow one.
>
>having said that, i continue to use vic (but not the rest of the AG
>package) to encode
>HD streams for a more kiosk/videowall type of scenario (The RIT Global
>Collaboration
>Grid). but i am looking to replace it with something that is under
>continuing active
>development (like UltraGrid). so, this is my research use of the AG
>tools, where ease of
>use is not the issue but only performance is. but it has an end of life
>at some point.
>
>for more general meeting purposes, i definitely vote for SeeVogh as the
>most AG-like
>in terms of functionality--esp. maintaining individual high quality
>streams that i can
>render on multiple displays. i run a development seevogh server here at
>RIT and i know
>it can replicate the standard AG use case with better
>performance/features given a similar
>hardware infrastructure; and it has gone beyond in terms of user
>friendliness. it still
>has a ways to go to replicate the unlimited performance possible with AG
>given enough
>hardware, but i am hopeful that will change in the future. i would hope
>there will be a
>merging of the easy to use meeting interface with the large scale display
>use a la AG
>at some point in the future. that would be very nice.
>
>also, we are continuing to develop 'grav' here at RIT, the OpenGL
>replacement viewer
>for vic type streams, that eventually may integrated with UltraGrid (and
>SAGE). so the
>research continues, but the everyday use cases demand a more ready to go
>solution
>that doesn't require high maintenance.
>
>just my two cents,
>
>-gurcharan
>
>PS oh regarding multicast bridges: i still like multicast a lot and and
>we assign each HD
>stream its own unique multicast address so that we have maximum
>flexibility in routing
>streams where we want them to. unlike vic which aggregates all the
>streams--that virtue
>became a hindrance with the higher bandwidth now of each stream (our vic
>streams are
>20 Mbps each; our UltraGrid streams will be higher). luckily, i can run
>my own private
>bridge to handle unicast connections so i control the bridge and an
>insure it's working.
>
>PPS SeeVogh doesn't use multicast but given the typical meeting
>requirements, it's not
>a practical hindrance to just use unicast.
>
>On 6/4/13 8:45 PM, Tim Salmon wrote:
>> Thanks Lloyd,
>> The perception of AG being labour-intensive is a problem here also. If
>>our (bridging reliability?) issues can be resolved then that will reduce
>>greatly.
>> Is there a contact list for admins of various bridges so that we can
>>contact them directly?
>> Tim
>>
>>
>>
>> -----Original Message-----
>> From: Lloyd Pearson [mailto:***@otago.ac.nz]
>> Sent: Wednesday, 5 June 2013 9:17 AM
>> To: 'accessgrid-***@lists.sourceforge.net'
>> Subject: Re: [AG-TECH] unicast bridge
>>
>> 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 [phone]
>> ***@otago.ac.nz
>>
>>
>> -----Original Message-----
>> From: John I Quebedeaux Jr [mailto:***@lsu.edu]
>> Sent: Wednesday, 5 June 2013 12:48 a.m.
>> To: Christoph Willing; Tim Salmon
>> Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:
>>
>>> On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>>> 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-***@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-***@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-***@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-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>
>--
>Gurcharan S. Khanna, Ph.D.
>Director of Research Computing
>Office of the Vice President for Research
>Assistant Research Professor, GCCIS Ph.D. Program
>Director, Interactive Collaboration Laboratory
>Rochester Institute of Technology
>Phone: [phone] ~ Cell: 585-451-8370
>http://rc.rit.edu http://rc.rit.edu/directions.html
>
>
>CONFIDENTIALITY NOTE: The information transmitted, including attachments,
>is intended only for the person(s) or entity to which it is addressed
>and may contain confidential material. Any review, retransmission,
>dissemination or other use of, or the taking of any action in reliance
>upon, this information by persons or entities other than the intended
>recipient(s) is prohibited. If you received this information in error,
>please contact the sender and immediately destroy any copies of this
>information, including attachments
>
>
>
>--------------------------------------------------------------------------
>----
>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-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>

[Todd Zimmerman]

Hey All,

Just wanted to throw in my $0.02 on the subject. As a long time user
of AccessGrid with many facilities + a server/bridge etc - when we
started transitioning away from AG we had many of the same concerns that
have already been discussed.

The solutions we went with are a combination of Vidyo, standard h.323
videconferencing (LifeSize, Cisco) and IOCOM. With the gateway
capability of both Vidyo and IOCOM system we can bridge one to the other
fairly seamlessly.

The point I'd strongly suggest is to ensure that any system you are
purchasing/looking into is capable of connecting using standards based
protocol - preferably h.323 and/or SIP. By ensuring this capability, it
allows us to connect these systems very easily for large calls handling
a range of desktop and room based systems. The Vidyo gateway allows
connection to h.323, SIP or telephone, is used extensively and works
well. The IOCOM <-> h.323 connection is a little less quality; however
last I checked they were working on it and I expect that it is
improving. This includes sending HD quality video as well as a HD
quality content feed.

Also, regarding the ability to have multiple live camera feeds within a
single room (in addition to the content feed), given the HD resolution
and quality of the cameras that come with these systems, we have not
often found the need for such a setup. Multicamera may have been
important when we were dealing with CIF resolutions, but now with HD, a
single camera can comfortably pick up multiple people around a table
with quite high clarity. You can still have multiple cameras and switch
between them if required, but the value of having multiple HD video
feeds live from a single room is a fairly rare use case. For the
rooms/setups where this is truly necessary (lecture halls) we run
multiple codecs in the room concurrently.

Regarding price, it is still a bit of a range. Nothing is free ;-)
h.323 systems and back end are still the most expensive but those prices
are dropping constantly. The ease of use (especially when you layer in
the ability to centrally control/manage and schedule the devices) is
really attractive. IOCOM is fairly reasonable and given the past
connection to AG, the IOCOM guys are always willing to discuss options.
Our most used technology, though, has been Vidyo. Relatively reasonable
price given what you get - bang/buck. Especially given range of options
(recording, control, management), devices (ios, android), platforms
(windows, mac, linux) etc. With CERN selecting Vidyo, it also made the
choice a little easier.

One complicating factor - the rapidly changing landscape of
collaboration technologies, especially cloud based solutions. Many of
the decisions we made regarding the collaboration systems/services we
would support were made a couple of years ago which was a substantially
different place. BlueJeans, Vidtel, Magor are all worth investigating too.

I'm willing to share more information regarding our
infrastructures/experiences with anyone if you want to discuss more.

Sorry for the long email, but I think its a great group and a great
discussion point. The more information we share, the better our
collaborations in the future.


Cheers,


Todd




On 13-06-05 08:17 AM, John I Quebedeaux Jr wrote:
> Greetings again!
>
> At LSU/Louisiana as part of our NIH grant (going on 11 years now - a
> couple of renewals down the road) we're still utilizing the AG but
> evaluating SeeVogh and other possibilities for all of the reasons brought
> up.
>
> Our success with AG has been entirely due to my supporting/training each
> of our sites so that we have consistency with the experience and quality
> (cue all the hard work Jason did with the QA) and having multicast support
> across our statewide optical network.
>
> I'm glad to see this discussion; i'm seeing commonality here and the
> mention of SeeVogh repeatedly has strengthened that i might be going down
> the right path for an alternative solution that can utilize our existing
> hardware. Our testing is going well, except for some older CPU's bogging
> down on the video display side due to how much i'm testing, it's going
> well.
>
> -John Q.
>

[John I Quebedeaux Jr]

Tim,

I don't know specifically a definitive test - unless this counts: my
version of testing involves having two nodes - putting one on multicast
and another i use on different bridges and seeing how they interact
(video/audio up) between the two nodes. I can test multicast this way
between the bridge location in question and my multicast. The other test
is multicast between bridges (if one isn't mine - otherwise it's usually
redundant if i'm on multicast or not locally except to test my bridge)
between my bridge and a remote bridge because multicast between the
bridges would have to work... which helps verify i have multicast
connectivity in/out of campus, in/out of state, in/out of country (in a
particular directionish) or just between two external locations (and back
to me if i have a third node for more fun and access grid games)...

In this way i've quickly established when i'm having multicast issues and
approximately the scope (area - in or out of campus/state/country) between
the two locations and then try to get the appropriate networking folks to
start looking at it from the IP information i can give them.

I've never had a bridge 'issue' locally - it's always been a network issue
within a site where a client was running (except the one time i was
working on the local bridge machine's firewall). Usually i can test my
bridge and verify this to the site having client issues with it always
turns out to be a networking issue there...

Hope that gives some kind of help...

Cheers, 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/23/13 7:22 PM, "Tim Salmon" <***@unsw.edu.au> wrote:

>[just found this in my drafts folder]
>Thankyou Chris and also John for the detail.
>It appears clear the right approach is to ensure that the multicast
>infrastructure is performing: are there definitive tests or measurements
>that we can perform that may help specify a bridge issue rather than a
>node problem?
>We shall continue to look at bridging infrastructure that we can
>contribute.
>Tim
>
>
>Tim Salmon
>Mathematical Applications Officer
>School of Mathematics and Statistics
>UNSW
>
>________________________________________
>From: John I Quebedeaux Jr [***@lsu.edu]
>Sent: Tuesday, June 04, 2013 10:47 PM
>To: Christoph Willing; Tim Salmon
>Cc: 'accessgrid-***@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" <***@uq.edu.au> wrote:
>
>>
>>On 04/06/2013, at 5:01 PM, Tim Salmon <***@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 [phone]
>>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-***@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
>>
>
>
>