Posts Tagged ‘call-routing’
We had a great response in turnout to Josh’s vSeminar yesterday. Thanks to everyone who made it out, we certainly hope it was beneficial for you!
A few comments from attendees in the ET helped us realize that the next Voice vSeminar, this Friday covering Simplifying Globalization and Localization, might be best held at 4pET/1pPT, rather than the 6pET/3pPT that it was originally scheduled for. So we changed it.
So why a lecture on this topic? Well, every class that I have taught over the last few months has invariably had most students walking in with a printout of the 40+ page, 3-part series on Globalization, Localization, and Mapping the Global to Local Variant blogs that I posted here on this blog a bit back. They all seem to have the same thing to say: “Excellent post, now can you simplify it just a bit for me and can you also explain why we would want to do any of this?”. So to that end – I decided to take on the task of helping you understand not only how in a much simpler way, but possibly more importantly, the why of it all. Continue Reading
So let’s recap, we’ve discussed the how and why of Globalizing every Calling Party Number – and we recall that this occurs as the first step inside CUCM as the call arrives Inbound at any of our enterprise gateways. We’ve also taken a good look at Localizing each number – and we recall that this occurs as the last step inside the CUCM as the call leaves Outbound to each destination IP Phone. So it logically behooves us to next take a look at the task Cisco labels “Mapping Global Calling Party Numbers to their Local Variant”. Now this may sound a bit daunting or even just plain confusing, but rest assured that it isn’t, and it could probably even stand a naming refinement – in fact for the rest of this article I will simply refer to it as “Call History Dialing” since that is more properly what we are wishing to perform.
In the last installment of this series, we took a brief look at the history of the ITU-T’s E.164 recommendation, as well as, hopefully, an understanding as to why we might want to begin building dial plans in CUCM versions 7 and later in a truly Globalized format, and we took a look at the basic configuration to do so. In this post we will look at the next phase in the process, namely Localization.
While having been covered before, there seems to still be quite a lot of confusion surrounding Cisco’s newest call routing additions and features in CUCM 7. These are best cleared up since they not only are completely fair game as testable topics for the CCIE Voice lab, but also since CUCM 8 is just about to FCS and includes a great deal of call routing enhancements of its own (such as policy-based call-routing and inter-cluster dynamic DN route building) which will only build on the complexity of CUCM 7’s call routing enhancements (I’ll blog on some of the new features of CUCM 8 another day if anyone is interested).
In this blog article I will first list the new call routing features, then explain why we might be interested in using them (which requires a bit of understanding of history that we will go over), next move on to how to configure them, and finally wrap up with some real world examples. This all might take a while to explain with accuracy and clarity, and therefore will be broken down into sections to assist the reader with an easier course of digestion and absorption. Also it should be noted that before we begin, we are only going to seek to understand the E.164 numbering recommendation in this blog article, that is – we will not go into the specifics of E.164 NUmber Mapping (a.k.a. ENUM) here – although I will cover that in a later blog article.
People constantly have troubles understanding the Gatekeeper-based call routing model. In this post, we are going to discuss the basic call-routing logic. Reader is assumed to understand the most fundamental gatekeeper configuration commands.
The first concept is the gatekeeper technology-prefix, which is the core of the gatekeeper dynamic call-routing process. Look at the tech-prefix as a special label used to group together a set of VoIP gateways. The gateways may register their technology prefixes with the gatekeeper dynamically, or you can map the prefixes to the VoIP gateways statically. The gatekeeper looks at the gateways registered under the same tech-prefix to be members of a single “gateway pool”. Now, recall that tech-prefix is just a part of the dialed number. Whether the called number prefix is actually a technology prefix, is decided by the gatekeeper, when it matches the dialed number against the database of the local registered/configured prefixes. There is nothing in the dialed number itself, that designates the part of the dialer string as a technology prefix.