Contact us
HOME
[BLOG #4] GeoDNS for Cisco UC
Connecting Mobile and Remote Access (MRA) and VNPLess via Expressway B2B Calls
Tags: CISCO  collaboration  CUCM  B2B  cloud  CMR  express way  MRA 
Once you start moving to larger telepresence and collaboration deployments involving audio and video, the question of geographical distribution becomes important. This is even more important once you start communicating with people outside of the enterprise firewall, be it either mobile employees or external companies and partners. In this article, we want to look at two things specifically: Users using Mobile and Remote Access (MRA), and connecting VNPLess via Expressaway B2B Calls.
Let's first define our goals here:
1.) We want to deliver the highest quality to users, both in video and audio
2.) We want to minimise latency because it impacts user experience, and
3.) We want this process to be dynamic, so it should react to the location of the user

However, for our purposes we have one disadvantage: we don't have the cloud infrastructure and the custom client advantage that WebEx has. WebEx measures the quality to multiple distribution centres (DCs) before making the connection and thus ensures a premium experience.

The solution becomes even more important if we use the same domain across multiple regions. If cisco.com or frink.at is used on both a cluster in the Americas and in Europe, how do we make sure that the US-based employees don’t connect across continents? This would significantly impact user experience.

Neither Jabber nor video units (Cisco or others) currently do this. It turns out that we can –at least for inbound calls and registrations- make use of a GeoDNS service. I hear what you are saying though: “I already use a DNS service which does not offer GeoDNS and besides, this is too expensive.”
Nevertheless, those issues are quite easily solvable. Let's first look at how both situations use DNS:

(1) Jabber / Phone / Telepresence MRA
All clients using MRA will look for the _collab-edge._tls SRV record to discover Expressway. So, when you log in with , Jabber will look for _collab-edge._tls.domain.com

(2) B2B Calling
B2B calling uses the domain as well, using either
_sip._tcp
_sips._tcp
_sip._tls
_h323ls._tcp
...
and so on.
But once again, it is all DNS SRV records. Let’s make up our plan: We want to change as little as possible our existing DNS infrastructure and we don’t want this to be too costly.

One of the reasons GeoDNS might be a problem for a deployment is that the existing DNS provider does not offer GeoDNS services. Changing all DNS zones might be too expensive or more often just too risky and not something a company wants to do for a single project.

Fortunately, we can still phase in some GeoDNS magic without having to change our DNS provider.
The solution is to create a separate sub-zone which we delegate to the GeoDNS provider. For example, we might currently use the domain frink.at for our Expressway services. We will then create a separate zone called geodns.frink.at and delegate it to our GeoDNS provider. Thus, our SRV records remain in the main zone (e.g. collab-edge._ls.frink.at), but now we point them to expway01.geodns.frink.at. This way, the actual resolution to an IP address will use the GeoDNS Service.

The second question was the question of price. Here the cloud comes to our rescue. Multiple cloud providers offer cheap GeoDNS services which we can leverage, one of them being Amazon Web Services (AWS).

In our next article we will look at implementing GeoDNS using Amazon AWS. We will also take a look at the different options we have there to improve reliability and performance, especially redundancy and health checks.
back to FRINK Magazine
Editorial Team: Bernhard Albler, Manon Pierre
Image source: http://goo.gl/OQMKbB