My JTAPI application is monitoring for when extensions have a CallForward instruction set in real-time.
In code, I am using the TsapiAddress#addAddressListener method, and implementing the addressForwarded event accordingly.
On a terminal when I set/unset a call forward - an event is indeed triggered, but when I parse the objects returned by CallControlAddressEvent#getForwarding or TsapiAddress#getForwarding the destinationAddress is set to null (understandable if an unset).

I tried polling the address in a background thread to see if the value is eventually available, but it seems not.
Bizarrely, if my application terminates and creates a brand new Provider whilst a forward is still active - the replay events *do* have the right data. Any thoughts on might be going wrong would be greatly appreciated.


Many thanks.

Marcus

Hi Marcus,

JTAPI uses the TSAPI API on AE Services so it is often useful to take a look at "TSAPI for Avaya Communication Manager Programmer's Reference". It includes the following statement in the Forwarding Event section:

"Currently, AE Services does not provide the forwarding destination in the Forwarding event. However, applications may use the cstaQueryForwarding() service to determine the forwarding destination for a device where call forwarding is active."

So this explains why you do not get the destinationAddress in the addressForwarding event. It is simply not provided by AE Services. In fact, I think it is not sent by Communication Manager to AE Services.

You also asked why getForwarding() does not provide the destinationAddress. From what I can see, the JTAPI does not actually make a cstaQueryForwarding() request when the application calls getForwarding(). It simply returns the values it has cached locally. If you change the forwarding state using setForwarding(), getForwarding() will return the correct value.

Your third question was why, after starting a new provider, getForwarding() does return the destinationAddress. When an application puts a listener on a station, JTAPI makes some requests to AE Services to get the initial state of the station. One of these is cstaQueryForwarding(). When you restart the application, it, presumably, also starts a new listener on the station and hence the destinationAddress is available.

Martin

Hi Martin - Thanks for your swift reply.

I don't think the ecsjtapia Java API is quite suited to this need...at least it seems overly difficult, so I may be doing it wrong!
If you can point me in the direction of any sample code for how to construct low level csta queries, that would be great.
That said - with a bit of a cludge for now I have managed to prove in code that your suggestion works and I can now see the destination numbers coming through, so thankyou for that.

A follow up question if I may - I get different behaviour from Enhanced Call Forwards
In real-time addressForwarded events:
- I don't get the destinationNumber even with the workaround implemented.
- The forwardType (unconditional/busy/noreply) and filter (internal/external/both) values also don't appear to reflect what is set on the terminal.
- When a new provider is instantiated - I don't seem to get any replay events for them at all.

Is this again a limitation of what is communicated between CM/AES?

Many thanks in advance,

Marcus

Hi Marcus,

Take a look a the DMCC Java SDK. It provides all the features of JTAPI (as well as a lot of other stuff). It does not impose the complex object model that JTAPI does so you may find it easier to use.

Martin