Get CXP to work in hosted environment RRS feed

  • Question

  • Hi all

    We are in the process of implementing CXP (preferrably 4.0) in an environment where the servers are centrally published (from a data center) and where the conference users are connecting (over internet 1) from home. The idea is for them to be able to get education at a distance, since they are all people with all sorts of disabilities.

    The setup we are using:

    • All servers are on Virtual Server 2005 R2 SP1 Beta2
    • Virtual servers are on dedicated IP addresses, domain members, Windows 2003 R2 Standard Ed. and both virtual servers are using the same physical network interface
    • Everything is published through single ISA Server 2006 Standard Ed.
    • Venue service is accessible
    • Reflector service is accessible (two people are listed in the reflector service user list)
    • People can enter the created venue, they however cannot see each other.
    • Port 80 is published (forwarded) to the venue service
    • Ports 8083 - 5004-5005 7004-7005 are forwarded to the reflector service
    • Same issues when reflector service is running on the venue server as well as on a different server (virtual server)

    The main issue is that two people can enter the same venue, are registered as user with the venue service, but cannot see each other.

    Is there an issue with virtual server?

    Could there be another issue?


    I look forward to hearing from any of you.


    Thanx in advance!

    Frank Verduin

    • Moved by Jundan Wu Thursday, April 28, 2011 8:59 PM (From:Reflector Service)
    Thursday, October 26, 2006 2:45 PM


All replies

  • Hi Frank,

    What a complicated setup (and not one we have tested)!  Maybe Adam will have some good ideas here.  In the mean time...

    It's no big surprise that Venue Service is accessible.  It is a regular old HTTP call.

    Reflector Service, on the other hand, uses UDP.  Do you have UDP ports 5004/5005 enabled in the ISA server (and TCP 8083)?  I don't think you will need 7004/7005 enabled in the firewall because it sounds like you don't actually have a multicast cloud that you are worried about sending and receiving on.  If it would be easy for testing purposes, you might try pulling the ISA server out completely to see if that helps.

    Likewise, if you can remove Virtual Server and just try Reflector on a regular old machine, that might help narrow it down also.

    Are there any interesting events in the event logs (on the Reflector and the clients)?  What do the performance counters say (on the Reflector and the clients)?  It sounds like the clients are at least able to complete the join request on port 8083 before things start to break.

    When all else fails, you can do a network sniff and see where the data is going...

    By the way, thanks for including so much information and having it so organized.  Sorry if my suggestions aren't that helpful.


    Thursday, October 26, 2006 3:08 PM
  • Hi Jason

    Thanks for your quick response. I just have changed the setup a little bit by allowing UDP ports for receive-send instead of receive only. This did not help. Then I installed another server within the Virtual Server environment, which is hosted on a second Virtual Server host. Therefore, traffic has to go through the network switch in order for the clients to see each other. Now when I tried to started the CXP client on this new server, I was able to connect to the venue, without using a reflector of course, and I was also able to see the connection from outside (through the reflector). On the outside I just saw myself. Then a collegue entered the same venue (from outside), he could just see himself and from the client inside I could see all three of us.

    I have no clue what should be configured on the reflector, to allow outgoing traffic I expect to the internet based clients, in order to view all participants in the venue.

    Any ideas? Because the servers are hosted in a data center, I can't remove ISA server from the configuration, nor can I add a physical server to perform reflector services. The event logs are giving no answers (just connect - disconnect informational messages).

    How is the reflector service handling seperate requests coming in from a single IP address (like multiple connections through the same NAT device )?

    Thanks again!



    Friday, October 27, 2006 10:07 AM
  • Dear Frank,

    Sorry to hear you are having problems.  Reflector can be a little tricky to set up sometimes.

    I have one quick question for you before we try anything else:  the people connecting from the outside -- are they behind a router/firewall of their own?  If they are, it is most likely that these routers need to have the right ports (5004/5005 and I think 8083) opened to receive packets from the Reflector service.  Since the routers have NAT translating (a way to map internal addresses to the external one and vise-versa), they can communicate fine TO the reflector, but by default, they cannot receive FROM it.  We ran into this a bunch when we were trying to set up CXP for our students to use off campus -- everyone could connect to the reflector just fine, but no one could see anyone else.

    If the clients are behind personal routers, then if they forward the ports 5004/5005 and 8083 to their machines, they should be able to see everyone just fine.  Hopefully there aren't any other firewalls between their machines and your servers.

    Hope this helps!

    Friday, October 27, 2006 1:12 PM
  • Hi Adam


    I will try to get this working in my home environment by opening ports 5004-5005 and 8083 from my firewall towards my client inside (port forwarding). Even if this works, this means that NAT is only supported for just one client on the inside, and these clients should have a specific opening of ports configured. Most of the simple DSL routers people use at home do not offer these kind of configurations (mine does however ).. I will get back to you with the results.

    If this is the case, I have some disappointing news for our customer I am afraid...

    Get back to you soon!

    Thanks for your help!


    Friday, October 27, 2006 1:51 PM
  • Hi All

    I have forwarded the ports inwards toward my client running ConfXP. This works. (also for my colleagues). We dit experience troubles(spontaneous siconnects, freezes etc) using the same reflector service (I did have two of those installed). When we were both running on a seperate reflector, things went best. Upload speed requirements are very high however.

    This afternoon we will be testing with four people together, all four from internet using reflector services. Hopefully we'll get the right results. On the other hand, I am very confused about the need for inbound port forwarding on the CXP clients. If the connection would stay open (over tcp 8083), the inboudn connection through NAT is also open for as long as the connection lasts. Is there a reason why the connection between reflector service and the client has to be set up every time? Since the reflector service is used, I expect all traffic to flow through this service. It would be so much easier to have the connections open until time-out (say five minutes) using keep alives, in order for the inbound connections to be handled without the port forwarding. Another advantage would be that more participants can use the same external IP (and NAT).

    I will be in Seattle a week from Sunday, (visiting SQL PASS). Is it possible to arrange a meeting to discuss these kinds of things with you guys from MSR? This would be very much appreciated. Let me know please.

    Regards, Frank

    Friday, November 3, 2006 1:46 PM
  • Frank,

    We'd be happy to meet you (schedules permitting).  Why don't we follow this up on email - you can reach me as todd.needham@microsoft.com.


    Friday, November 3, 2006 5:24 PM
  • Dear Frank,

    It is good to hear that you've gotten it to work, at least in a controlled environment.

    As for the forwarding of ports, all of the ports do something different.  TCP 8083 is used to communication with the reistration service of the reflector -- this is used by the reflector to maintain its list of current participants.  The connection does not stay open because this registration only happens when a participant joins and when they leave (I could be wrong though -- it's been awhile since I've looked through the registration code).  All the data itself is pushed through ports 5004/5005 (5004 for RTCP participant status data and 5005 for RTP data between the capabilities).  These are the ports that would need to be kept open for connection.  They are also the reason that only one participant can currently use CXP from an external IP address -- all data must be pushed to these ports.

    You are onto something I have been playing with a little in my spare time -- UDP Punching.  Holes in NAT firewalls are kept open as long as data is intermittently passed through them (whether CXP data or "keep alive" packets), but right now CXP doesn't use this functionality.  I have been trying to implement it and have had some success, but right now I've only been successful in getting one machine behind the router to have connectivity without opening ports (this is a because all registration and indexing is done by IP address, so I need to find a way to index by something else).  I think UDP punching could be useful, but unforunately, I don't have much time to work on it.

    Friday, November 3, 2006 5:57 PM
  • "Another advantage would be that more participants can use the same external IP (and NAT)."

    Hi Frank

    Be aware that the reflector uses the source IP address of the UDP packets sent to it - to track which participant the packets belong to. If you did manage to find away around your port forwarding issue you would still have the problem that the reflector has no means of differentiating between participants who share the same source address.

    For example if two participants behind your NAT join a session and then one leaves the session the reflector will terminate the session for both participants.


    Michael W


    Friday, November 3, 2006 11:55 PM