Hello Andrew, thank you for reply, as always clear and useful to me. The scenario you prospected to me is right the one I was thinking about as a "workaround" to the multicast problem. For this reason I first tried to configure a BridgeServer onto my VenueServer machine, but as far as now I'm still having some problems. Here is a description of what's happening. First of all, the VenueServer runs onto a dual-boot (XP Pro - SUSE 10) machine, located at an externally visible IP 213.209.222.50. I first tried to configure server and an experimental bridge for XP, so I created, following instructions found on AG portal, a BridgeServer.cfg file, with the following structure: ---------------------------- [BridgeServer] name = AGserver1 location = ReS qbexec = c:\programmi\AGtk2.4\bin\QuickBridge.exe BRIDGESERVER = AGserver portMin = 40000 portMax = 60000
# 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-t...@mcs.anl.gov 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.row...@manchester.ac.uk > > From: fabrizio.berdond...@prototipo.it [mailto:Fabrizio. > berdond...@prototipo.it] > Sent: 12 May 2006 09:08 > To: andrew.row...@manchester.ac.uk > Cc: ag-t...@mcs.anl.gov > 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.row...@manchester.ac.uk> 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.row...@manchester.ac.uk > > > > From: owner-ag-t...@mcs.anl.gov [mailto:owner-ag-t...@mcs.anl.gov] > > On Behalf Of fabrizio.berdond...@prototipo.it > > Sent: 11 May 2006 08:29 > > To: ag-t...@mcs.anl.gov > > 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.
