Thank you both for your suggestions. I will see where they lead.

We have a customer that has an Avaya Experience Portal in addition to the Communication Manager. I am using JTAPI to monitor the Communication Manager. It seems as though when a call arrives on a trunk, the Communication Manager hands the call off to some other thing, which I think might be the Avaya Experience Portal, and then that other thing sends the call back to the Communication Manager to be delivered to an agent but when the call is sent back it has a different UCID than then the one it was sent with. How can I correlate the two UCIDs or otherwise tie the original call with the call answered by the agent?

I am developing an interface to an IP Office system using IP Office CTI WebServices. I am having some problems reconciling the behavior of the system with the documentation.

1) The Avaya engineer who set up the system swears that the user ID set up for our use is an Application User, however, the response payload does not contain any "devices" sections.

2) After subscribing to the WebSocket, the IP Office system terminates the WebSocket connection after six minutes.

In section 4.3.3 Heartbeat, the documentation states:

For Application Users ending (sic) a heartbeat request is not required. The session for an Application User will remain activated as long as one-X Portal server is running and that Application User does not explicitly logout.

In section 4.3.4 WebSocket Heartbeat, the documentation states:

Heartbeat option has been added for websockets.

This option is enabled by appending 2 additional request parameters clientName and clientVersion to the websocket URL. Both the request parameter should be appended to the websocket URL for enabling the heartbeat option.

When the client chooses to enable the heartbeat option then it should send at least one heartbeat message over the websocket every 30 seconds. If the heartbeat message is missed then the websocket is closed by the server.

The heartbeat message can be any string.

Based on that, I should not need to send a heartbeat as I am not including the clientName and ClientVersion in the URL.

The sample in WebSocketService.cs sends the string "heartbeat" every 10 seconds. I have implemented something similar and find that the subscription is still terminated after six minutes with a WebSocket status 1000 (Normal Closure) and the message, "Closing web socket on stopApplicationSession".

I cannot find anywhere in the documentation mention of a subscription duration or WebSocket closing status codes or "stopApplicationSession".

I would really appreciate some assistance with these issues.

That does the trick, even when what I am monitoring is the VDN and not the individual extensions.

The key is that there are two TermConnActiveEv events generated, the first for the caller,and the second for the answerer.

Thanks to you both!

Thanks. I'll give that a try.

I see the following in the JTAPI debug log:

Received monitorCrossRefID 7 for TSProvider[#1]@1befab0
CSTAEstablishedEvent :::
{
establishedConnection
{
callID 4397
deviceID '10125'
devIDType 0 < STATIC_ID >
}
answeringDevice
{
deviceID '10125'
deviceIDType 55 < EXPLICIT_PRIVATE_LOCAL_NUMBER >
deviceIDStatus 0 < ID_PROVIDED >
}
callingDevice
{
deviceID '9512219697'
deviceIDType 20 < IMPLICIT_PUBLIC >
deviceIDStatus 0 < ID_PROVIDED >
}
calledDevice
{
deviceID '10355'
deviceIDType 55 < EXPLICIT_PRIVATE_LOCAL_NUMBER >
deviceIDStatus 0 < ID_PROVIDED >
}
lastRedirectionDevice
{
deviceID '10355'
deviceIDType 55 < EXPLICIT_PRIVATE_LOCAL_NUMBER >
deviceIDStatus 0 < ID_PROVIDED >
}
localConnectionInfo -1 < CS_NONE >
cause 22 < EC_NEW_CALL >
}

How do I retrieve the answeringDevice, and from what event do I retrieve it?

That did the trick. Thanks!

I have an existing telephony interface that supports both ASAI and CSTA that I am converting to JTAPI. In ASAI, there is an information element called "Call Identity" which is delivered with various call events. In CSTA, the equivalent is the callref. I was assuming that the equivalent in JTAPI can be found from getUCID, but all I get is "00000000000000000000" if anything. I am doing this in the event handler:

call = ( (CallCtlCallEv) event).getCall();
if ( call instanceof LucentV5CallInfo ) {
callRef = (( LucentV5CallInfo) call).getUCID();
}

I know the data must be around somewhere because I get messages like "TSDomainTracker/TSProvider[#1]@5db5ae: removeCallFromDomain: cid 7321 was not in any domain - no action taken" in the console window.

Inbound calls to a particular number are routed to a VDN. I have set up CallObservers on the stations as well as the VDN. I am receiving call control events when the call is routed to the VDN, but not to the station that gets and answers the call. How do I get those call events?