Primary NI and International Number Type

This is just a quick note on a topic where I recently found closure. This is one of those things where you apply a configuration workaround, intend to find out why people do it this way but get distracted by just about everything. Recently, one of my customers ran into a situation that caused the topic to come up in conversation. Curiosity got the best of me and I made the time to dig deeper. Interestingly enough, I didn't have to dig around as long as I thought.

Anyway, let's get down to it: the "thing" I am talking about is an IOS command. The command is isdn map address ^011* plan unknown type unknown

Background

Let's set the stage with a sample scenario. The customer is using H.323 to communicate to their Cisco Unified Communications Manager (CUCM) cluster and they are using ISDN PRI to communicate with their telco provider. A couple of weeks after the initial deployment of the system, the customer reports that some international calls fail to complete while other calls work just fine. 

The customer works with their carrier and the carrier reports that on the international calls that work, the voice gateway is sending a 011 prefix and numbering type of "unknown". While on calls that fail, the gateway is sending a 011 prefix and numbering type of "international".

Dissection of the Problem

The fact the call fails is not a surprise. It isn't uncommon for the carrier switch to bulk at receiving a prefix (such as 011 for international or 1 for national long distance) AND a numbering type. It makes sense, you can provide the prefix or the type but you shouldn't send both. 

Back to the problem call. When you look at the call setup messages sent from CUCM you will see that the numbering type is specified as "unknown". Which is what we wanted. Now we know that the gateway is putting its two cents into the mix. You look at the configurations and there is nothing obvious which indicates what is going on. No voice translation rules, profiles, etc. Though, you notice that the ISDN switch type is primary-ni. Turns out, this is key.

This isn't new, I have seen it in configs, forums etc. There are a couple of fixes but the common one is to apply the isdn map address ^011* plan unknown type unknown on the serial (e.g. int se 0/0/0:23) interface associated with the D-channel. That still doesn't satisfy the "why".

The Why

The best piece of information I came across that explained "why" is an old software defect: CSCdj64195. About halfway down the bug notes there is this paragraph:

"...the ISDN Type of Number is the Called Party Number IE can be set based upon the length of the called number. The Type of Number will be set according to: 7 digits - Local, 10 digits - National, 15 digits - International. This is performed automatically when using primary-ni switch-type. To override this, use the d channel subcommand isdn map address."

This explains a lot. In my testing I found that when using primary-ni as the switch type and the dial string is exactly 15 digits (no more, no less) the gateway will absolutely set the numbering type to International. If you send 14 or 16, the numbering type is set to unknown. So, if you were calling a mobile phone in the UK (which uses a 10 digit string for mobile devices in the national numbering plan) you would run into this problem. Unless, of course, you use the isdn map address interface command. Why? 011 + 2-digit Country Code + 10-digit national number is 15 digits.

I suspect the "15" comes from the ITU-T specification for the E.164 numbering standard where the max digit length for international numbers for geographic areas is 15. In hindsight, I feel it was one of those things I should have clued in on immediately. Not much more I want to say about that. 

---

Thanks for reading. If you have any feedback, post a comment!