[cisco-voip] E.164 Globalized Dialplan - Localizing on the egress

[Jason Aarons (AM)]

Since not everything supports the + yet (actually maybe 8.6 finally fixed the hold outs) you will find yourself translating back/forth into and out of E.164.

I like E.164 without the plus based on Cisco Advanced Services rollouts, see third option in the SRND "Variable Length Dial Plan with Flat Addressing"

Interested in see what carrier says about your routing Intralata calls as LD without requiring the user to dial 1, I'm seeing a similar issue in Houston with long distance Intralata calls being 11 digits vs 10 digits in a E.164 setup.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Roger Wiklund
Sent: Thursday, February 02, 2012 6:23 PM
To: Ryan Schwab
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] E.164 Globalized Dialplan - Localizing on the egress



On Thu, Feb 2, 2012 at 10:55 PM, Ryan Schwab <schwaby81 at shaw.ca<mailto:schwaby81 at shaw.ca>> wrote:
> I've been going over the design and advantages of implementing a fully
> globalized (+E.164) dialplan within a Cisco UC environment. The concept and
> configuration methods are clear to me and I like to sum up the concept as I
> understand it by saying: "Globalize the called number as close to the source
> as possible and localize at the destination."
>
>
>
> Implementing a simple \+! Route Pattern pointing to the SLRG and using
> Called Party Transformation Masks to localize(manipulate) on the PSTN
> gateway(s) has obvious benefits when thinking about AAR/CFUR and TEHO.
> However this gets complicated by the fact that in my area (Alberta, Canada)
> the Area Codes overlap long distance calling boundaries (ie: my local area
> code is 403, however not all 403 numbers are local and require to be
> prefixed with a 1).
>
>
>
> This would force configuration of an unmanageable amount of called number
> translations to ensure local calls and long distance calls are formatted
> properly to the PSTN. For example:
> http://www.localcallingguide.com/lca_exch.php?exch=000480
>
>
>
> Has anyone come up with solutions to this issue for true a true TEHO dial
> plan in this type of scenario? My next steps are to have discussions with
> the providers in the area (Telus, Bell) to see if their side can be set up
> to deal with this. Ie: Accept all 10 digit numbers in the 403 area code and
> complete the call even if it is a long distance rate.
>
>
>
> Any comments are welcome.
>
Hi,

I'm in the same boat as you. While E.164 globalization is the way to
go I have come a cross two major problems:

SIP trunks: getting more and more common but the way most ITSPs
authenticate calls, it's just impossible to normalize calling/called
numbers with just one SIP-trunk. You need multiple trunks to be able
to have site specific outbound transformation patterns. I have solved
this with multiple SIP-trunks to the same CUBE, using SIP security
profiles with incrementing SIP ports.

Countries with open dial plans: This is a real pain. Perhaps if you
are in US or in France or whatever with closed dial plans where you
always have to dial area codes this is easy peasy. But I'm in Sweden
and we have an open dial-plan so you can call subscribers without area
code if you are in the same area.

So for me using SRLG + globalization I still have to create site
specific translation rules to match local numbers and prepend area
code and +country code.

Basic example in City called Uppsala:

900.! -> predot, prefix +46 - International calls
9[^0].! -> predot, prefix +4618 -> Uppsala city subscriber numbers
90[^0].! -> predot, prefix +46 -> other area codes

So I have to create the same stuff for another city (Stockholm) but
replace the subscriber numbers with +468 (area code is 08).

In the end I can use SLRG to at least save some route pattern config.
Also E164 globalization with all the benefits. But still stuck with
site specific junk.

/Roger

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120202/5dc0a56b/attachment.html>