03-19-2011 12:01 PM - edited 03-16-2019 04:02 AM
Hello,
I am a student at a CCNP voice bootcamp. Recently my instructor attempted to demonstrate and walk me through a E.164 configuration where the /+.! route pattern is used. We spent more than an hour troubleshooting the lab when we realized that our called party transformation pattern simply would not strip off the + with a delete pre dot pattern.
Finally after an hour of troubleshooting he came up with a solution but although I have spend over an hour breaking down the process and understanding what he did I find it hard to believe that this is an industry standard solution/configuration. I would like some feedback to help me better understand what is really going on.
We are using an MGCP gateway controlled by the Call manager. The MGCP gateway uses ISDN and we are using "debug isdn q931" to see whether or not our configuration is correctly performing the called party transformation pattern for the route /+.!
We could never get this to work because our phone, our translation pattern, our route pattern, our called party transformation pattern and our Gateway was all in the same CSS. Once we broke up each step into a separate CSS/partition pair then the + could be stripped off and the call could be routed. I don't see a good example of this in the book but on page 4-189 of the new 8.0 CIPT-1 cirriculum it states "Therefore, creating completely independent CSSs for calling privilege implemenlalion as well as for called- and calling-transformation patlems is highly recommended."
But when we did the lab it just seemed so confusing that I kept thinking there must be a simpler way. Can anyone please shed some light on this process.
So here is the process:
Phone is placed in partition Internal
>>Internal has access to CSS "CSS1" which allows calls to Internal phones and partition "TransPattern"
A Translation Pattern is created for partition "TransPattern" dialing of digits [2-9]XXXXXXXXX to add a "+" to the beginning of calls coming from the phones and directs the calls to the CSS "RoutePattern"
>>CSS "RoutePattern" has access to partitions Local, Long Distance and International but none of these partitons are used instead the default partition is used to route calls via /+.! The called party transformation pattern box is checked.
>>A called party transformation then deletes the "+" by using the pre dot method and places the call into the "trans called_out" partition. This partition has access to the CSS "css_called_out"
>>The gateway of the MGCP router is placed within the css_called_out partition and the device pool for the phones are also placed in the css_called_out partition.
The call then is able go out to the PSTN without the +. But what did we really accomplish? What was the benefit of adding a "+" only to strip it off again? Why won't the called party transformation pattern work to strip off the + when everything is in the same CSS but it works fine when you break it up into so many different partitions/CSSs? When I asked my instructor these questions he just said that this is simply the correct way to implement E.164 dialing but after more than an hour of troubleshooting you can understand my skepticism at his solution. Is this really industry standard or just made up? What was the point of this lab and what is the point of using an E.164 standard when its much easier to do things the way they were in the CUCM 6.0 days of transformation masks and digit manipulation without the need of a "+".
Your help to understand this is MUCH appreciated!
Joshua
Solved! Go to Solution.
03-19-2011 04:36 PM
This is a must read write up by Vik Malhi
http://blog.ipexpert.com/2009/09/10/what-every-ccie-voice-candidate-should-know-about-dialing/
HTH
/divin
PS:Rate only useful posts!
03-19-2011 04:10 PM
I am trying to digest this I will have an explaination soon
03-19-2011 04:32 PM
Okay!
Lets take an example!
We have 2 Sites one in US and one in the UK
US Numbers are +1 [2-9]XX [2-9]XX XXX
UK Numbers are + 44 8XX XXX XXXX [Not too familiar with the UK numbering plan]
2 Scenarios
1) Call going out to the PSTN
2) Call coming from the PSTN into our Call Manager cluster
Case 1 : US User picks up the phone and dials 9011 44 888 999 4000 (UK Number)
I have TEHO setup, so that all the calls from US to UK goes out the local UK gateway!
So... in the new world of + dialing we would do the following
Called Number : 9011 44 888 999 4000 ----> Translation Pattern 901144 XXX XXX XXXX ----> +44 XXX XXX XXXX ---> RP +44 XXX XXX XXXX ----> GW
Now...we can do digit manipulation @ 3 levels. Route Pattern < RL/RG level < Gateway ... I have intentionally used the "<" .. Gateway level OVERRIDES every other level... RL/RG overrides RP level digit manipulation.
So...In my case, I just choose to do digit manipulation on the GW level...so I have Called Party Xformation CSS on the GW. Called Party Xformation CSS contains Called Party Xformation Masks pertaining to the UK GW..
So the Xformation Mask is something like ... \+44 XXX XXX XXXX ----> say we need to send only last 7 digits out to the UK PSTN as its a local call .. we do the xformation here.! ...
Same applies to Calling number too.. UK PSTN might not accept a 7 Digit US Extension we might need to E.164ize the calling number
Case 2: Call coming in to DN 3000 in the UK which gets transferred to a US extension 5000
So here... the call flow is like this
UK Mobile ----> UK GW -----> UK Internal DN 3000-----> Transfers ----> US DN 5000
Think of how the calling number should be displayed to the user in UK and the US. Users in a geographic location is used to see a particular format of numbers. Like in the US, 7 digits is a LOCAL call etc..
So ...lets say ... UK Mobile E.164 Number is +44 833 444 5555
Lets say ... when the call comes in to the UK DN 3000, we need to show the last 7 digits. But when the call hits the US DN 5000, The user should see 9011 44 833 444 5555.
So in this case...
Lets say the PSTN marks the Plan and Type of the incoming calling number as ISDN/Subscriber. And the PSTN sends the calling number as 444 5555(Subscriber/ISDN)
Now...on the GW, we would add a prefix to these calling number to make them E.164 compliant. so..we would add +44 833 444 5555 (Calling Number)
We will route the call to the UK DN 3000. on the phone we would have a Calling Party Xformation CSS which has access to Calling Party Xformation Mask which would convert the E.164 ---> 444 5555
Now...the user in the UK transfers the call to the US DN 5000, same procedure there too .. Change the E.164 number to 9011 44 833 444 5555 using Calling party Xformation CSS and Calling Party Xformation masks
Beauty of this method of digit manipulation is ..for an incoming call, its always stored as E.164 entries in the Directory(Placed Calls/Missed Calls/Dialed Calls) etc
Does this make sense? I hope it does.
Let me know if you need more help ! Happy to see someone breaking his head over dialplans!
HTH
/divin
PS:Rate ONLY useful posts.!
03-19-2011 04:35 PM
And the obvious! Lesser Route Patterns! Easy Digit Manipulations! TEHO is very easy to setup
03-19-2011 04:36 PM
This is a must read write up by Vik Malhi
http://blog.ipexpert.com/2009/09/10/what-every-ccie-voice-candidate-should-know-about-dialing/
HTH
/divin
PS:Rate only useful posts!
03-19-2011 08:44 PM
I am still trying to digest your answer but the crux of my question I don't think has been answered:
1. Do you need 3 partitions? Do you need 3 Calling Search Spaces?
2. Why?
- Why did using only one CSS break our dial plan?
3. What fundamental understanding of partitions, CSS, transformation patterns and translation patterns am I not seeing because I assume this is too complicated?
4. You stated "Beauty of this method of digit manipulation is ..for an incoming call, its always stored as E.164 entries in the Directory(Placed Calls/Missed Calls/Dialed Calls) etc"
- basically it seems as if +dialling is all about displaying the number to the user in a way that eliminates the 011, 1, or 3 digit area code for local numbers yet having a standardized dial plan for call routing. So all this work is just for users to see a + when calls are incoming or when redialing incoming numbers. I guess I am too lazy? I am like "just let the users see 011 whats the big deal".
- so what did we do before this "standardization" of our dial plans, is this so that the phones can place the dash marks in the right locations when displaying numbers? Was the world such a terrible place before CUCM 7.0 incorporated this "E164 feature" could we not do this displaying correctly before then?
5. My instructor seems to believe than when dialing a local US number out to the PSTN you can dial it 011 1 AreaCode, 7 digit number and it will still work. I basically told him this makes no sense. He wants to 'standardize' all of the outgoing numbers in this way and my thought is "no don't do that just transform numbers only as needed". His way of standardizing outbound dials is to make them all 011 1 AreaCode, 7 digits. I am not in the US now so I can't test it but this doesn't seem right to me. I wish someone with a land line could test this for me and let me know if it is true (I don't have a land line in the US anyways so wouldn't know) but this seems contrary to common sense, the call shouldn't work. He says "well don't you want a 'standardized' numbering plan? Is this the "wonderfulness" we gain from the standardization of E164. I am probably not reading enough and just being too lazy when understanding this.
6. So standardization of dial plans is "great". Well why not just perform translations as needed for every possible senario without thinking "is my dial plan 'standardized' is it wonderfully E.164ish enough? Obviously I need to read your link and the book.
03-20-2011 01:24 AM
I am still trying to digest your answer but the crux of my question I don't think has been answered:
My answers marked in Don't think so. I don't have any partitions in my TEST cluster. PLUS dialling works
RP -
> in Partition
To call that RP you will CSS which contains PT. (Calling Rights)
Same applies to xformation masks too. For a Endpoint to match a Xformation MASK and do the digit manipulation, the END Point's Xformation CSS should have access to the Xformation Mask.
I would say less route patterns. Mor standardized way of routing. As in once we have the FULL E.164 number, we can route it out any GW as we wish. As long as we follow that specific country's dialing rules.
5. My instructor seems to believe than when dialing a local US number out to the PSTN you can dial it 011 1 AreaCode, 7 digit number and it will still work. He wants to 'standardize' all of the outgoing numbers in this way and my thought is "no don't do that just transform numbers only as needed". I am not in the US now so I can't test it but this doesn't seem right to me. I wish someone with a land line could test this for me and let me know if it is true (I don't have a land line in the US anyways so wouldn't know) but this seems contrary to common sense, the call shouldn't work. He says "well don't you want a 'standardized' numbering plan? Is this the "wonderfulness" we gain from the standardization of E164. I am probably not reading enough and just being too lazy when understanding this.
Think of the transfer scenario! UK to US... Incoming call comes in as 333 4444 to the UK DN. It's a local call in the UK. Phone displays 333 4444. Transfer the call to the US DN. What will the User @ US Dn think? 333 4444 could be a local number in the US too Get my point. If we don't E.164ize a number when it hits our GW, we will be loosing the calling party details.. That’s what I think! :)
03-20-2011 01:27 AM
I am still trying to digest your answer but the crux of my question I don't think has been answered:
My answers marked in Don't think so. I don't have any partitions in my TEST cluster. PLUS dialling works
RP -
> in Partition
To call that RP you will CSS which contains PT. (Calling Rights) Same applies to xformation masks too. For a Endpoint to match a Xformation MASK and do the digit manipulation, the END Point's Xformation CSS should have access to the Xformation Mask.
I would say less route patterns. Mor standardized way of routing. As in once we have the FULL E.164 number, we can route it out any GW as we wish. As long as we follow that specific country's dialing rules.
5. My instructor seems to believe than when dialing a local US number out to the PSTN you can dial it 011 1 AreaCode, 7 digit number and it will still work. He wants to 'standardize' all of the outgoing numbers in this way and my thought is "no don't do that just transform numbers only as needed". I am not in the US now so I can't test it but this doesn't seem right to me. I wish someone with a land line could test this for me and let me know if it is true (I don't have a land line in the US anyways so wouldn't know) but this seems contrary to common sense, the call shouldn't work. He says "well don't you want a 'standardized' numbering plan? Is this the "wonderfulness" we gain from the standardization of E164. I am probably not reading enough and just being too lazy when understanding this.
Think of the transfer scenario! UK to US... Incoming call comes in as 333 4444 to the UK DN. It's a local call in the UK. Phone displays 333 4444. Transfer the call to the US DN. What will the User @ US Dn think? 333 4444 could be a local number in the US too Get my point. If we don't E.164ize a number when it hits our GW, we will be loosing the calling party details.. That’s what I think! :)
HTH
/divin
PS: Rate only useful posts!
03-20-2011 01:30 AM
Sorry for the mess!
I am still trying to digest your answer but the crux of my question I don't think has been answered:
1. Do you need 3 partitions? Do you need 3 Calling Search Spaces?
Don't think so. I don't have any partitions in my TEST cluster. PLUS dialling works 2. Why?
- Why did using only one CSS break our dial plan?
can you post a detailed TP/RP/CSS/PT/Xformation etc
3. What fundamental understanding of partitions, CSS, transformation patterns and translation patterns am I not seeing because I assume this is too complicated?
RP -
> in Partition
To call that RP you will CSS which contains PT. (Calling Rights) Same applies to xformation masks too. For a Endpoint to match a Xformation MASK and do the digit manipulation, the END Point's Xformation CSS should have access to the Xformation Mask.
4. You stated "Beauty of this method of digit manipulation is ..for an incoming call, its always stored as E.164 entries in the Directory(Placed Calls/Missed Calls/Dialed Calls) etc"
- basically it seems as if +dialling is all about displaying the number to the user in a way that eliminates the 011, 1, or 3 digit area code for local numbers yet having a standardized dial plan for call routing. So all this work is just for users to see a + when calls are incoming or when redialing incoming numbers. I guess I am too lazy? I am like "just let the users see 011 whats the big deal".
- so what did we do before this "standardization" of our dial plans, is this so that the phones can place the dash marks in the right locations when displaying numbers? Was the world such a terrible place before CUCM 7.0 incorporated this "E164 feature" could we not do this displaying correctly before then?
I would say less route patterns. Mor standardized way of routing. As in once we have the FULL E.164 number, we can route it out any GW as we wish. As long as we follow that specific country's dialing rules.
5. My instructor seems to believe than when dialing a local US number out to the PSTN you can dial it 011 1 AreaCode, 7 digit number and it will still work. He wants to 'standardize' all of the outgoing numbers in this way and my thought is "no don't do that just transform numbers only as needed". I am not in the US now so I can't test it but this doesn't seem right to me. I wish someone with a land line could test this for me and let me know if it is true (I don't have a land line in the US anyways so wouldn't know) but this seems contrary to common sense, the call shouldn't work. He says "well don't you want a 'standardized' numbering plan? Is this the "wonderfulness" we gain from the standardization of E164. I am probably not reading enough and just being too lazy when understanding this.
It could work! But, in theory, in the US, when you call a local you sent out 7 digits, national 1+10 digits and international 011 + E.164. It might work...but usually we do it according the geographic regions dialling plan.
6. So standardization of dial plans is "great". Well why not just perform translations as needed for every possible senario without thinking "is my dial plan 'standardized' is it wonderfully E.164ish enough? Obviously I need to read your link and the book.
Think of the transfer scenario! UK to US... Incoming call comes in as 333 4444 to the UK DN. It's a local call in the UK. Phone displays 333 4444. Transfer the call to the US DN. What will the User @ US Dn think? 333 4444 could be a local number in the US too Get my point. If we don't E.164ize a number when it hits our GW, we will be loosing the calling party details.. That’s what I think! :)
03-20-2011 02:44 AM
I think I am starting to get it. Basically "plus dialing" or "+ dialing" configurations are really needed for international translations. Without them things get way to complicated. Reading the article you wrote really did help a lot. As for my instructor I think he was right in creating as many partitions and CSSs as he did after reading that this is the way to do it. I am willing to take it as "this is just the way its done" but not sure I understand why it didn't work before and why it works now.
Thanks again for your posts. Most importantly the link really helped me.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide