@learningSkype - "Apply The Selected Routing Policies to All Originating Locations" doesn't work the way you think it does. It's not a bug.
In SM global settings, is the box ticked for "Better Matching Dial Pattern or Range in Location ALL Overrides Match in Originator's Location"?
Ticking the top-most box for location ALL is NOT THE SAME as ticking the box for each location.
Read this:
There's a writeup in the admin guide of how SM routing works, but I'll try to paint a picture here...
"Better Matching Dial Pattern or Range in Location ALL Overrides Match in Originator's Location" - that makes SM act more like CM/ARS. You'll use a better match in location ALL even if you have a lesser match in your specific location.
The location is determined based on the IP of the oldest Via header in the invite. If that IP is in a SM location, then the call is from that location. As an example, say a SIP phone goes to SM to CM and out to SM. That last invite leg will have the phone IP as the oldest via header. If that IP isn't specified in a location, then it'll use the location of the CM SIP Entity. And if there's nothing there, it'll use the location of the Session Manager.
p.311 for locations:
Here's some examples:
Say you have dial pattern 12x at domain ALL and 1234x also at domain ALL.
Suppose 12x is for location "NY" and 1234x is for location ALL.
You dial 12345 from NY.
If the better matching box is not ticked, you'll rollow the routing policy assigned to the 12x@all pattern for location NY
If the box is ticked, you'll pick 1234x for location all.
As a practical example, let's say you have little SIP gateways with analog trunks at each location. You want to use them if the core SIP trunks are unavailable as a 2nd choice and you also want to use them for 911 as a first choice, and then the SIP trunks if any particular gateway isn't available.
You'd build 2 routing policies for each location.
RP-Location1-SIP-Then-Local which would have 2 entries - the SBC rank 1 and the gateway at location 1 as rank 2.
RP-Location1-Local-Then-SIP which would have 2 entries - the gateway at location 1 as rank 1 and the SBC rank 2.
1x min/max 11 from location 1 would point to RP-Location1-SIP-Then-Local.
911 from location 1 would point to RP-Location1-Local-Then-SIP.
And then if you had a new location you never added, you can have a match for location ALL that goes to a routing policy that only goes to SIP 911.
Let's consider another example:
1-212-555-1212 is a number on your enterprise's Cisco switch. It's available via PSTN or on-net. You have an Avaya SBC tied to the Cisco CUBE. You could also dial it over the PSTN.
Let's say the dial pattern in SM is for domain ALL and location ALL.
If you have Avaya gateways and you have the number in each ARS location with a route to SM then the site's local trunk...
You'll always go out SM to the SBC to the CUBE if it's available.
If the CUBE is down, CM will send you out the local trunk on the gateway.
But if you have SIP gateways connected only to SM, you wouldn't be able to accomplish that with CM routing.
If "better match..." was true, you'd only follow 1-555-212-1212@ALL for your specific location if that match was as good as the match for location ALL.
That means you'd need to match a routing policy match to each originating location for that number to use the SBC first and then the local SIP gateway to do it.
If better match was false, then you could follow the 1x match specific to your location and go SBC first and then each location's specific gateway.
Remember: Ticking the top-most box for location ALL is NOT THE SAME as ticking the box for each location.
And you haven't even gotten into subdomain routing yet
Without the box ticked...
SM looks for a match in your location for the domain.
Then it lops off the most specific subdomain.
So... with the better match box unticked, 1234@east.us.pstn.customer.com will look for a match in your location for:
@east.us.pstn.customer.com
@us.pstn.customer.com
@pstn.customer.com
@customer.com
If it finds nothing, it'll do it all over again for location ALL.
With the box ticked, it does the same thing but considers location ALL in the first pass going over the subdomains.
Fun, huh?