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.
New Call Routing Features in CUCM
The major new call routing specific features in CUCM 7 are as follows:
It used to be that only very large corporations had multi-national operations and therefore needed communications systems that spanned those country borders, however in the past 5-10 years there has of course been a huge expansion of medium-sized (500-1000 employee) and even small (10-20 employee) companies having employees that work across many national boundaries. With the inherent need for employees of businesses of all sizes to communicate effectively with each other, regardless of geographic location between one other, comes the need to have a global standard for understanding and recognizing any phone number when it is presented on any phone screen or is viewed in an application or call history record. To put that in a different way, it would be important that if a call were to be presented to me ringing at a phone, that I be able to quickly and visually distinguish if that call were coming to me from a local area, a national (long distance) area, or from another country altogether, and in fact what country it was coming from.
A Bit of History Necessary to Understand E.164
Not too long after telegraph and then telephones became a common communication platform across the globe, an organization was formed to try to bring together differing systems into some sort of body of standards and principles. This organization started as the CCIF, became the CCITT, and eventually ended up as we now know it – as the ITU-T. In 1997 the ITU-T revised the E.163/Q.11 & E.164/I.331/Q.11 spec into the E.164 (Wikipedia summary here) Public Telecom Numbering Plan recommendation as an international standard for public switched telephone numbers. In a very brief summary that is in no way exhaustive, it defines that:
Here let’s quickly take a high-level overview at global geographic groupings (Zones) of geographic areas grouped mainly by the first digit in the CC field of an E.164 number, and break them down loosely just a bit further:
Why We Might Be Interested in Using These New Features – An Example
Now that we’ve talked a good bit of the idea of the + character, E.164 and its usage, let’s unpack the idea of Calling Party Globalization. The new concept that we are beginning to grasp is that we need to have a way to identify any calling party number, anywhere that it might present itself in the company. This is illustrated below (in bad ascii format
)with explanation:
NYC PSTN caller –> UCM NYC GW –> Hunt Group –>
–> NYC 7961
–> Brussels 7961
Here a call comes into a New York City, US (NYC) PRI gateway from a NYC caller out on the PSTN, and that call rings into a Hunt Group which first attempts to route the call to a NYC 7961 IP phone and when in does, it should display as a local call (let’s say a 10-digit number). However let’s assume that the call is not answered – it will continue to hunt to the Brussels, Belgium 7961 phone and when it rings there, if it were presented in the same fashion as it was to the NYC 7961 phone (as NYC local 10 digit caller-id), surely the person in Brussels seeing the call come in would not intuitively understand that call as having come from the US. In fact while a calling number within Belgium could be formatted as 10 digits, it could also be formatted with 9, but would most probably begin with a “0” if the carrier were sending in the leading national prefix. Instead of allowing that, we would need that calling number to have somehow dynamically updated to a format that made it immediately recognizable to the Brussels phone that the call was indeed from another country and an easily recognizable format to determine the calling party’s country’s origin.
So the first idea we will look at implementing is that of something we will call “Globalization”, and is really one of a sort of “Normalization” of the calling number. One of the ideas behind normalizing any large dataset is so that if we need to query against, or perform any sort of data manipulation against a large set of data is that we must first normalize that dataset before we perform any sort of global query or manipulation. Failure to do so would result in very different results depending on how we format the query and which portion of data we happen to be affecting at the moment we try to run the query or manipulation. When we first normalize the dataset, we can be assured that we have a common starting point from which we can query or manipulate all data in a similar fashion. So the data we seek to normalize or “globalize” first here is that of Calling Party Number and way we normalize that data is that the moment that the call enters into our domain (any UCM cluster under our administrative control) we identify certain information about the Calling Party Number, and subsequently prefix (and sometimes even drop) certain digits to the beginning of each number, depending on that information obtained from call as the carrier has sent it to us.
The information we need to ascertain from the carrier is most importantly, the Numbering Type, and optionally the Numbering Plan. Both of these bits of information come to us via the ITU-T’s Q.931 recommendation for ISDN signaling, and more specifically in the 3rd octet of both the Called and then the Calling Party Information Elements (IE’s) during a Q.931 SETUP message. As did many parts from the Q.931 spec, these elements carried over to the ITU-T’s writing of the H.323 specification, so we have the idea of these as well.
Now needing these bits of information inbound from the carrier assumes a few things – firstly that we have a sort of TDM or IP trunk from a carrier that is capable of carrying this sort of information and, secondly that the carrier actually sends us reliable information regarding the accurate numbering type. For the sake of this conversation, we will assume that every TDM or IP trunk is capable of sending this information, and that our carriers are reliable (this may be a big assumption – I know J – but we nevertheless have to make such assumptions for the sake of understanding the concepts in their entirety).
Let’s define here the different Numbering Plans and Numbering Types:
Note: The numbering types below that happens to be on the same horizontal line below as a given numbering plan does not necessarily mean that that numbering type has any relevance to the numbering plan – in fact many numbering plans do not contain all of the numbering types.
For the sake of this discussion, we only really care about the Numbering Plan of ISDN (or E.164). When we set or receive this kind of Plan (ISDN) going to, or coming from an IP-based trunk, we are actually referring to fact that it represents E.164. For that reason, this is the only Plan we will use from here on in this blog.
Now we will list the types of trunks from CUCM’s perspective that support this information:
Note above that T1-CAS, E1-CAS and FXO are not listed above, and that SIP has a very limited subset (Unknown). This is because CUCM does not support T1-CAS in an FGD type of trunk via the MGCP protocol, does not support E1-CAS via MGCP at all, and only supports Unknown as a type coming in from a SIP trunk. This does not actually mean that we cannot set a proper Type coming in from these specific trunks, only that if we wish to do so, we must do it on the IOS gateway before it reaches CUCM, and that we will not be able to rely on Type or Plan information coming to us from the carrier and therefore must deduce Type from the digits and what we know of our gateway’s geographic location and the carrier sending digits as they enter our IOS gateway from the carrier. We will revisit these types of trunks at the end of the discussion and discuss variant types of configuration to cover them after we have covered everything else.
Configuration for Globalizing Inbound Calling Party Numbers
So if we wish to globalize this data of Calling Party Number as soon as it come into any gateway or trunk that is a part of any UCM Cluster under our administrative control, we must of course configure this at the gateway or trunk web UI page level (there is an option at the Device Pool level – but we won’t explore that in this post as that simply gets into grouping configuration together for ease of large deployments).
So before we look at the actual configuration applied to a given gateway or trunk, let’s setup some assumptions as to what the carrier is sending into our cluster from each given gateway in each site:
This takes all calls with 10 digits (with proper Subscriber or National types) and adds a +1 to globalize and denote a call from the country code 1, and any International calls with variable digits beginning with country code and simply adds a + to denote that what comes next is the country code.
Then on our Brussels GW we will configure the following in the UCM NYC ISDN gateway web page:
This takes all calls with 9 digits (with proper Subscriber or National types) and adds a +32 to globalize and denote a call from the country code 32, and any International calls with variable digits beginning with country code and simply adds a + to denote that what comes next is the country code.
You might ask here why we even have different fields for Subscriber and National – the answer would be to assume that we have a peculiar carrier in a remote, rural part of the US that only sends us 7 digits for Subscriber type calls, and 10 digits for National type calls, in that situation the incoming calling party settings might look something like the next example for a gateway (we will still use the NYC example above so as not to have to define another set of area codes, just for the sake of example, and so let’s just assume that local subscriber calls are only coming in from a 212 area code but again displaying only 7 digits inbound):
The great thing about normalizing or Globalizing this data as it enters any of our our gateways or trunks in any of our UCM Clusters under our administrative control is that once we have Globalized the Calling Party Number, it doesn’t need to be changed or performed again if we wish to move the call across UCM Cluster boundaries. This is regardless of if those boundaries happen to correspond to geographical country boundaries or not, as that Calling Party Number will retain its Globalized Type, Plan and digit format across these boundaries. So to put it in other words, if we have a call come into our NYC, US ISDN gateway as the digits 2125551212, and we accurately identify it and prefix it with a + and a country code of 1 to change it to +12125551212, then when it leaves our US UCM Cluster to route across a Non-GK Controlled ICT Trunk over to our EU UCM Cluster, it remains formatted as +12125551212, and can quickly be recognized as an International calling party from the US.
Now that we have our inbound Calling Party Number properly Globalized, we see from our example of the hunt group earlier that this is obviously great for the quick visual identification of the Brussels 7961 phone as it needs to see and answer this call. However, this doesn’t exactly make it too very quickly readable to the original hunt group member, the NYC 7961 phone who has to see it in its International Globalized format. Sure it is clearly from +1 (US and Canada primarily), but isn’t there an easier way to view it? Such as in its native 10-digit Local format?
There certainly is, and it’s referred to as “Localization”.
But wait, didn’t we just Globalize this call?
Why on Earth (or beyond Earth as dial-plans expand to the ISS, Moon, Mars, etc
) would we want to Globalize a Calling Party Number if we need to turn right around and Localize it??? That is exactly what we will dive into – the “why” of it, as well as the “how” – in the next installation of this series.
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.
New Call Routing Features in CUCM
The major new call routing specific features in CUCM 7 are as follows:
- True E.164 Number support complete with + character
- Calling and Called Party Globalization
- Calling Party Localization
- Mapping Globalized Numbers to their Localized Variant
- Standard Local Route Group
It used to be that only very large corporations had multi-national operations and therefore needed communications systems that spanned those country borders, however in the past 5-10 years there has of course been a huge expansion of medium-sized (500-1000 employee) and even small (10-20 employee) companies having employees that work across many national boundaries. With the inherent need for employees of businesses of all sizes to communicate effectively with each other, regardless of geographic location between one other, comes the need to have a global standard for understanding and recognizing any phone number when it is presented on any phone screen or is viewed in an application or call history record. To put that in a different way, it would be important that if a call were to be presented to me ringing at a phone, that I be able to quickly and visually distinguish if that call were coming to me from a local area, a national (long distance) area, or from another country altogether, and in fact what country it was coming from.
A Bit of History Necessary to Understand E.164
Not too long after telegraph and then telephones became a common communication platform across the globe, an organization was formed to try to bring together differing systems into some sort of body of standards and principles. This organization started as the CCIF, became the CCITT, and eventually ended up as we now know it – as the ITU-T. In 1997 the ITU-T revised the E.163/Q.11 & E.164/I.331/Q.11 spec into the E.164 (Wikipedia summary here) Public Telecom Numbering Plan recommendation as an international standard for public switched telephone numbers. In a very brief summary that is in no way exhaustive, it defines that:
- All numbers will be a maximum of 15 digits in length
- All numbers will have multiple parts to the overall displayed number:
- Country Code (CC) for Geographic Area portion (1-3 digits)
- National Destination Code (NDC) portion
- Subscriber Code (SC) portion
- (NDC and SC portions will be no longer than 15 digits minus the number of digits contained in the CC)
- The 15 digit maximum for the CC, NDC, or SC portions do not take into account any National or International carrier code prefixes (such as 011 or 00 for International or 1 or 0 for National carrier codes)
- All numbers shall be displayed with a + as the preceding character followed by the Country Code (which as we will see is not alone necessarily a good indicator of country but rather geographic area)
Here let’s quickly take a high-level overview at global geographic groupings (Zones) of geographic areas grouped mainly by the first digit in the CC field of an E.164 number, and break them down loosely just a bit further:
- Zone 1 – Numbers beginning with +1 denote North America and many Caribbean island countries, however not Mexico or Central America. These are further broken down into NPA’s (Numbering Plan Area codes) (the NDC portion of the E.614 number) that often further delineate cities or areas in the US or Canada, but also many times delineate entire countries especially when referring to Caribbean island countries.
- Zone 2 – Numbers beginning with +2 denote mostly African countries, some Atlantic and Indian Ocean islands as well. Aside from +20 which is Egypt, typically these countries or areas will use the full three digits in the CC section of the E.164 number (e.g. +2XX).
- Zone 3 – Numbers beginning with +3 denote European countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +3X or +3XX).
- Zone 4 – Numbers beginning with +4 denote European countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +4X or +4XX).
- Zone 5 – Numbers beginning with +5 denote Mexico, Central America and South America countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +5X or +5XX).
- Zone 6 – Numbers beginning with +6 denote Southeast Asia and Oceania countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +6X or +6XX).
- Zone 7 – Numbers beginning with +7 denote former Soviet Union countries such as Russia and Kazakhstan. These countries utilize a single digit from the CC field +7 plus the NDC for delineating between countries similar to North America’s +1 usage.
- Zone 8 – Numbers beginning with +8 denote East Asia countries and Special Services numbers. These countries typically utilize 2 or 3 digits in the CC field (e.g. +8X or +8XX).
- Zone 9 – Numbers beginning with +9 denote West, South and Central Asian countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +9X or +9XX).
- A complete listing in easy to find format can be found here.
Why We Might Be Interested in Using These New Features – An Example
Now that we’ve talked a good bit of the idea of the + character, E.164 and its usage, let’s unpack the idea of Calling Party Globalization. The new concept that we are beginning to grasp is that we need to have a way to identify any calling party number, anywhere that it might present itself in the company. This is illustrated below (in bad ascii format
)with explanation:NYC PSTN caller –> UCM NYC GW –> Hunt Group –>
–> NYC 7961
–> Brussels 7961
Here a call comes into a New York City, US (NYC) PRI gateway from a NYC caller out on the PSTN, and that call rings into a Hunt Group which first attempts to route the call to a NYC 7961 IP phone and when in does, it should display as a local call (let’s say a 10-digit number). However let’s assume that the call is not answered – it will continue to hunt to the Brussels, Belgium 7961 phone and when it rings there, if it were presented in the same fashion as it was to the NYC 7961 phone (as NYC local 10 digit caller-id), surely the person in Brussels seeing the call come in would not intuitively understand that call as having come from the US. In fact while a calling number within Belgium could be formatted as 10 digits, it could also be formatted with 9, but would most probably begin with a “0” if the carrier were sending in the leading national prefix. Instead of allowing that, we would need that calling number to have somehow dynamically updated to a format that made it immediately recognizable to the Brussels phone that the call was indeed from another country and an easily recognizable format to determine the calling party’s country’s origin.
So the first idea we will look at implementing is that of something we will call “Globalization”, and is really one of a sort of “Normalization” of the calling number. One of the ideas behind normalizing any large dataset is so that if we need to query against, or perform any sort of data manipulation against a large set of data is that we must first normalize that dataset before we perform any sort of global query or manipulation. Failure to do so would result in very different results depending on how we format the query and which portion of data we happen to be affecting at the moment we try to run the query or manipulation. When we first normalize the dataset, we can be assured that we have a common starting point from which we can query or manipulate all data in a similar fashion. So the data we seek to normalize or “globalize” first here is that of Calling Party Number and way we normalize that data is that the moment that the call enters into our domain (any UCM cluster under our administrative control) we identify certain information about the Calling Party Number, and subsequently prefix (and sometimes even drop) certain digits to the beginning of each number, depending on that information obtained from call as the carrier has sent it to us.
The information we need to ascertain from the carrier is most importantly, the Numbering Type, and optionally the Numbering Plan. Both of these bits of information come to us via the ITU-T’s Q.931 recommendation for ISDN signaling, and more specifically in the 3rd octet of both the Called and then the Calling Party Information Elements (IE’s) during a Q.931 SETUP message. As did many parts from the Q.931 spec, these elements carried over to the ITU-T’s writing of the H.323 specification, so we have the idea of these as well.
Now needing these bits of information inbound from the carrier assumes a few things – firstly that we have a sort of TDM or IP trunk from a carrier that is capable of carrying this sort of information and, secondly that the carrier actually sends us reliable information regarding the accurate numbering type. For the sake of this conversation, we will assume that every TDM or IP trunk is capable of sending this information, and that our carriers are reliable (this may be a big assumption – I know J – but we nevertheless have to make such assumptions for the sake of understanding the concepts in their entirety).
Let’s define here the different Numbering Plans and Numbering Types:
Note: The numbering types below that happens to be on the same horizontal line below as a given numbering plan does not necessarily mean that that numbering type has any relevance to the numbering plan – in fact many numbering plans do not contain all of the numbering types.
| Numbering Plan (Octet 3, Bits 1-4) | Numbering Type (Octet 3, Bits 5-7) |
|
|
Now we will list the types of trunks from CUCM’s perspective that support this information:
| Trunk | TDM/IP | Type Provided |
| ISDN PRI | TDM |
|
| ISDN BRI | TDM |
|
| H.323 – H.225 | IP |
|
| H.323 – ICT | IP |
|
| SIP | IP |
|
Configuration for Globalizing Inbound Calling Party Numbers
So if we wish to globalize this data of Calling Party Number as soon as it come into any gateway or trunk that is a part of any UCM Cluster under our administrative control, we must of course configure this at the gateway or trunk web UI page level (there is an option at the Device Pool level – but we won’t explore that in this post as that simply gets into grouping configuration together for ease of large deployments).
So before we look at the actual configuration applied to a given gateway or trunk, let’s setup some assumptions as to what the carrier is sending into our cluster from each given gateway in each site:
- Our NYC, US gateway is ISDN PRI, and our carrier is accurately marking and sending us:
- 10 digits for all Subscriber and National type calls as well as those proper Types in the Calling Party IE
- Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of the North America along with the proper International Type
- We also happen know that all 10-digit calls beginning with 212, 718, 917, 347 and 646 are Subscriber type calls and thus local to NYC, while any other 3-digit NDC (referred to as NPA’s within the NANP) are National type calls – and while that information shouldn’t be too necessary at this stage since the carrier should mark all types appropriately, we will need to reference it later.
- Our Brussels, Belgium gateway is ISDN PRI, and our carrier is accurately marking and sending us:
- 9 digits for all Subscriber and National type calls as well as those proper Types in the Calling Party IE
- Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of Belgium
- We also happen know that all 9-digit calls beginning with 02 are Subscriber type calls and thus local to Brussels, while any other 2 or 3 digit calls beginning with 0[1,3-9] are National type calls – and again that info shouldn’t be too necessary at this stage since again the carrier should mark all types appropriately, we will need to reference it later – so we list it here.
| Type | Prefix |
| Subscriber | +1 |
| National | +1 |
| International | + |
| Unknown | Default |
Then on our Brussels GW we will configure the following in the UCM NYC ISDN gateway web page:
| Type | Prefix |
| Subscriber | +32 |
| National | +32 |
| International | + |
| Unknown | Default |
You might ask here why we even have different fields for Subscriber and National – the answer would be to assume that we have a peculiar carrier in a remote, rural part of the US that only sends us 7 digits for Subscriber type calls, and 10 digits for National type calls, in that situation the incoming calling party settings might look something like the next example for a gateway (we will still use the NYC example above so as not to have to define another set of area codes, just for the sake of example, and so let’s just assume that local subscriber calls are only coming in from a 212 area code but again displaying only 7 digits inbound):
| Type | Prefix |
| Subscriber | +1212 |
| National | +1 |
| International | + |
| Unknown | Default |
Now that we have our inbound Calling Party Number properly Globalized, we see from our example of the hunt group earlier that this is obviously great for the quick visual identification of the Brussels 7961 phone as it needs to see and answer this call. However, this doesn’t exactly make it too very quickly readable to the original hunt group member, the NYC 7961 phone who has to see it in its International Globalized format. Sure it is clearly from +1 (US and Canada primarily), but isn’t there an easier way to view it? Such as in its native 10-digit Local format?
There certainly is, and it’s referred to as “Localization”.
But wait, didn’t we just Globalize this call?
Why on Earth (or beyond Earth as dial-plans expand to the ISS, Moon, Mars, etc
) would we want to Globalize a Calling Party Number if we need to turn right around and Localize it??? That is exactly what we will dive into – the “why” of it, as well as the “how” – in the next installation of this series.
0 comments:
Post a Comment