Hi,

The CTI system which connects to AES using JTAPI is receving "dynamic device identifier" instead of the Caller Number.

We would like to know if this is a configuration issue?


Thanks!

Hi Jack,

Depending on your setup, this may be a configuration issue.

If a trunk in the route between the Originating exchange and the Communication Manager is Analog or some other trunk type that cannot transmit Calling Party Number then your application will never receive Caller Number for it.

If all trunks being used are ISDN, SIP, H.323 or other trunk that can transmit Calling Party Number, an exchange along the route has probably disabled "Send Calling Number" on it's outgoing trunk. You will need to have that configuration changed. For example, on the Communication Manager this is controlled by the "change trunk-group", page 3, "Send Calling Number" parameter.

Martin

Hi Martin,

Thanks for the reply.

Actually we had further foundings.

We have checked AES TSAPI log, and noticed Caller Number can be retrieved.

If the IVR transfer the call to a VDN by blind transfer, we are able to see the Caller Number all the way till agent ends the call.

However if the IVR transferred the call to a VDN with step "adjunct route to link 1" using "attSingleStepTransferCall" function, the Caller Number will be replaced with "TXXX#1" at the "CSTARouteRequestExt" event.

Do you have any clue about this??


Many thanks!

Many of the messages from the Communication Manager to the AE Services do not contain the Calling Number. If the AE Services is able to match these messages with information already in it's call block then it is able to provide a Calling Number to TSAPI applications. However, there are several instances where this is not possible. For example:

o The AE Services was not monitoring the call early enough - eg. an unmonitored phone transfers to a monitored phone.
o The AE Services "loses sight" of the call. It may be that the AE Services was monitoring the call at the start but stopped monitoring it for some time and delete the call block. eg. A monitored phone (A) receives a call, and transfers it to an unmonitored phone (B). B then transfers the call to A. In this case the original call block was lost.
o The AE Services is unable to tell that a call is an extension of a previous call.

Without setting up the same call flow & configuration as you, I can't be sure what's happening here.

One thing that you may helpful is to monitor all VDNs in the flow. This will limit the opportunity for problems to occur.

Martin