[cisco-voip] PSTN E.164 call routing

Tue Jul 15 11:45:56 EDT 2008

Ok just so we are both on the same page here, this is what I'm trying to achieve. A caller in Calgary from his office dials home which is local to his office. Ordinarily he would dial 403-555-1234. Instead I would like to send to the service provider 1-403-555-1234 and have the call routed. When I do this the carrier instantly recognizes the 1 as an LD code and rejects the call. If I were to do the same scenario with a Mobile phone it would work either way I dial because of the roaming nature of a Mobile phone. I was looking to do this.

Now back to your point, are you suggesting that I prefix the same above example with the international prefix to trick the service provider into routing the call? For example if I dial the same number prefixed with the NA international code it would work? Ex 011-1-403-555-1234?

Thanks Ryan

________________________________
From: smithsonianwa at gmail.com [mailto:smithsonianwa at gmail.com] On Behalf Of Tim Smith
Sent: Tuesday, July 15, 2008 9:28 AM
To: Ryan O'Connell
Cc: cisco voip
Subject: Re: [cisco-voip] PSTN E.164 call routing

I'm not sure if I'm getting the point here! apologies!

Are you saying for your purposes you dont care if it is LD or Local?
When you say ship out the E164 number, how are you getting this? Are the users dialling it?

If you use a line + device css you can achieve a very simple route plan.
You dont need to break it up into local / ld etc for anything other than your own restriction requirements? Are these simple as well?
In a really simple approach you could use 1 route pattern per site.. 0.! or 9.!
Lower your T302 timer.. away you go.
Add blocking translations to the line to take care of class of service stuff. i.e. blocking international for some users or whatever you require

Not saying make all calls LD. But you should be able to dial an E164 number from anywhere, by prefixing your international access code? Does your telco accept this?

My personal preference is same as yours.. simplify as much as possible... then on top of that I'm trying automate the process of adding / managing the route plan - to reduce errors, speed up changes, and reduce risk of RSI for myself!
I wrote a script to add route patterns in bulk... I use a CSV, edit it in excel, then upload the route patterns to CCM.

In CCM 6 you can actually export CSV of translation patterns, edit the CSV (and add all your own entries), and then upload them back in quite easily. I would expect CUCM 7 to extend this and make the route plan even easier to admin.

Until then but if your environment is large, and management complex, then you can create scripts / apps to ease the burden.

Cheers,

Tim

On 7/15/08, Ryan O'Connell <Roconnell at unislumin.com<mailto:Roconnell at unislumin.com>> wrote:

That is exactly what I'm trying to achieve is less route plan entries, and a much cleaner design overall. Back to the Calgary example, area code 403 is shared between Local calls and Long distance calls, and that is just one of 2 area codes for this region. If I want to designate which NNX is local vs LD based on the gateway it is leaving the network from then I would need to write patterns for each, not only that I would have to keep them current ass NNX's are added into the NANP. No Thanks. Cleaner would be to ship a fully qualified number out and let the telco figure it out. So back to my question do you know if this is possible to achieve? I'm pretty sure this can be done using SIP trunks to the service provider but not so sure on the traditional side as in PRI circuits.

I am not sure I am following what you are saying where I could achieve this by creatively selecting which GW certain area codes exit the network from, essentially making all calls long distance? Is this what you are suggesting?

Thoughts

Ryan

________________________________

From: smithsonianwa at gmail.com<mailto:smithsonianwa at gmail.com> [mailto:smithsonianwa at gmail.com<mailto:smithsonianwa at gmail.com>] On Behalf Of Tim Smith
Sent: Tuesday, July 15, 2008 1:54 AM
To: Ryan O'Connell
Cc: cisco voip
Subject: Re: [cisco-voip] PSTN E.164 call routing

Hi Ryan,

Are you able to dial the full E164 number by using the international access code? I would have thought this would work?

This would usually come down to your dialplan design.. i.e. route a call out a certain circuit, and make sure that you are sending the digits required on that circuit so the call can be completed.. this can be different for providers, or could be different if you throw the call out a remote gateway or something for example...

What are you really trying to achieve? Are you just trying to use less route plan entries :)

Cheers,

Tim

On 7/14/08, Ryan O'Connell <Roconnell at unislumin.com<mailto:Roconnell at unislumin.com>> wrote:

Does anyone know if service providers have any present day capabilities or future plans to pass full e.164 numbers. For example we want to pass full numbers to the PSTN whether they are local or long distance and let the carrier figure it out very similar to how it works on the Mobil networks. So today if we are in Calgary and we want to dial another Calgary number we must dial 4031234567, if we dial the same number with a leading 1 then the call gets rejected. Is there any means to make it like it is on the mobile network where if the same number is dialed with the 1 so 14031234567, while in Calgary, and the call gets passed? I know with the introduction to SIP trunking services they would have to take both the 10 digit local number and the 11 digit equivalent and route it accordingly because the point of entry into the PSTN cloud may not necessarily be local. If this is the case I wonder if it's possible with TDM circuits as well?

Thoughts?

Ryan

_______________________________________________
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

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