Hi,

Our company verifies the CTI coming from AES and uses it to make a decision about the call. I'm trying to write a SIPP script to emulate an Avaya phone. The goal is to automate the CTI testing.
So there are two scenarios:

1- Inbound: From a non-monitored station to a monitored station.
2- Outbound: From a monitored station to a non-monitored station.

Assumption: 22300 extension is monitored
22700 extension is not monitored

In the Inbound scenario, I make a call using SIPP from 22700 to a listening SIPP 22300. Server gets the correct CTI:

[20300] Updating AvayaCall [CTICall [id=8986, hybridCallID=null, localParty=20300, remoteParty=20650, agentID=null, nativeCallIDs={UCID=00001089861530195720}, parties=2, isRecording=false, isHeld=false, isTalking=true, isEnded=false, session=null, sessions=[], GUID=0eeb64c1-8489-46ef-a5cf-52141776f2b0], extension=20300, direction=INCOMING]

In the outbound scenario, the call is successful, but the CTI is not correct:

 [20300] Updating AvayaCall [CTICall [id=8998, hybridCallID=null, localParty=20300, remoteParty=null, agentID=null, nativeCallIDs={UCID=00001089981530196121}, parties=1, isRecording=false, isHeld=false, isTalking=false, isEnded=false, session=null, sessions=[], GUID=558ef734-0980-428f-bd46-ff5a0ab05068], extension=20300, direction=INCOMING]

As you can see the remoteParty is null and the parties=1, and the direction is shown as INCOMING which is not correct
I solved this issue by adding Off-Hook flow to my outbound SIPP script:

---> INVITE - Off-Hook
<--- 100 Trying
<--- 183 Session Progress
...
...
<--- 484 Address Incomplete
----> ACK

By adding this flow, AES sent the correct CTI on the outbound call with remoteParty populated. And the direction is OUTGOING

 [20300] Updating AvayaCall [CTICall [id=9000, hybridCallID=null, localParty=20300, remoteParty=20650, agentID=null, nativeCallIDs={UCID=00001090001530196839}, parties=0, isRecording=false, isHeld=false, isTalking=false, isEnded=false, session=null, sessions=[], GUID=70622cab-1b9f-40f8-b21b-4073e0ce368d], extension=20300, direction=OUTGOING]

But unfortunately this can't be applied to the proxy we are using. The proxy doesn't like 4xx messages and whenever it receives 484 message it assumes it's the end of the Dialog. It only works when SIPP talks to the Avaya Session Manager directly.

My question: Why does AES needs the off-hook flow to generate the right CTI? And is it possible to disable this requirement?

Thanks,
Hamid Moghani
Cogito Corp

I am not familiar with that trace. What produced it?

This is the trace of our product. It's just an interpretation of the CTI event we get from AES.

here are some logs I could get. There might be some log messages in between that is "our product" logs. Any logs with DEBUG level label is from the "Event" from AES.

For the outbound case, Communication Manager informs that 20300 originated a call to 20650 but there are no more messages until the call is cleared, 2 seconds later. So AE Services has no indication that the call has been answered.

Is 20300 an Avaya phone? TSAPI/JTAPI is only supported with certain Avaya SIP phones. These are listed in the AE Services Overview document.

Martin

None of them are Avaya sip phones. Both are SIPp endpoints. As I mentioned, we are trying to automate our CTI testing. So the goal is to send and receive calls with SIPp call emulator through Avaya, then Avaya generates the CTI and then we verify the CTI.

TSAPI/JTAPI is only supported with Avaya SIP phones.

I would suggest that you configure the stations as H.323 and register them as DMCC terminals. You can then use the DMCC terminals to make/receive calls.

Martin