ARS and mulitple locations 1

[Robi544]

I'm unwinding ARS for a multi-site system.

Under ARS Analysis I have many location specific tables in addition to the "all" table. My loc specific tables have few translations.

Couple questions:

1) Is accurate to assume that the PBX will first search the applicable loc in ARS first and if it doesn't find a match will then check the "all" table?

2) If so, what if a match exists in both tables? Are there precedence or best match rules?


Thanks for any help

--Dave

 

[simreal]

Actually it checks both tables. If one is more unieque it gets useed. if they are the same the master table is used.

So if I dial 9 1720-444-9899

In my location table I have:
1720

And in my master table: 
172

The location table gets used.

If I dial the same number 9 1720-444-9899

In my location table I have:
172

And in my master table: 
1720

The master table gets used.

If I dial the same number 9 1720-444-9899

In my location table I have:
1720

And in my master table: 
1720

The master table gets used.

 

[Robi544]

Thanks so much.

 

[TeleKing]

is it the same funtktion to the ars digit?

 

[Robi544]

As I review and compare the tables I've noticed that my "main" site does not have a location table (i.e. "list ars analysis location 1" is blank).

It seems that up to this point the "all" table was used as the main site table as well as the shared table (primarily to funnel all outbound LD via trunks at the main site.) Local tables are used to let sites use their own trunks for 911 and (sometimes) other local outbound.

There are no complaints and everything's been working fine for years, but I see several instances of more unique enties in my "all" table that were likely only intended for users at the main site.

I suppose this is a "best practice" question, but should I build a loc 1 table and ensure that my "all" table is limited to only those entries I want to be used by everyone at all sites?

 

[simreal]

In our case we DO NOT USE location 1 for any sites. Location 1 uses the master table.

In the master table we deny everything.

Then in each locations specific ars table we setup the routing for that specific site.

This allows you to block anything you might have forgotten in the location table (better to block than allow toll charges) and then make corrections to the location tables as needed.

 

[98Converter]

I think I need to disagree with simreal. Location 1 should be used for location 1, and 'all' should be used only on rare occasions. (IE: an IP Phone is in a disconnected state, but has call-forwarding enabled. Considering it's disconnected, the PBX has no way of identifying which NR it belongs to, so ARS routing fails. If there is an entry in the 'cha ars ana 0' table, then it will route that accordingly. This will also solve x-ported TDM phones that have call-forwarding enabled.)

To answer Teleking - it's the same behavior...


Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[Robi544]

I'm a bit new in the Avaya game - but how do you avoid using loc 1? Isn't it the default site? Our S8710 servers and MCC1, and main G650 cvabinets reside there

 

[98Converter]

You're correct - don't avoid using Location 1. What I think happened, was during your implementation Location 1 ARS was never defined... It simply continued work, because everything in Location 1 was using the 'all' table (due to the fact it had no entries). You can populate/copy the 'all' table into Location 1 and then clear it, and your calls in Location 1 will continue to work. However, now you don't know who else is using the all table... So I might not recommend clearing it.

My opinion...



Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[Robi544]

Ahhh - I see that my two cabs are in Loc 1/Net region 1.

 

[Robi544]

Probably VERY good advice 98Converter and I have no plans to delete anything in the all table just yet. I expect your conclusions are right on target regarding how we got here. Like many deployments we started out as a large single site TDM PBX and VoIP prompted branching out to remote locations years later.

Clear to me now is that many calls are using the "all" table (and I'll probably set up some testing/traces to verify) when perhaps we might be better served (from both a QOS and toll perspective) if we could keep the trafiic local. Though there certainly could be instances where programmers intent was to send calls out the main site - there's more than a few instances where that's not likely the case.

Thanks everyone for all the help!!!!

--Dave

 

[simreal]

I guess I mispoke. I didn't mean location 1 uses the master table. I meant to say we dont use location 1 for any of our sites. For similar reasons we dont use vector.

We simply don't want there to be any confusion as to what site uses what ars entries.

the master table is a catch all. In the master table we generally deny everything.

In our config if your local site doesnt have the proper ars entry to allow your call then it gets denied by the master table.

That lets us take safer approach to call routing where we dont accidentally open the toll calling floodgates.