Avaya Support Forums  

Go Back   Avaya Support Forums > Telephones, Adjuncts, and Adapters

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 07-13-2018, 02:54 PM
davis124 davis124 is offline
Brainiac
 
Join Date: Oct 2011
Location: Omaha, NE
Posts: 50
davis124 has 12 reputation points
Default Best Practice for H.323 Phones for using Redial/Contact/Call Log lists for dialing

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
Reply With Quote
  #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, 3 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
Reply

Tags
call log, contacts, h323, redial

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:20 PM.

This Forum is provided solely for the use and convenience of Avaya customers and partners. Use of the Forum is subject to the Terms and Use and Privacy Statement found at www.avaya.com. No other use is permitted. The Forum including all content posted is “AS IS” and Avaya expressly disclaims all warranties and/or guarantees as to its accuracy, reliability, usefulness, quality or non-infringement of intellectual property. Avaya reserves the right to remove any content posted on the Forum at any time and for whatever reason.

Avaya will not be liable for any content posted on this Forum, including, without limitation, any errors or omissions or for any losses or damages of any kind incurred as a result of use or reliance on any content, regardless of its origin.

You expressly understand and agree that you assume all risks associated with use or reliance on this content.