View Single Post
  #2  
Old 08-14-2018, 07:39 AM
davis124 davis124 is offline
Brainiac
 
Join Date: Oct 2011
Location: Omaha, NE
Posts: 50
davis124 has 12 reputation points
Default

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
Attached Images
File Type: jpg Calltype Analysis_Small.jpg (22.5 KB, 10 views)
__________________
James E. Davis
10 years at Lucent/Avaya as a System Application Specialist
4 years at Avaya as a TIER III Engineer
Now working for UNMC as a System Admin/VoIP Engineer
Reply With Quote