Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Legend to Voicemail ANI via DTMF

Status
Not open for further replies.

JaredMTSG

Programmer
Sep 3, 2009
1
US
Hello.
We recently moved from Octel to a Unified Messaging system connected to the same ports off a Merlin Legend R7. We have a PRI for incoming lines. The UM system provides auto attendant and voicemail services, similar to the Octel. We have found that when calls come in and are covered to the UM, we are not seeing the calling number get passed to the voicemail. Instead, if we check the inband DTMF after a missed-call/no-answer, we see #02##xxx# (where xxx is the called party extension) get passed to the UM. No Calling Party ID. For an inbound call, we typically do see the caller ID show up on our phones, so I know that the service is working on the PRI itself.

There are a few places such as Avaya Config Note CN5026 ( that refer to the need to set the "ANI Feature Bit" on the PBX in order to get ANI information... Is that something I need to do to enable this functionality? If so, how would I go about doing that?

Any help anyone could give would be greatly appreciated! Thanks.

-- Jared
 
First thing to understand is that ALL calls will be prefaced by either #02 or #03 (depending on whether it is an inside or outside caller). These "mode codes" are passed as DTMF to any analog stations assigned in the covering Calling Group provided that the Calling Group is of type "Generic VMI" or "Integrated VMI"; either will do the trick.

What you are seeing is not at all unexpected.

Tim Alberstein
 
First of all, PRI provides CID, NOT ANI. They are NOT the same thing even though the number contained may be the same. The only type of service that provides ANI to customer systems is 800 MEGACOM or equivalent, and is provisioned from a Class 4 office on CAS DS1 service.

Now for the Legend/Magix, PRI does provide CID to system phones only. It is not available from analogue station ports, and Avaya never made any upgrades to the analogue station modules 012 and 016 or 008OPT for CID. All Voice Mail systems connect to the Legend/Magix via analogue ports. The VMI config for calling groups says nothing about CID that I could find. So there won't be any! It is NOT available.

The Avaya config note you mention is not accurate and does not apply to the Legend/Magix in regards to CID per the above paragraph. Also in the Feature Reference I could find no explanation for any passing of CID info to the VMI calling group. It is not mentioned at all. The definition of ANI in the Feature Reference is not complete or very good. The tech writer did not understand the feature and difference.

Hope this helps!

....JIM....

 
Jim, I am totally with you on the ANI/CID thing (and I suppose I should throw in DNIS, LIDB and CNAM). I find myself privately irritated by those who chronically misuse these terms.

Having said all that, I also have to say that 'I blew it' by responding at 2:00 a.m. I falsely jumped to the conclusion that the poster was concerned about the dialed party information...you know, the stuff you need to parse out for fax-to-email or similar applications.

So with a little sleep under my belt, I now have the confidence to emphasize and reaffirm several things:

1. CID is passed to Merlin Messaging but not ANI. If you want/need to hear the calling party number in the message header, you will have to assure that the inbound call arrives on a loop-start analog trunk rather than your PRI. Though it's possible that this "ANI feature bit" exists, I've never come across it in software. I'll dig through my notes on the Monitor function, but I'm pretty sure there's nothing there either.

2. The #nn##ext# code is sent via DTMF to analog stations that are members of a Generic or Integrated VMI hunt group. The Automated Attendant plays for calls with the #01## prefix, while the mailbox-specific message is played for calls signaled as #03##ext#. Ever wonder how voicemail systems knew when to be an Attendant versus it's other roll as a Call-Answer mailbox? Now you know.

3. Jim is a heluva smart cookie. I am too, provided that I'm not fighting insomnia from a stressful day. :0)


Sorry bro, but that's the straight story on this stuff.

Tim Alberstein
 
Hi Tim, I guess we were both up late. I was checking some references before I submitted my post. Mine would have posted about the same time as yours, but that Avaya config note got my curiosity! So I continued digging in the Feature Reference. I guess some one @ AT&T or OCTEL had some great plans for CID that never materialized, since I consider the PRIMARY ISDN incomplete for the Legend/Magix compared to other PBXs of the time.

Yes, proper use of terms and their meanings is a constant challenge in this industry, whether it's the manufacturers, techs or the public! But I won't go there in this thread...
LOL

....JIM....
 
I have a Legend switch R7. I have an R4.4 Intuity Audix that I spent a lot of time programming. The problem is that when the auto-attendant answers and then transfers to an extension....the default message plays but the Intuity doesn't hang up.
Even on the system monitor it shows that it is adding. I set the ports to DNIS and to AUDIX and the same results happen.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top