Livemeeting: video doesn't work RRS feed

  • Question

  • I am running OCS 2007 R2 Std. with a FE, Edge, CWA and ISA proxy. Everything works but in Livemeeting 2007, outside clients cannot get any video. This is the error:

    Voice and Video Error Information
    Your audio and/or video session was unexpectedly disconnected.

    Action required: Please rejoin audio and/or video.

    More details for technical support:
    Message Category: 2 (kNetworkError)
    Message Code: 8 (kMediaConnectivityFailure)
    Root Cause Error: 0x00000000
    Root Cause Component: kNetwork
    Audio Input Device: Microphone (3- Microsoft LifeCam VX-3000.)
    Audio Output Device: Speakers (SoundMAX Integrated Digital HD Audio)
    Video Input Device: Microsoft LifeCam VX-3000
    Audio Muted: Yes
    Media State: (47,2,2,2,0,0,Connected)
    AvMcu Uri: sip:ocspool.company.com:5063;transport=tls
    Avmcu Reachable: Yes
    Acp Reachable: No
    Diagnostics Information:

    ocspool.company.com is the ocs pool name and I kept the same name for both internal and external connection using a split DNS setup.

    Looking at the traffic on my firewall I noticed something strange happening:

    The edge server, on the AV interface, is trying to connect to the client's private IP: 

        Aug 27 09:16:22       DMZ ->       UDP
    Aug 27 09:16:22       DMZ ->       UDP

    Where is the natted AV interface on the edge server, is the private IP of the remote client. I have no idea where is coming from since such ip or subnet doesn't exist on either my network or the remote site.

    The av fqdn (av.company.com) is resolved by the edge server to its public IP as required by the documentation. In the AV interface properties the "External IP address is translated by NAT" option is checked.

    I just found out taht the is a Virtual Box vistual adapter installed on the client machine. So it looks like the AV server is trying to connect to all the client's private IPs.

    • Edited by MaxNJI Thursday, August 27, 2009 2:27 PM
    Thursday, August 27, 2009 2:12 PM

All replies

  • Interesting development:

    The client who is having this issue is running Windows 7 Ultimate (RTM version). To eliminate that as a factor, we tried an XP virtual machine (running inside W7) with the virtual interface bridged to the same private subnet as Windows 7 ( To my surprise, the video connected and worked without issues.

    I checked the traffic on my firewall and this is what I saw:

               Aug 27 10:34:12            DMZ   ->              UDP
               Aug 27 10:34:12            DMZ   ->            x.y.z.249:3478            UDP

    Where is the natted AV interface on the edge server, is private IP of the XP client and x.y.z.249 is the public IP of the client.

    In this case it looks like the AV server is trying to use the private IP of the client first, then the public. This leads me to believe that the Livemeeting client is not working properly on Windows 7 for some reason.

    Has anybody tried to use livemeeting client on Windows 7?
    • Edited by MaxNJI Thursday, August 27, 2009 3:09 PM
    Thursday, August 27, 2009 3:04 PM
  • Yes I currently have clients deployed with Windows 7 RTM (x86 and x64) without issue.  I believe the issue is your NAT for the A/V edge.  Please do the following:

    - From a command prompt on your AV edge server ping the external DNS name of the AV edge server, does it return the public IP? 

    If not, you will have to put a hosts file entry on the AV Edge server with the external DNS name and the public IP.  The problem here is that the AV edge server is telling the client to connect back to it with a private IP address which is not routable from the client's network. 

    Please let me know if this works.
    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Thursday, August 27, 2009 3:10 PM
  • More help can be found here:

    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Thursday, August 27, 2009 3:11 PM
  • Thanks for the reply Mark. Yes I have edited the host file on the edge server to point the av name to the public fqdn.

    I have one question that might be related: on the edge server, on which interface shoud I enter the default gateway? I have 4 interfaces on the server: 3 (av, access and web. conf.) on the dmz and one internal. I crrently have set the gateway only on the access interface pointint to the DMZ gateway.


    Thursday, August 27, 2009 4:44 PM
  • The default gateway should be on all external interfaces.  I know this is contrary to everything you have known about multiple interfaces but trust me on this one!

    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Thursday, August 27, 2009 5:17 PM
  • Thanks again for the help. I'm making some progress. I set the default gateway on the AV interface instead of the Edge Access one. That did the trick and now I have video and audio going back and forth in Livemeeting. Now the firewall logs show:

      Aug 27 15:44:49   DMZ ->   x.y.z.249:3478   UDP
      Aug 27 15:44:49   DMZ ->   UDP
      Aug 27 15:44:49   DMZ ->   UDP

    I'm still not sure why the AV server would try to connect to the client's private IPs before finally using the public IP, but at least it gets there and it works.

    The problem now is that with this chage Desktop Sharing using external CWA is not working anymore. Again if I check the firewall logs I see the same behavior as before: The AV server tries to connect to the client's private IPs and then stops.

    I even tried to just use 2 interface (1 int. and 1 ext.) and assign the 3 external IPs to the external interface, but that didn't make any difference.

    At least I got livemeeting fully functional, now I have to figure out how to get CWA desktop sharing working again without breaking anything else in the process. Wish me luck ;)


    Thursday, August 27, 2009 8:02 PM
  • Good luck, what server do you have CWA on?
    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Thursday, August 27, 2009 8:13 PM
  • I have a dedicated server in the internal lan, joined to the domain with the appropriate cname records on the public dns as required by the documentation.
    Thursday, August 27, 2009 8:15 PM
  • Well that doesnt make much sense.  Changing the gateway on a completely unrelated server should have nothing to do with CWA on an internal server.  Are you using ISA?  Does regular desktop sharing work?
    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Thursday, August 27, 2009 8:28 PM
  • We've seen weird issues before with more than two NICS on the edge server caused by the edge server going out the wrong interface. The easiest way to get around this is drop down to two physical interfaces, one with the DMZ/External IP addresses and one with the Internal Addresses. You place the gateway on the DMZ/External address and make sure the internal interface has routes to all interfaces using the command line so it uses that interface to talk internally.

    I ran into nearly the same issue where I could switch gateways between A/V and Access edge, but it would break either or. In my situation we were dealing with federated audio issues, changing the gateway to the A/V Physical interface would allow audio/video but break IM... Very strange activity.

    I am making an edit to include this link which was posted recently that somewhat corrects my last statement:


    Randy Wintle | MCTS: UC Voice Specialization | WinXnet Inc
    Thursday, August 27, 2009 11:17 PM
  • Yes, I'm using ISA 2006 SP1 for publishing the FE web components and the CWA server and as far as I can see on the ISA logs, that part works. Regular IM through CWA works. The problem is Desktop Sharing from CWA (which apparently is handled by the AV server). Desktop sharing using Communicator Client works both ways inside and outside.

    Anyway after further testing it looks like the issue is only present when using with the same Windows 7 external client I was having problems with when I started this trhread. I tried 2 other XP clients on the same remote network and CWA desktop sharing works there as well as Livemeeting with audio and video.

    The problem when using the W7 client is the same I was having originally with Livemeeting AV. When I look at the traffic on my firewall: after the initial connection the AV server tries to connect to the remote client on UDP 3478 using the client's natted IP. If I watch the same traffic when I use the XP client, I can see that the AV server first tries the natted ip of the client, then the public routable IP and at that point the desktop sharing starts.

    There must be something on this W7 box that is interfering because the XP clients are in the same subnet and go through the same firewall and have the same rules applied to them. I just can't understand why when using Livemeeting the AV server is able to establish the connection with this W7 client (usilng the same UDP 3478 port), but when it comes to CWA desktop sharing it just refuses to use the routable IP.

    I'll install a Windows 7 on anothe machine on that network and try it again. I'll post the results.

    Friday, August 28, 2009 3:44 PM
  • I tried CWA desktop sharing on another Windows 7 machine with the same results, the AV server doesn't connect to the routable IP of the client, but just the natted IP. Livemeeting works fine with audio and video both ways.

    On Windows XP clients everything works regardless. This leads me to conclude that Windows 7 client behind nat behave differently.
    Monday, August 31, 2009 1:13 PM