Posts from ‘Call Routing’
This isn’t exactly the latest news, and doesn’t effect the CCIE Voice Lab exam (although it very well may effect the new CCNP Voice exams), however I am hearing more and more how people are upgrading their Voice routers with newer 15.x IOS code, and not realizing how existing (working) VoIP calls are being broken due to new, intelligent feature default configurations.
Last July, Cisco decided (wisely, IMHO) to create a new style of Toll-Fraud prevention to keep would-be dishonest people from defrauding a company by placing calls through their misconfigured voice gateway(s), at the company’s expense. This new mechanism works by preventing unintended TDM (FXO/CAS/PRI) and VoIP (H.323 & SIP) calls from being able to be placed through a given company’s voice gateway(s), by simply blocking all unknown traffic. Beginning in IOS 15.1(2)T, Cisco added a new application to the default IOS stack of apps that compares all source IP address with an explicitly configured list in the IOS running config, and if the IP address(es) or subnets do not match, all VoIP traffic is denied. Also, the new default for all POTS voice-ports is to not allow secondary dial-tone, making direct-inward-dial the default for CAS/PRI, and PLAR necessary for FXO.
Join me tomorrow, October 22nd at 12:00 PM PST / 3:00 PM EST, for the free vSeminar: Unified Mobility Interactions with Local Route Group and Globalization.
To attend this free vSeminar, use the following URL tomorrow at 12:00 PM PST / 3:00 PM EST: Unified Mobility Interactions with Local Route Group and Globalization
In case you missed any previous vSeminars, be sure to check out the recent updates here.
If you are interested in learning more about technologies covered by the CCIE Voice Lab Exam, check out INE’s Voice Deep Dive. The CCIE Voice Deep Dive is the ideal way to gain in-depth knowledge about specific topics and technologies. We’ve now just completed 17 modules, and unlike other Class on Demand’s that only go to 20 or possibly 25 hours, ours now span over 95 hours of training, and we still have more to go. It truly doesn’t get any “deeper” than this. We will post an update with the complete new table of contents to these 3 newly released Deep Dive modules on CUCME, next week.
Hope to see you tomorrow!
Many businesses globally – large and small alike – have been converting calls from routing over traditional PSTN carrier trunks – such as E1 & T1 PRI or CAS – to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this – we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee’s exploration on “PSTN Evolution” in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as “relics of a by-gone era”, and said that “Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete” – source: Reuters [emphasis mine].
The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier’s network.
That is a very true saying – in fact one that we believe strongly in here at INE. However we also understand just how expensive it can be to undertake studying for any CCIE Lab exam. That is why, whenever we can, we try to reduce the load on you – the students – to bear this cost. Take for instance our CCIE RS Volume II for Dynamips – we do all we can to provide you the best available instruction while trying to reduce, or sometimes even be able to eliminate the hardware costs associated with studying.
So now we have taken to task trying to do the same for our CCIE Voice track products. We can’t quite virtualize all of the routers used as voice gateways (pesky DSP’s and TDM trunk cards that dynamips won’t ever be able to support since we actually need hardware for the drivers to be able to trigger the signaling), but we thought we would try to reduce the hardware cost for you, the student, in any way we can with the necessary hardware. Anyone having decided to study for the CCIE Voice lab exam has no doubt realized that even if you decide not to take on the enormous cost of building your own rack to practice with, and instead, to rent rack time from any vendor on the market, you still must purchase your own hardware 7961 IP Phones along with some sort of a hardware VPN solution (such as an ASA 5505 or 851 ISR router) at a minimum in order to be able to practice for all of the most important features tested in the lab. This is quite simply due to the fact that the much older 7960′s and all current SCCP Software Client phones (including Cisco CIPC, IPBlue VT-GO*, etc) don’t support any of the newer features – those that are most critical to studying for the latest lab exam. Even if you can manage to find refurbished 7961 IP Phones from eBay for roughly $150/phone and $500/ASA5505 – you still have to invest over $1,000USD just in hardware before you are ready to rent the rack! Seeing as how the 7961 phones are already a generation behind the current ones, and the possibility that when you pass your lab 6-12 months from now that they will likely be 2 generations old and harder to sell for the same price you paid for them – it becomes a very expensive venture to undertake!
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
For many of you geeks and nerds out there like me (I’ll take a poll as to which one is better at another time), you’ve worked with some *NIX flavor for many years now. For others of you, you have most likely dabbled with various Linux distro’s and have come to know commands as needed. One extremely powerful tool that you may or may not have come across during your years is SED or the Stream Editor (sometimes referred to as the String Editor as well). This tool can take input from stdin and manipulate it as it leaves via stdout.
For those of you that have used SED in the past, you will certainly notice some similarities to the Cisco set of commands known fondly to many voice folks as Voice Translation Rules, and given your ability to pick out the differences, may help you in your quick adaptation to Cisco’s iteration of this tool.
For those of you that have not ever used this tool, take no worry. For in these next series of blog posts I will attempt to break down not only the components of Voice Translation Rules, but of the overall science of Digit Manipulation in IOS, into bite-sized chunks that will help you to digest it much easier. 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.