Options
CIPT2 - Called Party Number Normalization
negru_tudor
Member Posts: 473 ■■■□□□□□□□
Hi guys,
Am going through my CIPT2 studies now and am setting up a CUCM Globalized E.164 call routing plan. I have it laid out on paper but i have some questions about the "Use Calling Party's External Phone Number Mask":
- Is it best practice to enable it on the Translation Pattern (seeing how they're the new Route Patterns)?
- I only configured a single Route Pattern in a Partition called "PT-E.164" which the Translation Patterns reach via their CSS
- If I tick the "External Phone Number Mask" ONLY on the Translation Pattern then I think all works well for regular dialing (ex. Off-Hook, input digits bla bla)
- However, If the user dials from their Call Lists, they'd be dialing with a +
- So I was considering assigning the "PT-E.164" to the phones' CSSs so that they can dial from their Call Lists
- However, since I would have enabled the "External Phone Number Mask" on the Translation Patterns only, the phones would not be using their E.164 CLID format on calls from their dial-lists as they'd be bypassing any Translation Patterns and going straight to the \+! Route Pattern in my "PT-E.164" Partition (longest match in their CSS now)
- If I ticked the box for the "External Phone Number Mask" under the Route Pattern then calls from dial lists would use CLID on outbound calls as E.164 but whatever I do to manipulate the Calling Party Number on calls going through the Translation Patterns would be undone seeing how the Route Pattern also has the "External Phone Number Mask" ticked.
- My gateways are rigged to handle outgoing CLID and can transform it properly via Transformations
- I guess my question then is...at the Translation Patter Level, is there any point of doing anything to the Calling Party Number aside from ticking the "External Phone Number Mask"? ..it makes sense to manipulate the TON and Plan for the Called Party Number here though.
- Would I need to create additional Translation Patterns for each site to accommodate E.164 dialing and TON tagging along side the regular ones?
Say for an NYC site, would I need to have these Translation Patterns for subscriber calls:
a) Subscriber calls: 9.212[2-9]XXXXX, DDI: PreDot, TON: Sub., Use External Phone Mask
b) Subscriber calls: \+1.212[2-9]XXXXXX, DDI: PreDot, TON: Sub., Use External Phone Mask
Thanks guys!
Am going through my CIPT2 studies now and am setting up a CUCM Globalized E.164 call routing plan. I have it laid out on paper but i have some questions about the "Use Calling Party's External Phone Number Mask":
- Is it best practice to enable it on the Translation Pattern (seeing how they're the new Route Patterns)?
- I only configured a single Route Pattern in a Partition called "PT-E.164" which the Translation Patterns reach via their CSS
- If I tick the "External Phone Number Mask" ONLY on the Translation Pattern then I think all works well for regular dialing (ex. Off-Hook, input digits bla bla)
- However, If the user dials from their Call Lists, they'd be dialing with a +
- So I was considering assigning the "PT-E.164" to the phones' CSSs so that they can dial from their Call Lists
- However, since I would have enabled the "External Phone Number Mask" on the Translation Patterns only, the phones would not be using their E.164 CLID format on calls from their dial-lists as they'd be bypassing any Translation Patterns and going straight to the \+! Route Pattern in my "PT-E.164" Partition (longest match in their CSS now)
- If I ticked the box for the "External Phone Number Mask" under the Route Pattern then calls from dial lists would use CLID on outbound calls as E.164 but whatever I do to manipulate the Calling Party Number on calls going through the Translation Patterns would be undone seeing how the Route Pattern also has the "External Phone Number Mask" ticked.
- My gateways are rigged to handle outgoing CLID and can transform it properly via Transformations
- I guess my question then is...at the Translation Patter Level, is there any point of doing anything to the Calling Party Number aside from ticking the "External Phone Number Mask"? ..it makes sense to manipulate the TON and Plan for the Called Party Number here though.
- Would I need to create additional Translation Patterns for each site to accommodate E.164 dialing and TON tagging along side the regular ones?
Say for an NYC site, would I need to have these Translation Patterns for subscriber calls:
a) Subscriber calls: 9.212[2-9]XXXXX, DDI: PreDot, TON: Sub., Use External Phone Mask
b) Subscriber calls: \+1.212[2-9]XXXXXX, DDI: PreDot, TON: Sub., Use External Phone Mask
Thanks guys!
2017-2018 goals:
[X] CIPTV2 300-075
[ ] SIP School SSCA
[X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
[ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
[X] CIPTV2 300-075
[ ] SIP School SSCA
[X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
[ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
Comments
-
Optionsnegru_tudor
Member Posts: 473 ■■■□□□□□□□
Right...so after doing some heavy reading on Globalization/Localization I found the answers to my questions.. You do indeed have only one \+! Route Pattern BUT you'd also need to configure \+ enabled Translation Patterns for each individual site you have set up in the CUCM cluster to facilitate + dialing from Call Lists etc.
Also managed to set up a Globalization/Localization mock lab using 2 sites in different countries belonging to the same cluster and H323 gateways... ran into another interesting thing with the "Wait for Far End H.245 Terminal Capability Set" parameter on the gateways that gave me a good run for my money. Nevertheless, it actually proved pretty useful (even though it took me around 3 hours to troubleshoot the thing) 'cause I got used to the dialed number analyzer and getting more personal with IOS h323 debugs
All in all, pretty cool "framework" for designing a global dial-plan...I can see why this is the way to go
Some useful reading stuff:
- INE's posts: Building Global Dial Plans in CUCM7 Part I: Globalization
- Dennis Mink's blog: Ciscoshizzle: Call Manager using Standard Local Route Group, what's the deal?
- SRNDs although they don't quite hit the nail on the head
- This PDF: http://www.netcraftsmen.com/wp-content/uploads/2014/12/20091027_cmug_What-Does-Unified-Dial-Plan-look-like.pdf
..now back to SRST stuff
2017-2018 goals:
[X] CIPTV2 300-075
[ ] SIP School SSCA
[X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
[ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking) -
Options
shodown
Member Posts: 2,271
glad you figured it out on your own, lol. Its pretty hard for me to describe how to do a E.164 dial plan on the fourm. +E.164 is the way to go when you have multiple sites, even if none are INTL. It makes Jabber and dialing missed calls so easy. It also makes admin and building new sites pretty easy as well.Currently Reading
CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related -
Optionsnegru_tudor
Member Posts: 473 ■■■□□□□□□□
Yeap. I think what got me confused about the thing was the fact that everywhere you look you get the "single \+! per system/cluster" which kind of falls out of the picture as you have to back it up with similar translation patterns.. you do have only 1 such ROUTE pattern but there's also the Translation ones gravitating around there 2017-2018 goals:
[X] CIPTV2 300-075
[ ] SIP School SSCA
[X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
[ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)