Comminicator Calls Fail on Edge RRS feed

  • Question

  • Ok. I am starting to get frustrated. I used the edge server planning util to plan my edge deployment. I have an external NIC which has my external IP addresses on it, and I have my intneral NIC with my intnernal IP address on it. I have external DNS A records setup for ocs. (access edge), webcon. (Web Conf), and av. (A/V). Each service has a different external IP address. x.x.x.141 for access edge, x.x.x.142 for web conf, x.x.x.143 for av. I have external SRV records for _sip._tcp pointing to port 443 of ocs, _sipfederationtls._tcp pointing to 5061 of ocs, I have _sipexternal._tcp pointing to 5061 of ocs, and _sipinternal._tcp pointing to 5061 of ocs. I also have an a record, sip. pointing to the access edge ip address.

    I have a pretty simple setup. 1 edge server, 1 internal server. All on OCS 2007 R2 Enterprise. Internal works great. Audio video, everything. Outside and going through the edge works with IM, but not with audio or video if I'm at home going through my linksys router.

    Now here is the weird thing. When I use my laptop and connect via my verizon card, I get a public IP address and calls video and audio work just fine. I initially thought this was becuase I was natting on my server side. I am no longer natting, my edge is directly connected to the internet. I'm getting the same behavior. It will connect fine with IM. When I initiate a call, it says connecting call for about 5 seconds and then says call was disconnected. For troubleshooting sake, I have no firewalls enabled on either server or client. I get no errors in the error log.

    Now if anyone has any idea why this is acting this way please post. I'm starting to get deperate here. How does communicator know where the A/V service is? how does it know to point to av.copany.com when connecting? Do I have something messed up in my DNS?

    Thanx in advance. -Jason
    Wednesday, June 3, 2009 10:11 PM

All replies

  • First off, you really should be using sip.xxx.com for your Access Edge FQDN and not ocs.  This is a best practice approach and probably not what is causing your issue.

    Also, the Web Conferencing and A/V FQDNs are passed in-band from the Edge server to client during the sign-in process.  This is why only the Access Edge sip.domain.com address referenced via SRV records.  You still need external DNS A records for the webconf. and av. FQDNs so the client can correctly resolve the passed names to their public IP address.

    I'd recommend testing external access from more locations as it could be related to the Linksys router and/or setup you have at home.  Using your laptop from a few public Internet access locations should be sufficient to validate the setup.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, June 4, 2009 1:30 AM
  • Thank you for the reply Jeff. So far I have tried it though another router. A Cradlepoint with my verizon card plugged in. This setup gives me the same results. If you like, I will post screen shots of my edge config and DNS entries.

    This is what the call looks like. Not sure if this will help or not.

    This is the edge config.

    These are my internal edge settings.

    External DNS SRV records.

    External DNS A records.

    Internal DNS SRV records. Communications.domain.local is the name of the computer.

    Internal DNS A records.

    If you need any additional information please let me know. I will try from another router and see if it works but so far I'm 0 for 2.

    Thanx in advance. -Jason
    Thursday, June 4, 2009 7:19 PM
  • Does anyone have any ideas on this at all? I'm starting to pull my hair out.

    Monday, June 8, 2009 4:25 PM
  • This is a strange one for sure.  Is it possible to connect a workstatino with communicator to the same netowrk as the external Edge interface, but inside the external firewall?  Nine times of out ten the firewall is what causes these types of communications errors, so if you can completely eliminate it from the scenario that could help narrow things down.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Monday, June 8, 2009 11:36 PM
  • Thanks for the reply again Jeff. There isn't an external firewall on the edge at this point. I'm connecting directly to the internet with the external interface of the edge. As for the client side firewall, when I bypass the linksys router and connect directly to the internet with the client, it works just fine.

    I have actually contacted Microsoft regarding this. The gentleman that I talked to seemed to think that it was something on the client side router that wasn't being let through. So far I have experienced this issue with 3 different routers. A linksys, a netgear, and a cradlepoint. When my client computer has an internet IP address, it works, when it's behind a router, it doesn't work. Very weird. When I get a call back from microsoft, I will post the findings.

    Thanx. -Jason
    Tuesday, June 9, 2009 7:02 PM
  • Hi

    No errors in log files.
    Debug of the SIP signalling in the Front-End ?
    Result ?
    You should be able to track down the difference between behind router/not behind router since you are able to sign in.


    Wednesday, June 10, 2009 1:35 PM
  • Hi,

    We are setting up our edge server as well and do not succeed in getting the audio to flow, while SIP messaging obviously does work.  The situation is similar to the one described here.  We don't notice the issue of the router but simply can never get audio to work EXCEPT when we allow our internal users to fully traverse the firewall.  In that case the OC of the internal user seems to set up a peer-to-peer connection with the external user.  The internal user's OC client will always send out UDP packets in order to accomplish this.  When we block them, the audio call fails.    On the other hand we are also noticing that de mediation server tries to connect the AV edge server on the EXTERNAL interface, while all configuration is set for the internal interface.  The mediation server cannot even resolve the external av interface in DNS, but somehow still tries to connect to it...

    Any help is welcome :-)

    Tuesday, July 14, 2009 9:34 AM
  • I see the issue in the first post. They have 5062 listed as the port for the pool to talk to for av auth, and on the edge it is set to 5063, so that would be a problem.

    On the last post. can you give us more information. Are you doing NAT for your edge server? or does the edge have public  IP's? It sounds like  you may have 2 issues. so start with MOC to MOC calls with one being remote. Test it and take a trace if you see it talking to the edge server then that is good. But often times there are 3 things that cause AV to fail and it depends on if you are using NAT.

    Matt has a great blog about the major issues with setting up NAT for the edge.

    if that does not help be sure your ports are correct for the AV authentication service. I often see the wrong ports as pointed out above.
    Wednesday, July 15, 2009 12:54 PM
  • Hi Mitch,

    Thanks for your reply.  In the meantime I found the error, and I will make a seperate thread for it in order to inform others.  

    In short:  the problem was the routing on Windows 2008.  I was using multiple NICs, of which one was configured with a gateway.  Apparantly packets where going to the server, but the replies not leaving the server.  I needed to switch the routing behaviour of the NICs so that all packet transmissions would go over the NIC with the gateway. 

    See this post for more info:


    Thanks again for your kind reply,

    Best Regards
    Tuesday, August 4, 2009 6:58 AM
  • Wim,

    That is a common issue (multiple NIC and Dead Gateway Dectection) and I've covered the topic in this blog article:

    Also, similar routing issues can be seen when using multiple NICs on the Mediation server:

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, August 4, 2009 12:10 PM
  • Hi Jeff,

    I solved the issue a while ago, but did not have time to post it yet, but if I remember correctly your blog entries helped me on the way to find the solution.  So many thanks indeed!

    Best Regards
    Tuesday, August 4, 2009 12:13 PM