# VenueServer
[https://213.209.222.50:8000/VenueServer]
type = VenueServer
# Centro Monitoraggio Pazienti
[https://213.209.222.50:8000/Venues/default]
type = Venue
------------------------------------------------
I tried to mutually exclude the bridging
of the Venue or that of the VenueServer. In both cases, however, even if
the bridge seems running, it doesn't do his job: if 2 users connect their
client to the bridged venue they are able to switch to unicast mode choosing
the bridge server, but after that each one can see only audio/video that
comes out from his machine, no audio/video from the other. Is there something
misconfigured into my .cfg?
Second question: i tryed to connect
my 2.4 client to the venue:
https://ag2server.ag.manchester.ac.uk/Venues/default
then tried to switch to Unicast, the
msgbox for let me choose a bridge raised up and I selected:
AGSC/Manchester
but after that I got the following error:
"Use Unicast Error"
"Stream Information for selected
bridge not found; reverting to previous selection"
Only some more internal venue allowed
me to use unicast with a bridge, but connecting to it with a fellow of
mine who enabled unicast too, we are unable to get audio/video streams:
each one of us seems to be the only audio/video stream inside the venue.
As always thank you for your support,
Faber B.
owner-ag-tech@xxxxxxxxxxx scritti il 12/05/2006 13.40.20
> Hi,
>
> I am not sure if it is possible to tunnel an
entire venue server.
>
> What would be useful would be to have a bridge
server hosted on a
> multicast enabled network. This bridge server would allow you
to
> use the venue client in âunicastâ mode. This would make a
unicast
> connection to the bridge server and then the bridge server would
> make the multicast connection.
>
> You are welcome to use the AGSC venue server
just now to try this out (
> https://ag2server.ag.manchester.ac.uk/Venues/default). This
is an
> AGTk version 2.4 venue server, but we are bringing an experimental
> AGTk 3.0 server on line within a week (hopefully). All venues
on
> our server are bridged, although it is worth noting that this is
> still running as a âbest effortsâ server in that we try our best
to
> keep it running at all times, but donât guarantee that it is.
>
> If this works out, there may be scope for adding
more venues,
> although I will have to speak to my team here to see if this is
> possible. In this case, we would need a set of multicast addresses
> that you would want to use for the venues anyway â we donât have
any
> spare ones to use.
>
> I donât think there are any specific requirements
to set up
> multicast routing, but I am not an expert in this field. I would
> guess that you need your router, and every router between yours and
> another multicast router to be multicast enabled. I would then
> think that each router needs to know about the other multicast
> routers, although this may be done using a protocol, I am not too
sure.
>
> Let me know if I can help any more,
>
> Andrew J
> ============================================
> Access Grid Support Centre,
> RSS Group,
> Manchester Computing,
> Kilburn Building,
> University of Manchester,
> Oxford Road,
> Manchester,
> M13 9PL,
> UK
> Tel: +44(0)161-275 0685
> Email: Andrew.Rowley@xxxxxxxxxxxxxxxx
>
> From: Fabrizio.Berdondini@xxxxxxxxxxxx [mailto:Fabrizio.
> Berdondini@xxxxxxxxxxxx]
> Sent: 12 May 2006 09:08
> To: Andrew.Rowley@xxxxxxxxxxxxxxxx
> Cc: ag-tech@xxxxxxxxxxx
> Subject: RE: [AG-TECH] Venues Addresses: infrastructural question
>
>
> Thank you very much Andrew,
> quite clear right now....
>
> And now the question is...
>
> We are studying the development of an infrastructure for reasearch
> purposes focused on domiciliar monitoring of patients with
> Alzheimer's desease, leaving in islands or difficult to reach areas.
> It will be developed in collaboration with the Italian Ministry Of
> Health and other public structures, such as ISS (Istituto Superiore
> SanitÃ). We thought to base it onto the AccessGrid infrastructure.
> Thus we would need to have a couple of VenueServers connected to the
> Mbone in order to provide connectivity via Multicast for each
> videoconference dedicated machine at patient's home and for a
> central "Call Center", connected, again via videoconference
> dedicated machines, to some caregivers'/medicians' houses/hospitals.
> Would it be possible, and eventually how, to "tunnell" our
> VenueServer(s) in order to link it/them to the Mbone? How, and which
> pre-requisites are needed in order to require/gain access to the
> Mbone infrastructure?
> Thank you, as always, for your support,
> Faber B.
>
> "Andrew A Rowley" <Andrew.Rowley@xxxxxxxxxxxxxxxx>
scritti il
> 11/05/2006 12.44.34
>
> > Hi,
> >
> > As far as I understand it:
> > 1) The IP is a real multicast IP, with global scope.
> > 2) I think Argonne has reserved the IPs that they use with IANA.
If
> > you want to run a venue server, I would advise you do the same,
or
> > use your GLOP space. At the AGSC we only use static addresses.
The
> > server keeps track of the IPs in use internally â no talking
is done
> > between servers.
> > 3) This is standard multicast routing. Vic and rat communicate
> > directly with other vics and rats once they are running â the
only
> > use the venue server to get the addresses (unless you are using
> > unicast, in which case there is a bridge somewhere in the middle.
> > This bridge takes your unicast traffic and forwards it to multicast,
> > and vice versa).
> > 4) Multicast address routing works differently from unicast address
> > routing. Basically, your router must be multicast enabled
to allow
> > multicast to work from outside the router. It is possible
that it
> > will allow multicast to work inside the LAN without this, but
I am
> > not too sure. Your network card will respond to both the
192
> > address assigned to it, and multicast addresses, provided it
has
> > âjoinedâ the multicast group i.e. it has sent and IGMP message
to
> > the router saying that it wants to joint the group and receive
> > traffic addressed to that group.
> >
> > There may be some things that are not quite right in the above,
but
> > Iâm sure someone on the list will correct me if this is the
case.
> >
> > Andrew J
> > ============================================
> > Access Grid Support Centre,
> > RSS Group,
> > Manchester Computing,
> > Kilburn Building,
> > University of Manchester,
> > Oxford Road,
> > Manchester,
> > M13 9PL,
> > UK
> > Tel: +44(0)161-275 0685
> > Email: Andrew.Rowley@xxxxxxxxxxxxxxxx
> >
> > From: owner-ag-tech@xxxxxxxxxxx [mailto:owner-ag-tech@xxxxxxxxxxx]
> > On Behalf Of Fabrizio.Berdondini@xxxxxxxxxxxx
> > Sent: 11 May 2006 08:29
> > To: ag-tech@xxxxxxxxxxx
> > Subject: [AG-TECH] Venues Addresses: infrastructural question
> >
> >
> > Hello all,
> > while trying to resolve some troubles in our internal subnet
> > configuration, I was wondering how *exactly* the VenueServer
> > assigns/manages addresses for the venues. What I know, from official
> > documentation and from Thomas D. Uram messages inside this m/list,
> > is that the management of the IP for the venues can be either
static
> > or dynamic, meaning that I can assign a fixed IP to each venue
(one
> > for video, one for audio, and it will have always the same) or
let
> > the venueserver assign the IPs inside a variable range, giving
them
> > to audio/video of a venue when the first user asks to enter it,
> > while releasing them when the last person into the venue leaves
it.
> > What I'm not able to understand is:
> >
> > 1) is the IP assigned to audio/video for each room a *real* IP
(a
> > multicast IP publicly visible over the internet i mean) or is
there
> > some kind of alias/routing sistem underlying somewhere?
> > 2) In the first case, how can the venue server understand a
> > particular IP is "free" or "used" by someone
else (i.e. another
> > venueserver or another service)?
> > 3) In the second case, how is the routing done? How can the
> > venueserver address the two applications Vic and Rat (with some
kind
> > of DNS i guess) to the right IP?
> > 4) Again in the second case, how can the VenueServer assign/manage
> > addresses in ranges like 224.xxx.xxx.xxx when the allowed IPs
inside
> > a LAN are restricted to a range that goes from 192.168.2.10 to
> 192.168.2.150?
> >
> > I'm not sure if I could explain clearly what I'm looking for,
but
> > this matter, as far as now, is very critical to me, I'm ready
to
> > give any further clarification and open to every suggestion and
> information.
> > Thanx as always,
> > Faber B.