Outbound Call Routing Using Geo-Specific Dial Plan

Introduction

The Cisco Meeting Server is often deployed in a geographically dispersed cluster to provide resilience and scalability. One of the benefits of this is that the Spaces exist throughout the cluster. This means that, with appropriate dial plan rules within your call control platform, users in different locations can dial the same Space URI and the call will be routed to their local CMS node. The CMS cluster will then seamlessly cascade this call across the nodes as appropriate. In this way, callers in, say, Europe will hit the Europe node and callers in Asia will hit the Asia node, but they will all be in the same Space.

This document describes how it is possible to achieve similarly dispersed and cascaded calls for outbound calls as well; i.e., when dialling to participants from the VQ Conference Manager (VQCM) Activity view, forcing the call to be established from the called party’s local CMS node.

It is assumed the reader is familiar with REST API concepts in general and the CMS API in particular. The reference material for creating the example in this document was the Cisco API document, “Cisco Meeting Server Release 2.8 API Reference Guide” available from cisco.com.

This is an issue because of the way VQCM communicates with the CMS cluster. Specifically, VQCM sends all of its commands via the CMS API to only one node. When the cluster is added to VQCM, it is necessary to prioritise the nodes in the cluster. The highest priority node will typically be the one with the lowest network latency ensuring API commands reach it in as little time as possible. If communications are lost to this node due to some network error or the node server going down, VQCM will instead send API commands to the next-highest priority node.

The CMS cluster mechanisms ensure that API commands sent to any node are shared appropriately across the cluster. But all outbound calls will be governed by the outbound dial rules. The rules have to be set up directly on the CMS and are beyond the scope of VQCM. In the simplest case, you would set up a “match all” rule and route these calls to the call control platform. Now, this outbound dial rule is global across the cluster, so this means an outbound call placed via VQCM will always be established from the node the API command hits.

Thus:

If the Operator is in London and the nearest CMS node is also in London, if they establish a call from the VQCM Activity view, the call will always be established and routed from the London CMS node, even if the called party is in another region and even if there is a closer CMS node to them.

To force the call to be established from CMS nodes local to the called party, it is necessary to create location-specific outbound rules on the CMS cluster. Of course, this is dependent on there being a location-specific dial-plan. For example, you might have all London endpoints given the prefix 44 in their number and all Hong Kong endpoints have the prefix 852. You might also have location codes in alpha-numeric SIP URIs. In the following example, the latter is used.

Creating location-specific dial rules

To create location-specific dial rules, it is necessary to set them via the CMS API. In the following example, Postman is used to issue the API commands to a CMS cluster consisting of two call bridges: core-1 and core-2.

Assume core-1 is located in the UK and core-2 is in the US. The dial plan in this example stipulates that all UK endpoints have the SIP domain, pysip-uk.com and all US endpoints have the domain, pysip-us.com.

All things within the CMS API, Spaces, users, calls, etc., are referenced by a GUID. This is a 128-bit number generated in a way that makes it hugely likely to be globally unique.

To set the dial rules, first establish the GUIDs of the CMS nodes. This is done using a GET on the callBridges node:

In this example, this yielded the following result:

We then set up an outbound rule that only applies to the UK CMS node. This is core-1 in this example and the rule simply matches the SIP domain pysip-uk.com. This is created by a POST to the outboundDialPlanRules node:

with the body:

The important fields are the sipProxy which will be the local call control device (i.e., the local CUCM subscriber or Expressway node) and scope. This MUST be set to callBridge. You then specify the callBridge ID discovered in the previous step.

The other fields will be set according to your local environment and it is recommended you follow Cisco deployment guides to set these appropriately.

This step is repeated on core-2 but using pysip-us.com as the domain and core-2’s GUID discovered in the first step; i.e., a second POST on the outboundDialPlanRules node.

You can check the results on the CMS web admin. Go to Configuration > Outbound calls:

And now, calls placed on the VQCM Activity view to endpoints on the pysip-uk domain will go out via core-1 and calls to pysip-us will go out via core-2:

Getting help

Please do not hesitate to contact our support team at support@vqcomms.com for assistance.