Best Practice for H.323 Phones for using Redial/Contact/Call Log lists for dialing

[davis124]

So this is going to be a bit long winded so I applogize for that now...



Many years ago we setup our site to allow the IP Phones to be able to call directly out of their Call Log/Redial/Contact lists without have to manipulate what they were dialing. The way we did this was add entries into our Calltype Analysis table that would reflect the first digit that would be sent from the IP Phone (We have 10 digit out dialing into CenturyLink in our area). From there we manipulated if it was a Local or LD Call. If the IP Phone sent a 5 digit number (Which is our internal extension range) CM would process it accordingly.


This worked great for us, we could use the IP Phones as they were intended to, BUT NOW we have a change coming to our environment that is causing a disturbance in the force!


We are going to move to 10 digit internal extensions, we already have a few sites that are 10 digit dial today, and in testing we have uncovered that when an IP Phone uses the Redial/Call Log/Contact List for those sites, instead of CM Treating them as Local Extensions (Which they are clearly spelled out in our dial plan now), CM is trying to apply Calltype Analysis to it, and route as an outbound call, which as you can guess is causing major issues.



So now we find ourselves at a crossroads, we don't have enough space in the Calltype Analysis to define all of our Extension Ranges, and the only work around so far that we have found is to put ALL of our Extension Ranges in a ARS Digit Conversion Table and spell it out there as an Extension (Which will be a pain in the *** for us as we don't have continuous blocks of DID Ranges)


I am wanting to know a few things from the groups:



1. Has anyone else ran into this problem before, and if so was the ARS Digit Conversion the only way you fixed it?

2. What is Avaya's best practice on setting up a H.323 Phone for dialing out its Contact/Call Log/Redial list?

3. Any other ideas I might have missed?



Thanks again for any help you can offer,

James E. Davis

[davis124]

So I wanted to update this forum just in case others find themselves in this situation... we figured out a better work around then adding all of our extensions in the ARS Digit Conversion table as recommended by our vendor. The key is using the Calltype Analysis table and understanding what it can do, I am still learning this feature as we speak but it's been pretty valuable. Before I talk about what fixed my problem I just want to give a 10,000' over view of what the Calltype Analysis table is used for:



Avaya IP Phones before CM 5.x used the 46xxsettings.txt file to tell the phones how to handle calling out via Logs/Redial/Contact Lists. This worked for some people, but there was some inherent problems with it (In my opinion).

So CM 5.x introduced the Calltype Analysis table, which allows CM to control how the IP Phones will handle calling out via Logs/Redial/Contact Lists. The civet of this is, the table must be filled in before the IP Phone registers, or the IP Phone will not be aware of the list until its next reboot. Also, examples on how this field works, was a bit space at best.



So in my example, we had already defined any single digit, would have a 1 attached to it and treated as an ARS Call (Inserting the ARS Code). Then for our local area codes (For us 402, 531, and 712) would match, and be told to treat it as a Local ARS Call. This is where the phone was picking up our new 10 digit numbers (Extensions) and still trying to route them as outbound calls.

So where Avaya falls down is explaining how the fields work - There are 4 options per entry. I finally found an Avaya Article that talked about how this particular customer had set it up and how it really worked, and that pointed me to this, the 4 options are the order of operation.



So in my example we defined 402 as a local call (By spelling out 402 specifically), but we had to put EXT as the 1st Match, and if it doesn't match on an extension, then the 2nd Match routes the 402 call as a local call.

So remember this with Calltype Analysis, it's an Order of Operation, and if the 1st point doesn't match it moves onto the 2nd point. (I have attached a photo of what this looks like)


Hope this helps others who might be suffering through this!



James E. Davis