I like E164 and standard-local-route-groups. Assuming that you have used the line/device method for granting permissions on who dials where.
For outgoing calls : Create translation patterns to get local branch plan --> E164 (with a + at the front). These will be site specific so people in the US can dial 9011 for international it drops the 9011 and replaces with a + in the UK 900 again would be replaced with a + in france 000 again replaced with a + Then create outgoing called/calling translations specific to the gateway. In this way if gateway HQ-RTR is given a calling no of +16178631002 and a called no of +12123945002 it will know how to process these numbers so they are locally recognised by the PSTN at this point. In the case of the calling no it would drop the + and set the type and national. (there is nothing to say the telco will accept this info especially if you set type to international) In the case of the called no it would drop the +1212 and set the type to subscriber. (I¹m not sure if it would just drop the +1 ???) Now back to the local route groups ... Associate rg-hq with device pool HQ and rg-br1 with device-pool BR1 If your route-patterns consist of : \+1212xxxxxxxx --> rl-hq-teho (which contains rg-hq, local-route-group) \+1617xxxxxxxx --> rl-br1-teho (which contains rg-br1, local-route-group) \+! --> rl-gk (something for other targets ...) Basically I created a single partition pt-e164 with all the + dial patterns in it. Teho works auto-magically because it¹s a more specific path. In fact using the AAR also becomes easy as you make all the external numbers their full E164 number without the +, you then create a single AAR group for everyone with + in it. You create a single css (css-aar) containing a single partition (pt-aar) You create a single route pattern \+! in partition pt-aar which points at a route-list containing your local-route-group followed by say head office as backup. Set the service parameters and AAR works for the cluster ;-) For incoming calls: Generate the full E164 number from the subscriber/national/international fields Using the device profile incoming CSS translations you can localise what the phone displays (ie drop the plus and add a 9). It took me a while to get my head around where you do what as there¹s too many options but once it clicks it¹s quite straight forward. To show how flexible this is I made my BR2 another branch paris. To make this work cleanly I added country specific translations for the site (0.00 --> + instead of 9.011), a new set of country specific pt¹s were needed for outgoing permissions but that was about it. Because the number is globalised even a call from the BR2 (paris) extn to a HQ local number works. I believe the reason Cisco is doing this is to make CUCM more scalable I noted in the docs that if you use the default inter/intra codec and QoS settings from the service parameters they increase the max locations from 1000 to 2000. Whilst initially making the whole process a tad more complicated I can see how this reduces the size of the dialplan. --- due to my lack of sleep in the last few days I will apologise up front for the typos etc. Best regards Mick E: m...@pobox.net.uk From: ccie8340tx <ccie834...@gmail.com> Date: Sat, 15 Aug 2009 18:46:15 -0500 To: Brian Valentine <bkvalent...@gmail.com>, 'Kevin Damisch' <kevin.dami...@vitalsite.com>, <ccie_voice@onlinestudylist.com> Subject: Re: [OSL | CCIE_Voice] 11 digit local and LD issue Brian, how can you predict which area code prefix is going to be called and which prefix to add for each of the local called numbers ?. its quite possible the last 7 digits could be available in 1 or more area codes that are local ...Thoughts?? Cheers,Padhu > > ----- Original Message ----- > > From: Brian Valentine <mailto:bkvalent...@gmail.com> > > To: 'Kevin Damisch' <mailto:kevin.dami...@vitalsite.com> ; > ccie_voice@onlinestudylist.com > > Sent: Friday, August 14, 2009 12:51 PM > > Subject: Re: [OSL | CCIE_Voice] 11 digit local and LD issue > > > > > > Well, I¹ll admit that local route groups is not one of my strengths. I > haven¹t used them yet, and I¹m not yet convinced that they will be very > useful in a production environment. Having said that, I¹ll tell you have > that I have configured this exact setup (but without local route groups) for > a client. It was actually quite easy. > > > > Put the seven digit patterns in the ³Local² partition (9.[2-9]XXXXXX). Put > the ³11² digit pattern in the ³Long Distance² > partition(9.1[2-9]XX[2-9]XXXXXX). Same as normal. The only difference is > that when we send the local call, we strip predot and then prefix 1XXX (where > XXX is the local area code). So, if the local area code were 408, and > someone who has the CSS with the local partion in it dials the local number > 95551212, we would send it out to the telco as 14085551212. If they dial > 914085551212, but they don¹t have the LD partition in their CSS, the call > would fail. > > > > Now, couldn¹t you do that using local route groups? I would imagine it would > work if the gateways were H.323. Just make the translation in the dialpeer > instead of in the callmanager. > > > > Am I way off? > > > > > > > > > > > From: ccie_voice-boun...@onlinestudylist.com > [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Kevin Damisch > Sent: Friday, August 14, 2009 10:06 AM > To: ccie_voice@onlinestudylist.com > Subject: [OSL | CCIE_Voice] 11 digit local and LD issue > > > > This isn¹t from the workbooks, but hopefully good discussion. If you are > designing a dial plan where the PSTN requires 11 digits for both local and > LD, what have some of you done to apply calling restrictions so that certain > phones (lobby, breakroom, etc.) can only dial local calls. We don¹t want to > use any long distance access codes such as FAC or PSTN codes. We are looking > at using the Line/Device approach with local route groups. The only way I > see it is to know of every area code/prefix that is considered local to that > site, then create route patterns based off of those. This would be tedious > work as new prefixes could get added and you may not know about them. > > > > Thanks, > > Kevin > > > > > > > > > This communication (including any attachments) is intended only for the use > of the individual or entity to which it is addressed, and may contain > information that is privileged, confidential and exempt from disclosure under > applicable law. If you are not the intended recipient, any dissemination, > distribution or copying of this communication is strictly prohibited. If you > have received this communication in error, please notify Vital Support > Systems at 515 334 5700 and delete or destroy all copies and the original > document. > > > > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
