Cart
When using the term “+ dialing” we are typically referring to storing and calling a contact’s telephone number in the Corporate/Personal, Missed/Received calls directory in the equivalent of the fully qualified domain name format which is defined by the ITU spec E164. This defines the “+” character at the start of every telephone number followed by the country code and national digits. We don’t define the telephone number in a format that is localized to a particular country- for example with an international prefix of “011” which is localized for the NANP dialing domain. To put it another way- + dialing is all about making calls using a contact’s globalized telephone number.
It is worth pointing out that currently users’ cannot dial the “+” character from the keypad of Cisco IP Phones. This means that an Enterprise that wishes to switch to + dialing must also concurrently support localized dialing (dialing with an access code of “9” or “0” depending on the country). + dialing can only be used when dialing a telephone number from one of the directories or manually from the CUPC client (there are many SIP endpoints that support + dialing but we shall focus with the context of the CCIE Voice lab in mind).
If you are only dealing with devices in a single dialing domain (e.g. NANP dial rules) then the full benefit of designing and implementing your dial plan in full E164 format will not be fully realized.
If you are dealing with devices registered to a single UCM cluster spread across different dialing domains (countries) then tell me how you are going to get AAR, internal calls to an IP phone in SRST mode using the Call Forward UnRegistered setting (CFUR), roaming devices such as CUPC, wireless handsets and dual-mode phones making calls efficiently across dialing domains without the use of + dialing? The key word here is efficiently- meaning a solution that scales well.
The purpose of this blog is to take a look at the “new world” way of creating a dialplan and assumes advanced knowledge of Call Routing in Unified Communications Manager (UCM).
Let’s take a look at a very basic problem that illustrates some of the advantages of + dialing.
San Jose based user “Fred” has a contact “Bob” in his personal directory with telephone number “4082223333”. When Fred calls Bob from his CUPC (or wireless 7921 or dual-mode cellphone) registered to the UCM whilst in San Jose the Route Pattern “9408.XXXXXXX” is matched and 7 digits are sent out to the San Jose gateway (the Route Pattern has Called Number Transformation Discard Digit Instruction PREDOT). Fred can successfully call Bob.
The Route Pattern points to a Route List containing the Standard Local Route Group (a virtual Route Group that retrieves the actual Route Group from the calling party’s Device Pool). Since Fred is registered to the San Jose Device Pool, the San Jose Route Group, which contains the San Jose gateway, is chosen.
When Fred goes to the Paris office and initiates a call to Bob, the call fails since 408XXXXXXX is an invalid number to be sending to the Paris PSTN. [Note- for the purposes of this example we are routing all calls at each site to the Local Gateway only].
To exasperate the problem further, Fred is unable to make calls to local, national or international numbers whilst roaming in Paris since “0” is the access code used in France and Fred is used to dialing with an access code of “9”. “00” is the international prefix used in France whilst “011” is the international prefix in the US. So when Fred wants to call his customer in Spain, for example, he would have to dial an access code of 0 followed by the international prefix of 00 followed by the Spanish country code 34 followed by the national digits in Spain. In Fred’s personal directory the contact in Spain is stored with the telephone number 901134+national digits. In order to successfully make a call to the contact in Spain, Fred must edit the contact’s stored telephone number and localize it to an appropriate format that works in France.
Storing contacts telephone numbers in full E164 or globalized format- which means that the “+” is followed by the destination country code and remainder of the national digits- is a scalable method of solving the problem. If Fred has added Bob as a contact with Number +14082223333” the dialed number can be transformed into the appropriate local format depending on where Fred happens to be at the time.
Designing the Dial Plan around Globalized numbers
So we can add the following Route Pattern in UCM to deal with Fred making the call to Bob from the San Jose office:
- \+.! / pt-pstn > RL-LOCAL > Local RG > SJC-GW (based on originating Device Pool)
This single Route Pattern should be available to ALL our sites including those across different dialing domains. The called # transformation patterns defined below are used to format the number into the desired format.
The “+” character is a valid wildcard within the Route Pattern meaning 1 or more of the preceding characters within the Route Pattern. In order to negate the wildcard property of “+” and search for the “+” character in the Called Number string, we precede the “+” with the International Escape character “\”. We would add the Called Party Transformation Patterns as follows:
- \+1408.! / pt-sjc-dnis; DDI=Predot; Type = Subscriber
- \+.1! / pt-nanp-dnis; DDI=Predot; Type = National
- \+.! / pt-nanp-dnis; DDI=Predot + Prefix 011; Type = International
The San Jose gateway would have the Called Party Transformation CSS:
- CSS-SJC-DNIS
PT-SJC-DNIS
PT-NANP-DNIS
The “\+1408.!” Called Number Transformation pattern will modify the Called Number so only the last 7 digits are sent to the PSTN and is site specific- in other words only the San Jose gateways should undergo the digit manipulation contained in this Called Number Transformation pattern since 408 is only local when the call is being sent to the PSTN from San Jose. When a call destined to the 408 area code is being sent to the PSTN from another city such as NYC, we would have to send all of the national digits as opposed to the last 7 “subscriber” digits to reach the contact in San Jose. We also set the Called Party Number type to Subscriber (quite often optional in the real world).
The \+.1! Called Party Transformation Pattern is specific to all callers from the US dialing Long Distance. Since the Called Number begins with +1 the called party is in the US (or at least NANP dialing domain- sorry Canadians and some Caribbeans). Hence we will place this into a partition that all of our US gateways will be able to access. Local calls to San Jose will not use this more generic Called Party Transformation Pattern since the \+1408.! Pattern is a longer match. If we have other gateways in the US then we should create a single Called Party Transformation Pattern that is specific to that site. So our gateway in New York will contain a \+1212.! / pt-nyc-dnis and the New York gateway Called Party Transformation Pattern CSS would contain pt-nyc-dnis and pt-nanp-dnis.
The \+.! Called Party Transformation Pattern is specific to all International calls since we only get if there was no match on the local or LD pattern. Assuming our PSTN provider does not accept the number in full E164 format we need to put the international prefix that is used in the US- namely 011. This should be accessible to all gateways in the US but not to gateways in a different dialing domain such as the UK or France where the international prefix is 00 (the same is true of the other Called # Transformation patterns mentioned).
In each of the 3 Called Number Transformation patterns we are taking the globalized number and localizing it to a format that San Jose PSTN provider is expecting.
We would need to make the following Called Party Transformation Patterns accessible to the gateways in Paris (we are going to assume local and national calls are identical). Country code for France is 33.
- \+33.! / pt-france-dnis; DDI=Predot + Prefix 0; Type = National
- \+.! / pt-france-dnis; DDI=Predot + Prefix 00; Type = International
National/local calls are sent out to the PSTN with a leading zero prepended to the national digits. The Called Party type is set to national.
International calls are sent to the PSTN with the international prefix of 00 followed by the country code and national digits.
Called Number Transformation Pattern gotchas
The Called Number Transformation pattern allows you to avoid creating duplicate site specific Route Patterns. You must be careful when using Called Party Transformation Patterns to manipulate the Called Number.
The first thing to mention is that the Called Transformation Pattern will not affect call routing within the UCM- the call is going to go out of the gateway regardless of how you transform the number. The only chance you can change the Called Number again is if you are not using MGCP. With H323 you can perform subsequent digit manipulation within dial-peers.
It is possible to perform Called Number digit manipulation on the Route Pattern and Route List- the Route List taking precedence. If you use Called Number Transformation Patterns, the string that is used when matching a Called Number Transformation Pattern is the string at the point when the Route Pattern was matched. In other words, the Called Number Transformation Pattern match will look at the Called Number pre Route pattern and Route list digit manipulation and negate or override any Called manipulations that were taking place in the chosen Route Pattern or Route List. The Called Transformation Pattern CSS will not be used for specific calls out of the gateway but potentially ALL calls that are being sent out of the gateway. If you have any subsequent Route Patterns that begin with “+” then the called # digit manipulation will always be done at the gateway via Called Transformation Patterns.
Other Route Patterns such as our localized offnet dialing numbers (911, 9[2-9]XXXXXX, etc) that don’t begin with a “+” will not match on a Called Number Transformation patterns based on the configuration discussed thus far- you could perform digit manipulation on the Route Pattern / Route List in this instance or simply re-use the “+” Called Transformation Patterns already created by expanding the localized Called Number to the globalized variant using Translation Patterns and matching on the \+.! Route Pattern.
The destination entity (gateway/trunk/device) as far as UCM is concerned is the entity that invokes the Called (or Calling) Party Transformation Pattern. If a phone calls an offnet PSTN number then the UCM considers the destination as the gateway- the gateway Called/Calling Number Transformation Pattern CSS is used. For a call from the PSTN: as far as UCM is concerned the Gateway calls a phone and the phone Calling Number Transformation Pattern CSS is invoked (there is no Called Number Transformation pattern on phones since this is the actual end destination).
Another thing to be watch out for: if the egress gateway is using Calling Number Transformation Patterns, the Called Number Transformation Patterns are also checked. Yes you saw that right- the Calling Number can be affected by Called # Transformation Patterns, at least in UCM version 7.0.1.
So back to the original example:
Fred sitting in Paris calls Bob using +14082223333. The Route Pattern \+.! Is matched and the Local Gateway is selected. This is determined from the originating Device Pool- in this case the Paris Device Pool is used since the IP Address that the phone is using whilst roaming in Paris is associated with the Paris Device Pool). The call is sent to the Paris gateway where the Called Party Transformation Patterns are invoked. +14082223333 is transformed to 0014082223333 / Type International. The call is sent to the PSTN and Bob’s phone rings.
Tags: + dial, called number transformation pattern, CCIE, ccie voice, ccie voice 3.0, ccie voice lab, CCIE Voice Training, e164 cisco, globalized, IPexpert's CCIE Voice Course, localized, Mark Snow, vik malhi, Voice
Hello Vik,
I couldn’t understand how a calling number tranformation affect the called number. You mean – the patterns in Calling party transformation CSS will be checked against the called number also?
Thanks
Hello Vik,
I couldn’t understand how a calling number tranformation affect the called number. You mean – the patterns in Calling party transformation CSS will be checked against the called number also?
Thanks
On EM scenarios where the EM profile line is shared with Hard phone devices / CIPC, the CFUR could create potential loops and wastage of resources. Though the service parameter MaximumForwardUnRegisteredHopsToDn can be configured to detect and end the loops, It will have still create huge wastage of B channels.
On EM scenarios where the EM profile line is shared with Hard phone devices / CIPC, the CFUR could create potential loops and wastage of resources. Though the service parameter MaximumForwardUnRegisteredHopsToDn can be configured to detect and end the loops, It will have still create huge wastage of B channels.
Vik, Great post. I couldn’t understand 2nd last paragraph though.I would test this but what normally happens is that calling number gets checked against RP/RL/CgPTP . What i infer from your experience is that Calling number will be matched against RP/RL/CgPTP/CdPTP.(both calling and called party transformation patterns).If that’s the case , what would be given priority ? CgPTP or CdPTP and is this a reported bug in 7.0.1 ?
Thanks
Vik, Great post. I couldn’t understand 2nd last paragraph though.I would test this but what normally happens is that calling number gets checked against RP/RL/CgPTP . What i infer from your experience is that Calling number will be matched against RP/RL/CgPTP/CdPTP.(both calling and called party transformation patterns).If that’s the case , what would be given priority ? CgPTP or CdPTP and is this a reported bug in 7.0.1 ?
Thanks
Kamal, Hari,
Yes there is cross-pollination between Called and Calling Party Transformation patterns when they are placed into the same PT and Calling and Called Party CSS are enabled on the gateway. The closest match will take priority.
I would recommend that you ALWAYS place calling and called transformations in SEPARATE partitions to avoid any unwanted overlap. Make the called party transformation patterns invisible to the calling party transformation css and vice versa. This is most likely something you would have done in any case but treat this as a word of warning against taking any shortcuts.
I haven’t found any reported bugs (haven’t looked too hard) but this is reproduceable 100% of the time in 7.0.1.
Kamal, Hari,
Yes there is cross-pollination between Called and Calling Party Transformation patterns when they are placed into the same PT and Calling and Called Party CSS are enabled on the gateway. The closest match will take priority.
I would recommend that you ALWAYS place calling and called transformations in SEPARATE partitions to avoid any unwanted overlap. Make the called party transformation patterns invisible to the calling party transformation css and vice versa. This is most likely something you would have done in any case but treat this as a word of warning against taking any shortcuts.
I haven’t found any reported bugs (haven’t looked too hard) but this is reproduceable 100% of the time in 7.0.1.
Hey Vic -
Never been able to get this to work. Probably my home lab. Any known issues with plus dialing on older models like the 7940? Even if I place the Calling Party Transform CSS directly on the phone rather than the DP to ensure that it is the final change point the missed call directory always shows 4 digits and not the e164 number being sent via the translation pattern. Thanks
Hey Vic -
Never been able to get this to work. Probably my home lab. Any known issues with plus dialing on older models like the 7940? Even if I place the Calling Party Transform CSS directly on the phone rather than the DP to ensure that it is the final change point the missed call directory always shows 4 digits and not the e164 number being sent via the translation pattern. Thanks
nice post Vik! couple of questions for you though
1) when we change the “numbering type” to subscriber, national and international, are we also required to change the “numbering plan” to “isdn” at the same time or is it optional?
2)
in my practise lab i create route pattern for everything instead of called party transformation, do you see any problem with this approach?
3) which is best place to manipulate “outbound ANI” considering +dialing?
4) my understanding is +dialing is not supported in SRST mode. i.e. we can’t dial globalized number from missed calls directory while in SRST..is that correct?
Many Thanks
nice post Vik! couple of questions for you though
1) when we change the “numbering type” to subscriber, national and international, are we also required to change the “numbering plan” to “isdn” at the same time or is it optional?
2)
in my practise lab i create route pattern for everything instead of called party transformation, do you see any problem with this approach?
3) which is best place to manipulate “outbound ANI” considering +dialing?
4) my understanding is +dialing is not supported in SRST mode. i.e. we can’t dial globalized number from missed calls directory while in SRST..is that correct?
Many Thanks
@Earl- the expansion to a full E164 # takes place on the “incoming calling number prefix settings” on either the device pool or gateway.
The calling party transform patterns on the phone or phone DP will localize the number when the phone is ringing (get rid of e164 format and replace it with localized format -e.g. 7 digits for local, 10 digits for LD- while the phone is in the ringing state). So in effect you will only see the E164 # in the Missed Calls/Receive Calls directory.
Try prefixing “+” on the gateway “incoming calling number prefix” settings- that should work- then you can take it from there.
See Vol 2 Lab 3 & 4 for more info.
@Earl- the expansion to a full E164 # takes place on the “incoming calling number prefix settings” on either the device pool or gateway.
The calling party transform patterns on the phone or phone DP will localize the number when the phone is ringing (get rid of e164 format and replace it with localized format -e.g. 7 digits for local, 10 digits for LD- while the phone is in the ringing state). So in effect you will only see the E164 # in the Missed Calls/Receive Calls directory.
Try prefixing “+” on the gateway “incoming calling number prefix” settings- that should work- then you can take it from there.
See Vol 2 Lab 3 & 4 for more info.
@Aamir,
(1) Both changing the Numbering Plan and Numbering Type are, I would consider, optional. I know that with some older PSTN switches you are required to send the correct Plan/Type but in the lab, unless specified, you should be able to leave it to default values.
(2) I would consider it to be better design to have a single Route Pattern with called # transformation patterns manipulating the called #. It is more efficient and allows you to use “standard local route group” and fewer Route Patterns. You lose the benefit of the local Route Group if you are pushing all Called # manipulation to the RP level. This is not felt with 2 or 3 sites so in a lab environment you aren’t going to see much benefit. In the lab, unless specified, it is the result that is going to matter rather than the method of how you get there. Again- unless specified. Personally I would get used to the new way of using transformation patterns.
(3) If the Calling # is going to change depending on the type of call then you must modify at the RP/RL level. If the Calling # is fixed for a particular gateway (e.g. for an HQ phone calling out of an HQ gw always 7 digits, for an HQ phone calling out of a BR1 gw 10 diigts, etc) and not dependent on the type of call being made then use Calling Party Transformation Patterns.
(4) SRST / + dial not supported- at least in 7.0.
@Aamir,
(1) Both changing the Numbering Plan and Numbering Type are, I would consider, optional. I know that with some older PSTN switches you are required to send the correct Plan/Type but in the lab, unless specified, you should be able to leave it to default values.
(2) I would consider it to be better design to have a single Route Pattern with called # transformation patterns manipulating the called #. It is more efficient and allows you to use “standard local route group” and fewer Route Patterns. You lose the benefit of the local Route Group if you are pushing all Called # manipulation to the RP level. This is not felt with 2 or 3 sites so in a lab environment you aren’t going to see much benefit. In the lab, unless specified, it is the result that is going to matter rather than the method of how you get there. Again- unless specified. Personally I would get used to the new way of using transformation patterns.
(3) If the Calling # is going to change depending on the type of call then you must modify at the RP/RL level. If the Calling # is fixed for a particular gateway (e.g. for an HQ phone calling out of an HQ gw always 7 digits, for an HQ phone calling out of a BR1 gw 10 diigts, etc) and not dependent on the type of call being made then use Calling Party Transformation Patterns.
(4) SRST / + dial not supported- at least in 7.0.
Vik -
Thanks so much for the response. It’s not that I don’t grasp the theory, I believe I just have a local problem. I am attempting an upgrade from 7.0 to 7.1 to see if anything improves.
Even if I follow the lab solution guide and copy the steps verbatim I still get the calling number transform in the missed call log instead of the e164 translation pattern.
Vik -
Thanks so much for the response. It’s not that I don’t grasp the theory, I believe I just have a local problem. I am attempting an upgrade from 7.0 to 7.1 to see if anything improves.
Even if I follow the lab solution guide and copy the steps verbatim I still get the calling number transform in the missed call log instead of the e164 translation pattern.
Soooo…
I am running version 7.1.2.31900-1 which does not permit the use of a colon to specify dropped digits on a gateway when specifying your prefixes. A separate field is provided to input the number of digits you would like to drop after appending the prefix.
But my directory problems remains…I still get the final transform. Any calling/called transform applied at the phone level overrides anything that came before. According to Cisco the ANI at the gateway for inbound calls will always be inserted in the missed call directory so even if I misconfigure something I should still see the ANI from the gateway. If I apply a transform on the DP or phone that last transform always shows up instead of the ANI at the gateway. Should this even be possible??? The CSS on my gateway is intentionally set to none and deselected the use DP option.
Soooo…
I am running version 7.1.2.31900-1 which does not permit the use of a colon to specify dropped digits on a gateway when specifying your prefixes. A separate field is provided to input the number of digits you would like to drop after appending the prefix.
But my directory problems remains…I still get the final transform. Any calling/called transform applied at the phone level overrides anything that came before. According to Cisco the ANI at the gateway for inbound calls will always be inserted in the missed call directory so even if I misconfigure something I should still see the ANI from the gateway. If I apply a transform on the DP or phone that last transform always shows up instead of the ANI at the gateway. Should this even be possible??? The CSS on my gateway is intentionally set to none and deselected the use DP option.
Earl:
Calling party normalization is not supported on 7940/60 phones. You should use newer phones like 7941/42/45/61/62/65. Globalize calling number at gateway level using “incoming calling party prefixes” for national, international and subscribers call types, this globalize number (+E164) will be shown in call log directories (i.e missed calls). Use “calling party transformation patterns” to localize what you see in your phone display while call is ringing.
Earl:
Calling party normalization is not supported on 7940/60 phones. You should use newer phones like 7941/42/45/61/62/65. Globalize calling number at gateway level using “incoming calling party prefixes” for national, international and subscribers call types, this globalize number (+E164) will be shown in call log directories (i.e missed calls). Use “calling party transformation patterns” to localize what you see in your phone display while call is ringing.
Dear Vik,
I have a home lab with all devices.How can we simulate the PSTN router for this new globalized dial plan with all these features like + dialing,isdn plans and type specifics.
thanks for your response..
Tom
Dear Vik,
I have a home lab with all devices.How can we simulate the PSTN router for this new globalized dial plan with all these features like + dialing,isdn plans and type specifics.
thanks for your response..
Tom
Hi Vic,
This is a very useful blog. I understand that this is all about the lab. But how about real life? I live in the UK and we are using UK dial plan for all of our customers. How will this new approach work with dial plans? For example, if you dial from a corporate directory +441… number the dial plan will not understand this. So you need to translate the number first to match the dial plan. Which is not an easy task if you have a few route filters there. Then you need to translate the number back to +44 format before it reaches the gateway. If the system is spread around multiple countries then you will need to do the same procedure for every country.
The only workaround I can see there is for Cisco to introduce the new (+ adopted) dial plans.
Regards
Ivan
Hi Vic,
This is a very useful blog. I understand that this is all about the lab. But how about real life? I live in the UK and we are using UK dial plan for all of our customers. How will this new approach work with dial plans? For example, if you dial from a corporate directory +441… number the dial plan will not understand this. So you need to translate the number first to match the dial plan. Which is not an easy task if you have a few route filters there. Then you need to translate the number back to +44 format before it reaches the gateway. If the system is spread around multiple countries then you will need to do the same procedure for every country.
The only workaround I can see there is for Cisco to introduce the new (+ adopted) dial plans.
Regards
Ivan