Prevent calls from routing over the WAN

[pfp]

Quite simply I'm more concerned about WAN bandwidth than LD rates.

We have multiple offices all with their own switches and trunks / PRI's. I've been limiting the staff in each site to the trunk groups which are local to them and this has worked well so far. We have started to have people traveling between offices rather frequently now an this setup isn't working so well any more. As a result I've now given the people that travel the ability to use trunk groups in any location they travel to. I'm not happy with this since it allows some of their calls to be routed through the WAN.

In the end I would like to give everyone rights to use any trunk but have the system first route calls out trunks local to the phone being used. For example, a Phoenix user travels to Los Angeles, assigns his extension to a phone there, then makes a call to Phoenix. I want that call to go out the Los Angeles trunks.

Is this possible?

[Forum]

Kind of defeats the purpose of the system in a way. I'll have to think on this one.

[cburgy]

Can I ask why you would want that behavior?

[pfp]

I'm more concerned about WAN bandwidth than LD rates. LD rates are ridiculously cheap and I'd rather pay $100-$200 in toll charges than have to add additional T1's at multiple locations (at least $600) to support the added bandwidth of more calls. We are already routing a good deal of data over the WAN + intersite calls + calls where somesome called site A but wants to talk to someone in site B. The bandwidth we have now works very well for all of this but won't if I allow other outbound calls to use the WAN by default.

As a result the least cost routing will actually cost me more.

[cburgy]

Just limit your inter site bandwidth. Drop down the allowable bandwidth on the remote sites to what you want it to be capped at.

[pfp]

Accoring to the manual:

The caller hears a “network busy” prompt if the Admission Control
Bandwidth is exceeded.

I definitely don't want that to happen.

[cburgy]

Accoring to the manual:



I definitely don't want that to happen.

If he has access to the trunks at the site he is visiting, it should prefer access to them if the inter-site bandwidth is not sufficient to make a call.

[Ken]

Hi,

If a traveling Phoenix User login to a LA phone, and call Phoenix, depending on LA site dial plan and LA trunk dial plan and also because the LA IP phones are mapped to LA site, this particular Phoenix user should be using the LA site dial plan and so his call will automatically go out via the LA trunks, just like any LA users.

Yes, No, Maybe?
Will someone be able to try it out?

[Jason Learmouth]

I think that if you change the custom dial plan on the trunk groups to cost all calls as a local call in SWD support mode then no calls will be routed over the WAN. I believe that they will be routed according to the site that the IP phone is mapped to.

I think this might be what Ken was trying to say as well.

This won't stop extension to extension calls from going over the WAN, only admission control bandwidth will affect that. If you want internal calls to go over the PSTN then you will have to look at PSTN failover and 0 admission control, etc.

[pfp]

I think that if you change the custom dial plan on the trunk groups to cost all calls as a local call in SWD support mode then no calls will be routed over the WAN. I believe that they will be routed according to the site that the IP phone is mapped to.

I think this might be what Ken was trying to say as well.

This won't stop extension to extension calls from going over the WAN, only admission control bandwidth will affect that. If you want internal calls to go over the PSTN then you will have to look at PSTN failover and 0 admission control, etc.

I'm fine with extension - extension calls going over the WAN. I'm also fine with INCOMING calls to one office or the other over the WAN. I know how to get in support mode, but I could use some guidance on how to set the costing as you suggested.

[cburgy]

Here is how routing costs work:

The system weights routing based upon site, trunk and the type of call.

A proxy site (proxy is checked) adds a weight of +10
Being at a different site adds a weight of +25

A local call adds +140
Nearby adds +340
Long distance adds +540
International adds +740

Trunk group types (analog versus digital) start with a negative weight and digital are preferred. Unfortunately, I can't remember their weights off hand.

You can only adjust via the support interface by -+ 35. Anything else requires custom dial plan work.

Note that my numbers might actually be a bit off on the actual weights for type of call.

[pfp]

I believe it's

Analog = +1
PRI = -1
SIP = -2

[Jason Learmouth]

I'm fine with extension - extension calls going over the WAN. I'm also fine with INCOMING calls to one office or the other over the WAN. I know how to get in support mode, but I could use some guidance on how to set the costing as you suggested.

Our default dialplan for the trunkgroup looks like this:

<Y.>X.%40G;1H
<+X.>x0011X.%740G
<+M4X.>xm0X.%640G
<+MX.>xm0X.%540G
<+M1(3|800)X.>xmX.%140G
<+MNX.>xm0X.%140G
;40M
<E'+MX.>xm0X.%999G

This is for an Australian trunk group so yours will be slightly different, but similar. The line in red sets the weight of local calls to be 140, local calls can only be dialled out from your local site or a proxy site if no trunks are available at the local site. If you change the weight of the other call types (inat, ld, etc) to also be 140 then they will be treated as a local call and routed as such. To do this replace the 740, 540, etc with 140 in the custom dial plan. Don't mess with the 999 on as that is for routing 911 calls. I've seen this used to stop calls being routed across the WAN when there was an issue with QoS once.

[pfp]

Our default dialplan for the trunkgroup looks like this:

<Y.>X.%40G;1H
<+X.>x0011X.%740G
<+M4X.>xm0X.%640G
<+MX.>xm0X.%540G
<+M1(3|800)X.>xmX.%140G
<+MNX.>xm0X.%140G
;40M
<E'+MX.>xm0X.%999G

Thank you VERY much this is definitely helping me, unfortunately I'm not completey understanding it yet.

I take it the part before %140G, %540G, %740G is some type of code representing the phone number format. I assume the software takes a look at all the trunk groups I have access to, which are capable of placing the call, and chooses the one with the least cost.

This would only change the call routing costs - not make it send a (real) long distance call over a trunk that is only allowed to handle local calls?


To be honest, I really don't want to mess up our dialing plans so perhaps the best bet is to contact our vendor rather than messing this much with the dialing plan.



I also had another thought though. What about using the Nearby Area Codes? What would happen if I entered the remote sites Local and Additional Area Codes in the local sites Nearby Area Codes. It looks like this might accomplish wht I'm looking for and I wouldn't have to mess with the dialing plans.

[Jason Learmouth]

You are correct about the bit before the %740G, etc. Changing the 740 to 140 means that a international call will be costed as a local call and be routed with the same preferences as a local call - i.e. out a local trunk and not through the WAN. If your local trunk group has international dialling disabled then the string would end in %740F ( or just F for FAIL as opposed to GOOD).

You could do some experimenting after hours if you want. You can't actually change the default dial plan, when you edit the custom dial plan the rules are appended to the default and the last matching rule wins. If you stuff it up just delete the custom dial plan.

Near by area codes will probably not work because it is still cheaper to send the call out another site if it is local to that site. The call will be weighed as 175 from the site down the WAN that is local to the called number (local call at another site = 140 + 35) and it will be weighted at 340 from the site configured as nearby to called number. 175 wins so the call goes down the WAN.

Let me know how you go. You can PM with your default dial plan if you want me to give you my version of what I'd change it to.