Message |
[+]
JTAPI
» 9611 SIP Avaya Phone with AES TSAPI/JTAPI, 29/06/2020 00:38:49
» Go to message
|
|
Hi John,
Here is the CSTA Trace from AES Server -
---------------------------------------------------------------------------------------------------------------------------------------------------
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 InvokeID: 760
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 Driver: AVAYA#CM#CSTA#AURA8AES
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 Message:
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 value CSTAAnswerCall ::=
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 {
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 alertingCall
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 {
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 callID 3,
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 deviceID "6001",
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 devIDType staticId
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 }
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40 }
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 644 1 com.avaya.aes | csta_trace:Thread 0xd32d3b40
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 TSERVER Src: DRVR
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 Login: "testtsapi" App Name: "Jtapi Client" SessionID: 6 Transport ID: 10.81.234.6
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 InvokeID: 760
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 Driver: AVAYA#CM#CSTA#AURA8AES
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 Message:
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 value UniversalFailureConfEvent ::=
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 {
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 error networkOutOfService
<135>Jun 29 11:01:26 aura8aes TSAPI[12092]: +05:30 2020 705 1 com.avaya.aes | csta_trace:Thread 0xd5ad8b40 }
------------------------------------------------------------------------------------------------------------------------------------------------------
Regards,
Umesh
|
|
[+]
JTAPI
» 9611 SIP Avaya Phone with AES TSAPI/JTAPI, 26/06/2020 10:46:43
» Go to message
|
|
Thanks John.
I will follow instructions.
Regards,
Umesh
|
|
[+]
JTAPI
» 9611 SIP Avaya Phone with AES TSAPI/JTAPI, 26/06/2020 09:47:57
» Go to message
|
|
Hi John,
We are not using SES (SIP Enablement Services). I just asked without I was going through Avaya documents on Internet.
Our setup is Avaya Aura CCElite 8.0 and SIP phones are registered with Session Manager.
I will enable trace on AES as suggested by you and will try to find out the log details.
I am attaching document which I followed to configure SIP phones for AES. Is there any other settings or document which can be useful to resolve the issue.
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» 9611 SIP Avaya Phone with AES TSAPI/JTAPI, 26/06/2020 01:12:13
» Go to message
|
|
Hi John,
Thanks for reply.
I have also tried with Avaya JTAPI Exerciser and error is same i.e. CSTA Error: 36.
I have done lots of work with Cisco & JTAPI (have good experience about Cisco CM & UUCE/UCCX related configuration) and I am doing first time with Avaya. Working on CRM & Avaya CC Elite Connector project.
Can you tell me one thing, Is there any use of "SIP Enablement Service(SES)" component if I am monitoring/controlling Avaya SIP phone.
Note :All features(Answer/disconnect/MakeCall/Hold/Resume/Consult/Transfer/Conference) of Connector works fine for Avaya H.323 phones.
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» 9611 SIP Avaya Phone with AES TSAPI/JTAPI, 24/06/2020 23:22:51
» Go to message
|
|
Hello,
Regarding our earlier post about SIP phone support with AES.
We are using 9611 Avaya phone with SIP. Following are the setting we have done for station setting-
Type - 9611SIPCC
IP Softphone - Y
Type Of 3PCC Enabled - Avaya
Now we are able to do following action using AES JTAPI API -
- Login & Logout agent on SIP Phone
- Able to change agent state from READY to NOT_READY & NOT_READY to READY.
- Getting events for any call activity on station
- Able to disconnect call using JTAPI API
Things which are not working and we are getting "CSTA Error:36" when try to do following -
- Answer using JTAPI API
- HOLD/Resume
-Consult
Can you please suggest what could be the reason?
As per documentation CSTA Error:36 is OutOfService error but we are getting event for the call and if we answer the call from 9611 phone then we receive event for the same.
Here is the details of CSTA Error:36
• NETWORK_OUT_OF_SERVICE (36) (CS3/38)
– The adjunct route request to route using NCR resulted in the call not being routed by NCR because the NCT contained an invalid PSTN number, and the second leg cannot be set up.
– The adjunct route request to route using NCR resulted in the call not being routed by NCR because of a PSTN Network Call Deflection (NCD) network error.
– The adjunct route request to route using NCR resulted in the call not being routed by NCR because of a PSTN NCD no disc error.
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» Avaya 9611 SIP Phone CTI Event Monitoring using AES TSAPI/JTAPI, 01/06/2020 08:53:17
» Go to message
|
|
Hi,
We are developing CTI Event Monitoring application for CC Elite using Avaya TSAPI/JTAPI. We are unable to perform agent Login/logout and able to get CTI event for Avaya H.323 phone.
But for SIP we are unable to perform activity. Actually we ask extension number from agent on which agent is trying to login and application get Address using JTAPI provider.getAddress("6001") function where 6001 is extension configured on Avaya 9611 SIP phone.
JTAPI getAddress function throw exception "could not create terminal: 6001; device is not a terminal".
Can you please suggest the steps to resolve above issue? Do we need to perform any specific configuration on AES/CM to monitor SIP phone?
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» List of Avaya Phones Supported by AES JTAPI, 29/05/2020 10:33:03
» Go to message
|
|
It will be very helpful if any Avaya AES expert can post reply.
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» List of Avaya Phones Supported by AES JTAPI, 26/05/2020 23:47:25
» Go to message
|
|
Hi,
Is there list available for AES JTAPI supported Avaya phones? Can you please confirm out of below which are the hard phones/soft phones supported by AES JTAPI -
-14XX Series phones
-16XX series phones
-95XX series phones
-96XX series phones
-OneX Communicator
-OneX Agent
-ContactPro
-Equinox
It's better if there is any reference on Avaya site.
Thanks & Regards,
Umesh
|
|
[+]
JTAPI
» AgentState eventing!, 23/02/2020 22:06:00
» Go to message
|
|
Hi,
You will get agent state change event when there is change in Ready-> NOT_Ready or Not_Ready->Ready. But you will not get if there is multiple reason code configured for Not_Ready State and you are change to Not_Ready state from one reason code to another reason code.
It's better you implement polling and maintain last state of agent at server end and send event to browser only if there is change in state.
Regards,
Umesh
|
|
[+]
JTAPI
» AES connector: Initializing failed [SOLVED], 23/02/2020 21:59:40
» Go to message
|
|
Hi,
Can you first check with CSTA option, in place of CSTA-S?
Regards,
Umesh
|
|
[+]
JTAPI
» JTAPI application disconnects multiple times in a day, 12/01/2020 23:11:55
» Go to message
|
|
Hi John,
We also experience inconsistent event (in case of disconnect) with Avaya AES JTAPI e.g. if station1 and station2 are in call and anyone drops the call application shouuld receive connectionDisconnect & terminalConnectionDropped event for monitored station/s. But sometime application receives and sometime not.
Is there any link where we can find the open issues with AES platform?
Regards,
Umesh
|
|
[+]
JTAPI
» Transfer Using Phone (Not Using API) Steps & JTAPI Event, 06/01/2020 07:18:29
» Go to message
|
|
Thanks Martin.
Sample code from AgentViewer may help. We will try following code tomorrow-
private void handleCallCtlConnDisconnectedEvent_TransferCause(
CallControlConnectionEvent connEvent, CallManager callmanager) {
Call call = connEvent.getCall();
long callID = CallUtilities.getCallID(call);
String droppedDeviceID = callmanager.getDeviceID(call,
connEvent.getConnection().getAddress().getName());
Connection[] conns = call.getConnections();
// If there was only one connection in the call, the call has now
// ended
if (conns == null || conns.length < CallManager.MIN_CONN) {
callmanager.updateCall(callID, ConnectionState.Null,
null, null, null, droppedDeviceID);
return;
}
// Retrieve the old call that was transferred
long oldCallID = CallUtilities.getOldCallID(call);
String oldDroppedDeviceID = CallUtilities.getOldDeviceID(call);
/*
* Determine the device to which the call is transferred.
* If the call is answered before transfer is completed, it is the stored
* calledDevice. In the case of blind transfer it is the device which
* is alerting.
*/
String newDeviceID = null;
if (callmanager.hasCall(callID)) {
newDeviceID = callmanager.getCall(callID).getCalledDeviceID();
} else {
if (conns[0].getState() == Connection.ALERTING) {
newDeviceID = conns[0].getAddress().getName();
} else {
newDeviceID = conns[1].getAddress().getName();
}
}
// Inform the UI that the call is transferring. This shows the ID of
// the old call, the device transferring and the device being
// transferred to.
callmanager.updateCall(oldCallID, ConnectionState.Transfered,
CallState.INVALID, null, newDeviceID, oldDroppedDeviceID);
}
Regards,
Umesh
|
|
[+]
JTAPI
» How To Identify if a call is consult call or normal call from connectionEstablished event, 06/01/2020 06:42:29
» Go to message
|
|
We tried with OCI but problem is we are not getting CallId from OCI. It's returning 00000000000000000000
[2020-01-06 15:32:53,554][DEBUG][connectionEstablished][207][00000000000000000000
Regards,
Umesh
|
|
[+]
JTAPI
» Transfer Using Phone (Not Using API) Steps & JTAPI Event, 06/01/2020 01:18:28
» Go to message
|
|
Hi,
We have 2 phones on which 2 agents are logged-in.
Agent 1 - id=2001 , Ext=1010
Agent 2 - id=2004, Ext=1003
Our Case is -
- Dial IVR, after initial input call call reaches to agent 1 (CallID-1)
- agent 1 answer call (CallID-1)
- agent 1 presses Transfer key on phone and enters agent 2 ext(1003) (CallID-2)
-agent 2 answer call (CallID-2)
-agent 1 presses Complete key on phone
-Customer & Agent-2 connected (CallID-1)
After "Complete" key press following event should be received by JTAPI application-
-terminalConnectionDropped for CallId-1
-terminalConnectionDropped for CallId-2
-terminalConnectionTalking for CallId-1 i.e. first call id after transfer complete.
But application never receives terminalConnectionDropped for CallId-2.
Can you please confirm above behaviour?
PS: Even though OldCall Ids are wrong in multiCallMetaTransferEnded event -
2020-01-06 13:50:04,859][DEBUG][multiCallMetaTransferEnded][NewCallId : 00001002271578318387][NoOfOldCalls : 2][Old CallIs : 00001002271578318387
[2020-01-06 13:50:04,859][DEBUG][multiCallMetaTransferEnded][NewCallId : 00001002271578318387][NoOfOldCalls : 2][Old CallIs : 00001002271578318387
Regards,
Umesh
|
|
[+]
JTAPI
» How To Identify if a call is consult call or normal call from connectionEstablished event, 06/01/2020 01:05:50
» Go to message
|
|
Hi Martin,
We are using JTAPI so for consult call we are calling consult and for normal call we are using connect API.
In case of Telephone/One-X, while transferring call we can use "Consult Transfer"/Transfer.
We are finding event synchronization/missing issue when doing some activities from phone e.g. if agent starts transfer activity from phone and Completes transfer from phone. I this case there is no Drop event for Second Call.
Regards,
Umesh
|
|