Hi Aamir
Having only two gateways sort of distorts the power of the
local-route-groups unless you are looking at 911 which would only want to go
out of own gateway.
rp:911 -> rl-local (rg:local-route-group)
However if you had
rg-all-us-gateways = BR1-RTR + HQ-RTR
The you could have:
rp: \+ --> rl-us-local (rg:local-route-group, rg-all-us-gateways)
I guess this would give your solution if the first gateway had failed in the
local-rg it will also fail in the rg-all-us-gateways so subject to service
parameters you would pick the next one. It¹s a bit haphazzard.
In the real world you would have a backup in country/state rg giving a more
suitable destination.
Where it really comes into it¹s own it teho.
rp: \+1212 --> rl-hq-teho (rg-hq, rg:local-route-group)
rp: \+1617 --> rl-br1-teho(rg-br1, rg:local-route-group)
So you try and least cost route and if that fails send call out of own
gateway
Best regards
Mick
E: m...@pobox.net.uk
From: Aamir Panjwani <aamir.panjw...@ivision.com.au>
Date: Mon, 17 Aug 2009 21:37:26 +1000
To: Mick Vaites <m...@pobox.net.uk>, ccie8340tx <ccie834...@gmail.com>,
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
Thanks Mick for sharing your knowledgeit certainly does help! I have
following questions for you though
1) Let say requirement is to for HQ local calls to go out local GW and
fallback to BR1 GW, likewise for BR1 local calls to go out local GW and
fallback to HQ GW. Now generally speaking when we create a route list for
given scenario it would be something like
RL RG
HQ: rl-hq-br1 rg-hq
rg-br1
BR1: rl-br1-hq rg-br1
rg-hq
However, can we replace the primary route group with the local route group
to achieve the same result or do you see any potential issues with this
approach
HQ: rl-hq-br1 local-route-group
rg-br1
BR1: rl-br1-hq local-route-group
rg-hq
and it may sound bit silly, but what about the following, consolidate above
into just ONE route group
rl-local local-route-group
rg-hq
rg-br1
so in normal mode calls for both HQ and BR1 will go out local-route group.
However, in case of primary gateway being unavailable we have following
options
1) HQ gateway down: From HQ¹s perspective local-route group and
³rg-hq² are same so would it automatically fallback to 3rd route group
³rg-br1² in the route list?
2) BR1 gateway being down: calls will go out 2nd route group ³rg-hq²
I haven¹t tested it yet but I think ONE route group solution won¹t work (I
know I have kinda answered my own question J) because of the fact that we
can apply different digit manipulation so same route group within different
route list, but wanted to confirm with everyone just in case anyone has
different opinion.
Thanks
From: ccie_voice-boun...@onlinestudylist.com
[mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Mick Vaites
Sent: Monday, 17 August 2009 8:32 PM
To: ccie8340tx; Brian Valentine; 'Kevin Damisch';
ccie_voice@onlinestudylist.com
Subject: Re: [OSL | CCIE_Voice] 11 digit local and LD issue
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
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
