Error with creating venues

ตอบทั้งหมด

• 6 สิงหาคม 2549 19:08

   

   
  

  0
  All of a sudden, when i try to access   http://localhost/venueservice/venueservice.asmx  the file opens in MS Development environment. I am not able to see the methods because of this and check the availablity of my created venue.
   
• 6 สิงหาคม 2549 20:08

   

   
  

  0
  I have made some progress since the last post. I am now able to retrieve the list of venues on the venue server and also the created venues are visible. Also I am able to see the participants in the venue that I created. I had reinstalled IIS and remembered to register asp.net with it. Followed the instructions on the Venue service installation page and things worked like a charm. My next step would be to make this venue visible to all users, among the ones listed when CXp starts. Am working on it. IN the meantime any useful pointers in this regard will be useful.
   
• 7 สิงหาคม 2549 18:29

   

   
  

  0

  Karthik,

  I'm not sure I completely understand your question / comment - "My next step would be to make this venue visible to all users, among the ones listed when CXp starts."

  It sounds like you understand how to get a client to point at a VS, but just in case that is the stumbling point... You need to add a link in your client to your Venue Service.  That is done through Settings / Services / Venue Service.  Add an entry at http://<MachineNameOrIPAddress>/<VirtualDirectory>/venueservice.asmx.

  JVE

   
• 8 สิงหาคม 2549 0:05

   

   
  

  0
  Jason,
  Thnx for the reply. I have already done what you have suggested and it works. What I want to do is make the venue visible to users outside of my network as well. If I am right, this is done when I have the port on my router forwarded to 80 on the venue server? Also regarding the multicast ip address, how do I determin what is my address. Is it the one that is listed under Multicast Ip address when I run the connectivity detector. It is shown as 233.4.12.3. However watching the presentations in the documentation section, I noticed that one of the developers listed the same address. I am beginning to doubt if 233.4.12.3 afterall is my multicast address or is something else!
  
   
• 8 สิงหาคม 2549 1:12

   

   
  

  0
  Hi Karthik,
  
  You are right about the port forwarding:  you just have your router forward this port to the machine you have the venue service installed on and then anyone can connect to it by adding your router's public ip address (not the 192.168.* one) to their list of venue services in CXP.
  
  As to the the multicast IP address, generally speaking you can make this whatever value you want between 224.0.1.0 through 238.255.255.255.  Multicast IP addresses are a lot different from normal IP addresses.  Instead of identifying a machine, it instead identifies a group.  All the members of that group have their own personal IP addresses, but they also share the multicast address.  The group is allowed to choose any address it wants to be identified by, as long as everyone knows what that address is and they all use it for sending and receiving data. 
  The reason that you get 233.4.12.3 as your multicast IP and this value is also what you saw in the presentation is that is the group address that CXP uses to determine whether or not you are able to receive and send multicast data.  CXP has everyone connect to that address when they run the connectivity detector to see if they can receive data as part of that group.   The developers could just as easily have chosen 233.4.12.4 or 233.10.44.72 or any other value.
  
  If you take a look at Microsoft's venue services, they all belong in the 233.31.135.* range.  You could use one similar to this, or something completely different if you want to :).
  
  Hope this helps,
  Adam
  
   
• 8 สิงหาคม 2549 19:45

   

   
  

  0

  Jason & Adam,

  Thanx for the replies. I have this recurring doubt about multicast. When I start CXp on a machine and start Connectivity detector it returns False to all four status (N/w send, N/w recieve, ....) However when I run Cxp on another machine and configure the service to the machine running the server, the status changes to TRUE for the first three. Is this because only machines behind the router and connecting to one another have multicast by nature? Is there a possibility that my n/w isnt multicast afterall? I tried forwarding the port (5004) on my router to the machine running the venue server.and again I am able to see only the local venue when I connect to the venue server(note I changed the IP address to the sxternal IP address of the router). Should I forward any other ports?

   
• 9 สิงหาคม 2549 3:29

   

   
  

  0
  Dear Karthik,
  
  Sorry for the confusion.  Maybe I can clear this up a little bit.  The Venue Service is really nothing more than a web service that stores a list of names of venues, participant info (like name and email address), and multicast addresses for those venues.  Whenever you click on a venue to join it within CXP, you don't actually connect within the venue service server anywhere.  Instead, your computer just joins the multicast address specified by that venue, and any one else you can share a multicast connection with can join that address, too.  A venue service is more like a meeting schedule that tells people where to meet if they want to spend time together.  They don't actually spend time in the listings.  This is definately one of the most confusing parts of CXP and one that I got hung up for awhile on when I started using CXP and developing capabilities for the project.  This is why you only need to forward port 80 (HTTP) to that machine since it only operates on HTTP (all requests for venues are over HTTP).  I'm sorry if this still doesn't make sense; I don't think it was that good of an explination :(
  
  Ok, now on to multicasting.  Basically, multicasting gets blocked when you start operating behind routers.  Most routers are not configured to enable multicasting by default, so this poses a problem to using CXP (although networking people can go in and change those settings, but some departments don't want it on).  Now, any computer within the same subnet (those that share the first 3 octets of the IP address (e.g., 192.168.1.*) connected to the same router or access point can automatically send and receive multicast messages to/from each other.  Once you start jumping across subnets or past routers, that traffic will be blocked.  If you need to send messages across subnets or past routers, you might want to look into using the reflector service.  Computers outside of your subnet can connect to it and send and receive any traffic going on between the computers connected to that router.  Basically, it takes multicast packets and sends them over unicast so anyone can receive them.
  
  An easy test to see if your network is multicast or not is to join one of Microsoft's venue services and pick any venue and join it on two different machines in your network.  If they can see each other, then your network is multicast.  Note: try to make it so they are on different subnets -- maybe try connecting in different buildings, or one over LAN and one over WiFi.  The connectivity detector only tells you if your network has nothing blocking it from multicasting with anyone else in the world.  There could be something in your ISP or some where else blocking multicasting with other people, but multicasting might still be enabled on your network.
  
  Finally, you shouldn't need to forward port 5004 to your venue service.  Ports 5004 and 5005 are the ports that CXP sends its multicast packets over.  Since none of these packets need to go to your venue service (remember, it is just a listing), you can unforward that port. Also, since you can't see anything but the local venue anymore, you might want to change your IP address on that machine back to whatever it was before you changed it to the external address of the router.  Since the router and the machine now have the same IP address, there is probably a conflict that is preventing everyone from seeing your venues.  If you change this, you should hopefully be able to see the venues again.  If not, we will try to help you get them back! :)
  
  I hope all of this helps.  If I don't make any sense, just tell me :)
  
  Adam
  
  
   
• 9 สิงหาคม 2549 13:55

   

   
  

  0

  Adam is right on in his explanations.  The one thing I would add is how the Connectivity Detector actually works.

  It sends out RTP data to a known multicast address, and listens for data on that address as well.  If it receives data, then network receive is true.  If the person you are receiving data from receives your data (in other words if the data is flowing in both directions) then network send is true.  If both network send and network receive are true, then you are multicast enabled between those 2 points.  We also have (or should have, depending on if the machine reboots and whether or not we remember to restart it) a machine here that is also running Connectivity Detector.  It is a well-known host.  If you receive data from the well-known host and your are multicast enabled, then we mark you as having Internet2 connectivity.

  At this point I should mention that Internet1 is not multicast enabled.  In order to connect from your ISP, to most other sites, you will need to use a Reflector.

  JVE

   
• 9 สิงหาคม 2549 22:13

   

   
  

  0
  Adam,
   thanx for the detailed explanation. I get what you have said. I undid forwarding the 5004 ports and instead did the 80 port. Now the venue appears on the machines within the LAN. I am currently sitting at my home and tried to connect to the newly created venue by having the venue service point to the venue server on my Lab( i specified http://ipaddres/venueservice) correctly and even now only the local venue pops up. I have followed the port forwarding method correctly ( added a custom service mentioning the ports to be used and then provided the local machine ip address for which the service should be forwarded to) Is there something else that I am missing?
  
   
• 10 สิงหาคม 2549 0:10

   

   
  

  0
  Dear Karthik,
  
  That sounds like it should be working, especially if all the machines within your LAN can see the venue service without problem.  Quick question, though:  when you say you specified "http://ipaddress/venueservice", which ip address are you using?  Within your LAN, you would want to use the local 192.168.*.* one.  However, when accessing from home, you would want to use the external IP address of your router (this will not begin with 192.168.*.*).  It does sound like you forwarded the port correctly, so I'm not sure what the problem is if you are using the external address of the router.  One more question, though: do you have any software firewalls installed on the venue server machine or your home one?  If so, try turning them off (especially one at home) and then try testing again.  If this solves the problem, you will need to open up port 80 in that firewall. 
  
  Hope we can figure this out,
  Adam
  
   
• 10 สิงหาคม 2549 18:06

   

   
  

  0

  Hi Adam,

  It is a bit strange. I thought having the firewall turned on in my notebook @ home may be the problem. But once I turned off the firewall and opened port 80 I still get to see the Local venue only when I connect to the venue service with the router's external ip address. I have disabled the firewalls on all the comp's I am testing and opened port 80 as well. Venue service address's are correctly configured. I am confident port forwarding works becasuse even within my LAN if I point the venue service address to http://router address/venue service, I am able to see the venue and the participants correctly but once I step out of the LAN ( my lab) and connect thru a computer on a different machine (different subnet) I get to see only the local venue. Man this  is driving me crazy !

   
• 10 สิงหาคม 2549 20:24

   

   
  

  0
  Dear Karthik,
  
  That does sound frustrating!  It looks to me like you do have everything properly configured, especially if you are able to access it in your LAN by typing in http://routeraddress/venueservice.  My best guess is there is something within your university's/corporation's LAN that is blocking your connection attempt on its way to your router.  One of their firewalls might not allow port 80 traffic in to the network, or diverts it some other machine first...
  
  Maybe Jason has a better idea (crosses his fingers...)
  
  Sorry,
  Adam
  
   
• 10 สิงหาคม 2549 21:03

   

   
  

  0
  Hey guys,
   looks like it is something with the university's policy, because when i tried to ping the router's address, the response was a request timed out. I have mailed my admin. Let me wait and see.until then i will have my fingers crossed.
  
   
• 13 สิงหาคม 2549 21:24

   

   
  

  0

  Karthik,

  Can I ask what university you're with?

   
• 13 สิงหาคม 2549 22:36

   

   
  

  0
  
  
  
   
• 10 กันยายน 2549 18:49

   

   
  

  0

  Dear Adam:

  I find this forum a little bit empty and without response.

  I belong to a university in Guatemala,  Galileo University, adn we are current license holders for ALL Microsoft's packages.  We started testing CXP because of its potential in education.   Recently I posted a help request without success or replies at all.

  I am encountering the same problem posted by Karthik.   I've done the correct hook up,  installed the Venue Service in a Win 2003 server machine,  which is located inside a subnet 192.168.15.xxx  and mapped to the outrside world via NAT.  We can connect properly within the subnet suscribers, but when we try to access from another subnet, such as 192.168.18.xxx we can get to the venue service properly but we get no connection.   As I understand by reading this posts,  I must "forward port 80",  and this is the part we do not know how to do.   Could you point us to some information on how to "forwarad the port 80 so we can connect among ALL subnets ?

  Is it our Wemaster in cahrge of all router programming the one that most do the "port forwarding" ?

  Please help us with some advice.

   

  Thanks.  Mike Aparicio   MediaLab director Galileo University Guatemala.

   
• 11 กันยายน 2549 13:14

   

   
  

  0
  Dear Mike,
  
  Sorry no one has been getting back to you.  The guys at Microsoft must be pretty busy right now.
  
  Ok, first of all, let me make sure I understand your problem:  you have created a venue using the venue service on a Windows 2003 server inside your 192.168.15.xxx subnet.  Any machine inside that subnet can connect to the venue just fine and conference with each other.  On any computer in any other subnet (like your 192.168.18.xxx subnet), you can see the venue, but when you connect to it, you cannot see any other users.  Is this a correct understanding?
  
  If this is the case, then forwarding port 80 is not an issue for you.  The venue just needs port 80 (the same port HTTP uses) to be seen by anyone trying to connect to it.  If you can see the venue (even if you can't connect with anyone), then port 80 is already open :)
  
  Basically, the venue service is nothing more than an online listing of meeting places, kind of like an address book -- it tells you where to go to meet someone.  All of the meetings themselves take place on a group IP address.  When you click on a venue, your computer joins that group IP address which lets you conference with other people by sending and receiving data on that IP address.  This is how multicasting works -- you don't worry about your local IP address (192.168.xxx.xxx), but instead just use the group address which is shared by everyone in the venue. 
  
  If you do not have multicast enabled (and a vast majority of networks do not), then you will not be able to see anyone else that is using that group IP address, unless you are on the same subnet (if you connected two machines in your 192.168.18.xxx subnet to the venue, they should be able to see each other, even if they can't see any computers from the 192.168.15.xxx subnet).  Luckily, this is not a complete problem.  To resolve the issue, you can use the Reflector service. 
  
  The Reflector works by allowing everyone to connect to a central server which shares messages for everyone.  Each computer connected to the Reflector sends all of its data to the server, which then forwards it to all the other computers connected to it.  This lets everyone use CXP without needing to use a multicast group IP address.  You can install the Reflector anywhere, but it has to be accessed by it's external (public) IP address.  If you install it behind a router (such as on your 192.168.15.xxx) subnet, then on the router controlling the subnet, you will need to forward ports 8083 (and probably ports 5004/5005 and 7004/7005 to allow traffic to flow) to the machine running the Reflector (this is the same as needing to forward port 80 to the machine hosting the venue service).  Forwarding ports is set within the routers, so you will need to have whoever runs your network connect to the specific router and choose to forward the port to the machine you want (I hope this resolves that issue for you).  Once ports are forwarded, all you have to do is set each client to connect to the public IP address of that subnet's router and you should be good to go.
  
  At this point, you might run into some more problems since you are running everything behind routers.  To communicate across subnets (even using unicast with the Reflector), you might need to open up ports 7004/7005 in every router to allow all unicast traffic to flow through.  I might be wrong, but I think this requires Cisco routers (or equivalent ones).  If you are using simple home routers (like those by Netgear, D-Link, etc.) you will only be able to use CXP on one machine behind each router since you cannot "open" ports on these routers, but instead need to forward 7004/7005 to the machine using CXP (and port forwarding can only be done to one computer on the subnet).  You could also try port triggering with ports 7004/7005 (also set inside the router) which allows any computer to use those ports.  I believe some of the guys at Microsoft have had success with port triggering, but I've never tried.  A future version of the Reflector shouldn't have this problem (clients should be able to use CXP without any port forwarding or triggering on their routers), but this probably won't be ready for a little while.  It is something I'm working on as a pet project, but I don't have any time to devote to it right now.
  
  I hope all of this helps, and if you have any more questions, just let us know!
  
  Good luck,
  Adam
  
  
  
   
• 13 กันยายน 2549 14:40

   

   
  

  0

  The only thing I would like to add to Adam's post is that when choosing where to install a reflector, you want to put it on the multicast cloud with the largest number of clients, so that you have the fewest number of unicast clients.  Otherwise, just about everything else Adam says is correct.  I think the unicast clients only need 8083 and 5004/5005.  The reflector itself is the only one using 7004/7005 (I think, but I always have trouble remembering this detail).  And that is so it can filter its own data.

  And yes, I'm always busy.  :-)

  JVE

   
• 13 กันยายน 2549 17:40

   

   
  

  0
  Dear Jason,
  
  Thanks for clearing up the port information.  Thinking about it again, you are right:  all of the sender and receiver sockets only send and listen on 5004 (for RTP data) and 5005 (for RTCP data), regardless of whether they are using unicast or multicast, so they don't need ports 7004/7005.  And good point about the placement of the reflector -- I didn't think of that.
  
  Adam