Access Pbx Ani & Dnis Value

[Guest Guest_Chris]

Hello,

 

We are using VG with a mitel sx2000 PBX via two D/82JCT-U PBX integration cards. For our application, we need to access both the DNIS (Caller ID) and ANI (Automatic Number Identification) values that are sent from the PBX. The $RV_CIDNUMBER var only returns the standard caller id string (DNIS).

Are there any additional TAPI vars that are returned that are not documented that *may* contain this information?

If not, can anyone suggest any way that I can get this info for each call? Is there a way that I can access TAPI or the Dialogic drivers directly and get this info for use in VG?

 

Thanks in advance,

Chris

[SupportTeam]

Could you please .ZIP up and post a copy of two logs from VG's \log\ subdirectory, this will allow us to see what is being sent.

 

When running the script click on VoiceGuide's View menu and select 'Event Trace Log' option. Then restart VG and make a call - the log files should now be created.

 

The log files you should .ZIP up and post are MMDDvgm.txt MMDDtw.txt (MMDD stands for current month and day).

 

BTW:

 

DNIS = Dialed Number Identification Service - it's the number the caller dialed.

 

ANI = Automatic Number Identification = CallerID - what number caller is calling from.

[Guest Guest_Chris]

Thanks for the quick response. I apologize for not being more clear with my terminology. The VG $RV_CIDNUMBER var is returning the pbx DNIS rather than the ANI. You'll notice in the logs that I am attaching that the CID is returning 5566. That is the extension that the call is received on. That works fine because we do dynamic script routing based on the dnis. What we need is the ANI value so that we can accurately trace the lifespan of a caller.

 

If the information doesn't exist in a VG var, is there anything progmatically that we can do to retrieve this info?

 

Thanks again,

Chris

0512_logs.zip

[SupportTeam]

From the logs we see that CallerID is sometimes reported as 5566 and sometimes as a 10 digit number.

 

I'd suggst looking at the MMDDtw.log's entries with "ocxev CallerId" in them. Some of these entries in log file you provided are:

 

021625.671 ocxev CallerId(sLineId=5, hCall=0x10091, strNbr=[5566], strName=[ ], strDialed=[7259])

021953.859 ocxev CallerId(sLineId=5, hCall=0x10020, strNbr=[3232359962], strName=[ ], strDialed=[7259])

022141.171 ocxev CallerId(sLineId=6, hCall=0x10202, strNbr=[5566], strName=[ ], strDialed=[7256])

023014.062 ocxev CallerId(sLineId=7, hCall=0x1031d, strNbr=[5566], strName=[ ], strDialed=[7272])

023335.703 ocxev CallerId(sLineId=7, hCall=0x100b4, strNbr=[7188121392], strName=[ ], strDialed=[7272])

023407.421 ocxev CallerId(sLineId=7, hCall=0x10092, strNbr=[5566], strName=[ ], strDialed=[7272])

023407.421 ocxev CallerId(sLineId=7, hCall=0x10092, strNbr=[5566], strName=[ ], strDialed=[7272])

035208.609 ocxev CallerId(sLineId=11, hCall=0x100d3, strNbr=[6628343021], strName=[ ], strDialed=[7252])

042038.421 ocxev CallerId(sLineId=12, hCall=0x10023, strNbr=[8175143206], strName=[ ], strDialed=[7251])

 

What we are seeing here is that the PBX is sending "5566" as the CallerID - and that the DNIS is sent as "7259" or "7256" or "7272" etc...

 

You should decide which values you want to use but basically we can ensure that both numbers sent by the PBX are available to you in your script.

 

The first value is available right now as $RV_CIDNUMBER

 

To access other value you will need to update your v5.2.2 installation with attached patch.

 

Unzip attached file and place OCX in Windows' System 32 directory, and then place .EXE in VG's directory. Start VG again and you will be able to access the second number using:

 

$RV[DNIS]

 

in your scripts. If something does not work please post both traces again and we'll look at it.

v5.2.2_DNIS_patch.zip

[Guest Guest_Chris]

Thanks again for the help. I added the update and now I am getting the DNIS.

I did more research and found out that the Mitel sx2000 system sends the *real* calling number via In-Band signaling. On the operator's phones, the real number only appears AFTER the phone is answered. So now I just need to determine what and how the information is sent.

 

If the information is sent as either digital in-band signaling or out of band signaling, is there any way that I can access that information using VG?

 

Thanks again for all of the help.

 

Chris

[SupportTeam]

Mitel sx2000 system sends the *real* calling number via In-Band signaling.

The PBX can only pass on the calling number that was reported to it by the phone company.

On the operator's phones, the real number only appears AFTER the phone is answered.

Looks like that's what the Mitel's phone handsets are configured to do.

 

The D82JCT reports both CallerID and DNIS at the same time, as soon as the call arrives, (you can see this in the traces).

If the information is sent as either digital in-band signaling or out of band signaling, is there any way that I can access that information using VG?

If you need to classify how it is sent then you'd probably say it was "digital out-of-band", but I guess all that's important to know here is that both CallerID and DNIS are available as soon as the call arrives, before the call is even answered.

[Guest Guest_Chris]

The PBX can only pass on the calling number that was reported to it by the phone company.

 

Agreed. What my Mitel system is reporting however is the hunt group extension that the call is sent to as the ANI (i.e. 5566), and the phone extension the hunt group distributes the call to as the DNIS (i.e. 7259). After the phone is answered, the pbx then sends the telco caller id (originating phone number).

 

After more research, I was able to find the function d42_display() in the Dialogic drivers. This function returns the telco information that would appear on the phone display AFTER the call is answered. My intial thought was that I could create a small prog that I would call after VG answers and retrieve the info from that function. No go. As you probably already know, accessing the same port by different processes causes problems.

 

So now, I'm back to trying to retrieve the out-of-band information. Is there any way that I could either access the out-of-band info via VG or access the d42_display() Dialogic function via VG?

 

Thanks again,

Chris

[SupportTeam]

Mitel system is reporting however is the hunt group extension that the call is sent to as the ANI (i.e. 5566), and the phone extension the hunt group distributes the call to as the DNIS (i.e. 7259)

sometimes we see what you describe above and sometimes what appears to be the full telephone number being reported, as per the traces we showed before:

021625.671 ocxev CallerId(sLineId=5, hCall=0x10091, strNbr=[5566], strName=[ ], strDialed=[7259])

021953.859 ocxev CallerId(sLineId=5, hCall=0x10020, strNbr=[3232359962], strName=[ ], strDialed=[7259])

022141.171 ocxev CallerId(sLineId=6, hCall=0x10202, strNbr=[5566], strName=[ ], strDialed=[7256])

023014.062 ocxev CallerId(sLineId=7, hCall=0x1031d, strNbr=[5566], strName=[ ], strDialed=[7272])

023335.703 ocxev CallerId(sLineId=7, hCall=0x100b4, strNbr=[7188121392], strName=[ ], strDialed=[7272])

023407.421 ocxev CallerId(sLineId=7, hCall=0x10092, strNbr=[5566], strName=[ ], strDialed=[7272])

023407.421 ocxev CallerId(sLineId=7, hCall=0x10092, strNbr=[5566], strName=[ ], strDialed=[7272])

035208.609 ocxev CallerId(sLineId=11, hCall=0x100d3, strNbr=[6628343021], strName=[ ], strDialed=[7252])

042038.421 ocxev CallerId(sLineId=12, hCall=0x10023, strNbr=[8175143206], strName=[ ], strDialed=[7251])

What is different between the calls which show you the full number and the calls which show you the hunt group extension?

Are the numbers "3232359962", "7188121392" etc CallerID numbers or something else?

[Guest Guest_Chris]

What is different between the calls which show you the full number and the calls which show you the hunt group extension?

Are the numbers "3232359962", "7188121392" etc CallerID numbers or something else?

 

Yes. Those are CallerID strings. The reason they show up in the trace logs is due to a misconfiguration on our part. For that log, after-hours calls were being misrouted to the IVR when they should have been sent to an alternate extention. If you notice, the call times are between 2am and 7am only for the calls displaying the actual callerID strings.

I apologize for not being clearer when I posted the logs.

[SupportTeam]

I guess the immediate question is: can you set up the PBX in the way so that all the calls send to IVR are sent in the same way as these 'misrouted' calls - looks like the PBX then provides the correct CallerID before the call is answered - which is much more preferable to getting the CallerID only some time after the call has been answered...

 

Right now VG does not call the d42_display() function after answering the call - it would not be very hard to add this feature, but looks like you should be able to set up the PBX so that this is not needed...

 

All PBXs should be configurable to present CallerID before the call is answered - it's a very basic feature that all PBXs support. Maybe you shoiuld speak with the PBX supplier to see how this should be configured.

[Guest Guest_Chris]

First off, let me thank you for all of the attention that you have given to this issue. I realize this is not a standard problem, so the participation by VG support in this thread shows just how commited you are to your customers. Thank you.

 

I guess the immediate question is: can you set up the PBX in the way so that all the calls send to IVR are sent in the same way as these 'misrouted' calls - looks like the PBX then provides the correct CallerID before the call is answered - which is much more preferable to getting the CallerID only some time after the call has been answered.

 

Yes I can set this up. Unfortuntely this isn't the optimal solution. Knowing the calling hunt group (ie 5566) is critical to accurate call routing. If I were to remove that, then I would be unable to dynamically route calls through the IVR. There are also other systems in place that rely on this information that would be adversly effected by a change. In other words, this is by design.

 

At this point, the only choices I have is to either capture the out-of-band data, or grab the display() var.

 

Rather than have customer bother VG for product enhancements, would it be possible to eventually either release the source for the tapiWrap OCX or allow a mechanism for plug-ins? I'm sure many ppl here would be happy to code extensions to VG and possibly post them to a "User Utility" section of your site.

 

Thanks again,

Chris

[SupportTeam]

choices I have is to either capture the out-of-band data,

What out-of-band integration does this PBX offer? SMDI or something similar?

This will probably be the way to go on this system.