Branch office AV call routing RRS feed

  • Question

  • We have OCS deployed in our central London office with a correctly configured Edge Server. In addtition we have 2 Branch offices connected via a permanent VPN each end using ISA 2006. The Branch offices do not have any OCS infrastructure, everything goes via the London office.

    1. All IM chat works fine from anyone to anyone.
    2. Branch office to Head office AV calls are fine.
    3. External to Head office AV calls are fine
    4. External calls to Branch offices and vice-versa fail.

    I'm sure this is related to either DNS or IP routing thorough the network, I'm not seeing anything obvious on the ISA logs.

    It seems that an AV call from a Branch office sends traffic over the internet to the external IP of the Edge server. However other OCS traffic goes over the VPN to the internal Front End server. Is this what's causing the problem?



    Wednesday, January 16, 2008 12:41 PM

All replies

  • Dear Tim,


    When Office Communicator calls another user in a normal telephone call, the connection is peer-to-peer, over the network, without passing by a the central OCS server.    Probably your firwall is configured NOT to route between the external VPN subnets, and the call will not go through.  Only communications to and from the central site are allowed, and hence the branch office can call the main site.


    The only exception to this rule is in a conference call.  As soon as you have 3 users in one conference, the central OCS server is used to route all traffic.  Without any changes to your environment this type of call should work.  You can test this easily by setting up a call between two users on the main site, and then inviting two other callers located on two of the branch offices connected by VPN.


    When you change the routing in your firewall, everything should work.


    Best Regards



    Wednesday, January 16, 2008 1:19 PM
  • Thanks Wim,

    I have confirmed this as 3 way Communicator calls work but not 2 way, also Live meeting Audio works.

    So I think I need Communicator to know that it is 'inside' the network. At the moment some OCS traffic is passed directly to our FE Server using the private IP address whereas AV traffic is passed to the Edge Server using it's public interface.

    Do I need to configure communicator so that both it's internal and external server names resolve to the private address of the FE server in the main office?


    Friday, January 18, 2008 9:27 AM
  • Tim,


    Live Meeting is also OCS hosted and not peer-to-peer. Yes, you are correct, it appears to be DNS related. I assume that each office has their own IP subnet. Have you populated SRV records in the remote office DNS? I would check this and add the appropriate SRV and A records to guide your clients accross the VPN.


    If that doesn't work, let me know more about your IP setup in those offices.



    Friday, January 18, 2008 1:31 PM
  • All the internal DNS is common across all sites, AD integrated DNS.


    Internally there is a DNS for;

    • Front End OCS
    • Edge Server Internal Interface
    • sip.xxx.co.uk resolves to external ip of the Edge server
    • _sip [443] SRV points to external sip.xxx.co.uk
    • _sipfederationtls [5061] SRV points to sip.xxx.co.uk record
    • _sipinternaldns [5061] SRV points to internal interface of Front End OCS

    Externally we have;

    • sip.xxx.co.uk resolves to 87.xxx.xx.250 Access Edge
    • ocswc.xxx.co.uk resolves to 87.xxx.xx.251 Web conferncing
    • ocsav.xxx.co.uk resolves to 87.xxx.xx.252 A/V
    • ocs.xxx.co.uk resolves to 87.xxx.xx.238 reverse proxy, (thorough ISA)
    • _sipfederationtls._tcp.xxx.co.uk [5061] SRV points to sip.xxx.co.uk
    • _sip._tls.xxx.co.uk [443] SRV points to sip.xxx.co.uk

    The London office is the central site which has 2 branch offices connected to it with ISA Site-Site VPN links. There is full routing and no restriction on traffic flow between the sites.

    There are no validation issues on the OCS FE server.


    Looking at the DNS above I can't remember why I added the sip.xxx.co.uk external record to the internal DNS but it would have been to solve some particular problem.





    Friday, January 18, 2008 3:43 PM
  • Hi Tim,

    Did you ever resolve your issue?
    Thursday, February 12, 2009 7:45 AM
  • No not really although I have shelved this for a while. I use a Polycom IP communicator phone outside the firewall at the Branch office for voice calls now so the traffic always avoids the VPN tunnel.

    Ideally I need to setup so all communicator traffic passes over the internet through head office edge server, not through the vpn. This I expect I can achieve with the careful use of DNS and certificates. If I crack it I'll report back to this thread.
    Friday, February 13, 2009 1:21 PM
  • You said

    >It seems that an AV call from a Branch office sends traffic over the internet to the external IP of the Edge server. However other OCS traffic goes over the VPN to the internal Front >End server. Is this what's causing the problem?

    What makes you think so? If so, that would indeed be your problem however I can hardly imagine that MOC can split voice and signalling traffic that way.

    The best thing to do here is activated tracing on the Frontend / Edge and see how call setup works out. I had an unsupported edge scenario in R1 (no public IPs on the edge) and that way I could clearly see that  when setting up calls between a machine on the externa and the internal side, the two would try to send media directly to each other which didn't work due to routing limitations and hence the call never worked out (signalling passed through just fine).

    And I take it each branch has direct Internet access only only traffic meant for another branch and the central office is supposed to pass through the VPN tunnel, correct?

    Also, you didn't write if branch <-> branch calls work.. do they?

    Also.. where's your _sipinternaltls_tcp_.xxx.co.uk record (the one for automatic internal signing)? You wrote something about _sinternaldns (tcp?).. did you mean to write _sipinternaltls_tcp_?
    Saturday, February 14, 2009 3:49 PM
  • Sorry I did mean _sipinternaltls_tcp.

    In an ISA-ISA site to site setup the client DNS queries are resolved by the 'internal' DNS servers, hence communicator wanting to go straight through the VPN tunnel directly to the private IP interface of the FE server. All external traffic goes out to the internet directly using the local default gateway, (it doesn't pass through the VPN and out through the head office for example).

    I'm not totally sure that I'm right but I feel that if the communicator traffic used the external dns records and passed directly over the internet to the Edge Server at Head office, avoiding the VPN tunnel, then I would not have these call failures.

    For instance could there be an instance where a branch office client tries to establish a call with a totally external client. The branch office client see's an external IP address so tries to communicate with it using the local default gateway, (as above). However the external client sees not the branch office clients external IP address but the address of the Head Office Edge server as, as far as it is concerned, this was where the call originated from.

    A greater mind may explain to me why I'm wrong and the call failures may be down to something else.

    Note the above doesn't apply with client VPN connections as in this case all internet traffic uses the remote default gateway.
    Sunday, February 15, 2009 1:19 PM
  • Tim,

    Well, after finding this thread again and mulling it over....
    You are right, it's definately a DNS puzzle. Your clients are going to automatically look for the following:

    1. SRV - _sipinternaltls._tcp.sipdomain
    2. SRV - _sipinternal._tcp.sipdomain
    3. SRV - _sip._tls.sipdomain
    4. A - sipinternal.sipdomain
    5. A - sipexternal.sipdomain

    So, we need a balance of DNS and GPO to get this to work. Assuming your internal DNS is syncing between internal sites, we can't easily make DNS entries for a site without having that entry affect everyone. For example, if we just leave #5 above for the remote sites, the local site won't find OCS locally.

    Let me know if this sounds reasonable based upon your environment... Remove the DNS records internally for OCS and use GPOs based upon the sites, or OUs if you have them broken down that way. This way the clients at the site where OCS is hosted get the internal FQDN for OCS, but the remote sites just get the external FQDN for the OCS server. Then, the remote sites will see the public IP and use the local sites connection to the Internet to get to OCS.

    I hope I'm clear enough on the situation and your environment to have this make sense.

    Jim Raymond - DynTek
    Friday, February 27, 2009 6:04 AM
  • Thanks Jim,

    What you describe is exactly the scenario. Unfortunately an ISA - ISA branch office site link is a fairly common and standard Microsoft solution.

    Your proposed solution looks like it could work, i.e. using a GPO to distribute the server details rather than DNS. I'll try it our over the next couple of days and report back.


    Friday, February 27, 2009 9:25 AM
  • I've now resolved this. When you have communicator users in a branch office linked back to the OCS via VPN and using internal DNS you have to manually configure their communicator so that they connect as external users, not using the internal DNS. I did this by creating a GPO forcing both the internal and external url to be fqdn.edgeserver:443 and the transport as TLS.
    This GPO is then linked to any Branch office Sites.

    Also noted far better call quality as no vpn payload.
    Sunday, May 10, 2009 4:38 AM