COR explanation 1

[rfcomm2k]

I have looked at many of the threads relating to COR on Avaya Definity, but they all seem to start with the basic premise that the person asking already knows how to do it.

I am new to Definity, have no opportunity to go to school on it, but am tasked with keeping the system operating. I could of course fail at this, which would be a disappointment to me, the customer, and my employer, so I am trying to avoid that.

I am well trained in other products (Cisco UCM, NEC, Mitel, Siemens, Panasonic), but have never seen Avaya until last February. This is the first time a problem has been raised about COR.

So the problem: Certain phones here are restricted to dial 610 and 215 area codes only. And apparently these phones cannot dial toll free calls (800, 888, 866, 877, etc). I looked up a restricted phone, saw that it is COR 4, whereas my phone is COR 1. I displayed COR 4, and that is where I lost it. 0?, 1? 2?, 15?, 87?, what do these all represent?

Is it the dialed digits AFTER stripping off the access code 9?

Is it ALL the dialed digits including the 9?

Is it something else?

Attached is a screenshot of tab 3 of COR 4.

 

[kyle555]

ARS is tricky

do you have multiple locations? Each can have their own ARS which they'll always use unless there is a more exact match in the all table.
So, "list ars analysis" shows the all table, "list ars analysis location 1" shows it for location 1.

Then, for some reason, you're using partition routing - that's what the p in p14 means. It lets you have a matrix where your "time of day chart" number in your COR is your PGN (partition group number). If you display partition 14, you'll see from left to right PGN1 thru 8. If your COR has time of day chart 2, you'd pick the route under the PGN2 column. The idea being that you can have multiple locations, but multiple departments in those locations and sales might be PGN1, customer service PGN2 and they don't share trunks.

You can also have ARS digit conversion per location to manipulate strings - like if people are calling each others DIDs with a 9, you can intercept your ranges to not go out and in. Or, maybe your TF is being converted there if for whatever reason.

list ars route-chosen helps too - tells you how a dialed string will be routed.

 

[joe2938]

ARS/World class Routing is something that will take some time to learn as it is pretty involved

 

[rfcomm2k]

OK kyle555, that is more helpful. As a matter of fact, there WERE 2 locations up until Sept 30. The other site was a standalone system with their own trunks, but there were tie lines between here and there. And a shared numbering plan existed, although the way it was designed it was entirely possible for the same extension number to exist in both locations (until I started working here, at which time I eliminated the duplicate extensions). Over the time from February to September I also tried steering the two systems toward a separate numbering plan, in which my location could have DID numbers in the range of 4000-8999 and the other location would have DID numbers 2000-3999. And to top it off, the other site was in a different area code.

The other site migrated to Cisco VOIP from mid July to September, and the tie lines were disconnected on Sept 30.

So, this all being said, AGAIN I ask where this restriction is occurring? Obviously there is somewhere that has that entire phone number as the dialed digits, because I cannot dial 8775659999, but I can dial 8775659998. Just tell me where that entry can be found so I can remove it.

 

[kyle555]

it's hard to say! udp (list uniform), ars/aar digit conversion per location or the all table, call-type analysis tables.

What bugs me in your trace is that it's route 14 preference 0. I don't like preference 0. I've only seen it in something called a "proxy selection route pattern" if you "display locations" - its basically a route that if all else fails or doesn't match, try it. That's the only time I've ever seen a preference 0 - though I'm sure there's some other reasons that could maybe cause it.

Your problem sounds like you inherited a PBX where someone duct taped a dial plan together. I couldn't tell ya what kind of bad ideas were put in there that are making your life difficult or where the hiccup is. It might not be a bad idea to have an Avaya shop review your dial plan - maybe there's something worth cleaning up in there that can make it simpler for you to manage the system in the long term.

By no means official, this guy tried making a visio

http://rogerthephoneguy.com/?p=329

 

[redphone]

So I typed list ars route-chosen 18775659999 and I got back dialed string 16, route pattern p14. Then I typed list ars route-chosen 18775659998 and I got back dialed string 1877, route pattern p1.

This suggests to me that the number is being converted to an LD number starting with 16. Run the following command to see if your toll-free number is listed:

list ars digit-conversion

It is, or used to be, good practice to add entries to the bulletin board when abnormal changes were made to the configuration. You could also check there for a clue as to why the toll-free number is being changed.

display bulletin-board

 

[rfcomm2k]

kyle555, you said something above that made me go looking somewhere I had not thought of, and found the problem! Thank you Thank you Thank you!
That phone number was in the ars digit conversion table being converted to a Boston number, which of course is restricted in COR 4.

I simply removed that entry and all is well.

Now I hope I did not muck up something else.