Author Message
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
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

JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
I suspect you are misreading what error you are actually receiving. I suspect you are actually receiving an ACS Universal Failure code of 38. Error code 36 had to do with the adjunct routing service which you are not working with when making those service calls (answer, hold, retrieve, consult).

38 TSERVER_INVALID_MESSAGE TSAPI The TSAPI Service has received a message from the application or the driver that it does not recognize. Verify that the offending message is valid according to TSAPI.

Have you tried using the JTAPI Exerciser (it is bundled with the SDK) to invoke the problematic services? I would do so and enable TSAPI tracing on AES and compare the messaging received (in the csta-trace file from the Exerciser with those from your application and look for the difference.

I am not all that familiar with the sample applications included with JTAPI SDK but you could inspect them to see if any provided one or more of these services (I suspect one at least answers a call) and do some comparison with that.
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
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
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
Are you really working with SES (SIP Enablement Services)? and not System Manager/Session Manager?

If so -- that is very OLD stuff. SIP Enablement Services (SES) 5.0 (and later) introduced the ability to control Avaya SIP endpoints via TSAPI/JTAPI. Starting with release 6.0 Avaya switched from SES to SMGR/SM.

And yes there would be interactions with the SIP proxy (be it SES or SM), and a SBC if it is involved.

My suggestion retruns to enabling TSAPI tracing on AES and observing a bit more carefully what is occurring. If you are using SES we have little to no familiarity with product issues there. I would make sure you are up to date on patches for SES/SM/ASBC-E and ensure the SIP endpoint you are working with is using current firmware.
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
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
Filename Using96X1SIPphoneswithCCElite.pdf [Disk] Download
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp#10


Here is what I point people to who are having SIP / TSAPI issues as far as configuration The document you provided is nice, but it isn't focused on CTI.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/index.gsp#880
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
Thanks John.
I will follow instructions.

Regards,
Umesh
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
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
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
Thanks John for your hepl.
Today, our vendor has done some changes in phone settings file and now it's working fine.

Thanks Again.

Regards,
Umesh
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
<nice> <smile>
DTownCoral
Joined: May 16, 2017
Messages: 1
Offline
UmeshC wrote:Thanks John for your hepl.
Today, our vendor has done some changes in phone settings file and now it's working fine.

Thanks Again.

Regards,
Umesh


Hi Umesh,

I too am experiencing this issue. Would you be able to shed some more light on as to what was changed to overcome this issue?

David
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp#10

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/index.gsp#880

There are a number of items that could be provisioned incorrectly that cause this class of issues. Please review these two FAQs and compare the information in them to your configuration.

I am not aware of anything in the 46xxsettings file that can be configured to conflict with what the FAQs describe, but I suppose it is possible. You can get a new copy of the 46xxsettings file from the support.avaya.com portal and start with that and make sure it is not the source of your issue.
UmeshC
Joined: Apr 18, 2011
Messages: 89
Offline
Hi David,

You need to check following setting in 46xxSettings file -

SET ENABLE_OOD_MSG_TLS_ONLY 0

Should be set 0. Default value is 1

Hope this will work for you.

Thanks & Regards,
Umesh
Go to:   
Mobile view