cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4322
Views
0
Helpful
12
Replies

CUCM 8.6 TSP issue

Kapil Atrish
Level 3
Level 3

Hi,

I've trouble making the TSP connection to a CUM 8.6 cluster.

I am using windows 7 64 Bit PC and installed the "CiscoTSPx64.exe" as a fresh, did a reboot and configured the required paramenters (CTI Server/Username PWD).

When I use dialer.exe, I don't see Cisco line available. When I go to install the WAVE driver, I don't see WAVE folder created. I searched for OEMSETUP.INF, couldn't find it anywhere.

I put the TSP client in trace mode which generated the output mentioned below. I am sure my username/pwd is correct as I can login to CUCMUSER webpage from the same PC.

I've tried installing TSP plugin from following CUCM versions:

CUCM version: 8.6.2.22900-9

CUCM Version: 8.6.2.20000-2

When I install 32 bit TSP client, I do see WAVE folder created but when I try to install it, it throws an error saying this application is not supported on 64bit OS.

++++++++++++++++++++++++++++++++++++++++++++++++++++

16:13:32.730 HDR|10/22/2012 CiscoTSP001.tsp,Special

16:13:32.730 |   ProviderOpenRequest::qbeTraceOut seq# =0x00000005

16:13:32.731 |   ProviderOpenRequest::qbeTraceOut {{0x00000104, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x00000003, 0x00000020, 0x0000006C, 0x00000080}

16:13:32.731 |   ProviderOpenRequest::qbeTraceOut

        ProviderName             : {0x0000008C, 18, CiscoTSP 8.6(2.7) }

        LoginUserID              : {0x000000B0, 10, 5, 2, katr }

        ApplicationID            : {0x000000EA, 25, CiscoTSP001-172.20.40.26 }

        QBEClientVersion         : {0x0000009E, 18, CiscoTSP 8.6(2.7) }

        ProviderEventFilter = {0x000000DA, 16, 4} :

            {bDeviceRegistered: 0xFFFFFFFF, bDeviceUnRegistered: 0xFFFFFFFF, bDirectoryChangeNotify: 0xFFFFFFFF, bDeviceConfigChangedNotify: 0xFFFFFFFF}

        WantServerHeartbeat     : 0x0000001E

        CMAssignedApplicationID : 0x00000000

        PluginName              : {0x00000103, 9, CiscoTSP }

        bLightWeightProviderOpen: 0x00000000

        SingleSignOnTicket      : {0x00000000, 0, }

        AuthenticationType      : 0

        bOldDeviceLineFetch     : 0x00000000

16:13:32.734 |   ProviderOpenResponse::qbeTraceIn seq# =0x00000005 result =0x00000000

16:13:32.734 |   ProviderOpenResponse::qbeTraceIn {{0x0000008B, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x00000004, 0x00000020, 0x00000034, 0x0000003F}

16:13:32.734 |   ProviderOpenResponse::qbeTraceIn

        Result          : 0x00000000

        ProviderInfo    : {0x00000054, 14, 8.6.2.20000-2 }

        ClientHeartbeat : 30

        ServerHeartbeat : 30

        PluginVersion   : {0x00000062, 10, 8.6.2.2-0 }

        PluginLocation  : {0x0000006C, 39,

http://10.1.10.10/plugins/CiscoTSP.exe

}

        dwProviderId    : 117440522

        bisFIPSEnabled  : 0x00000000

16:13:42.886 |   ProviderOpenCompletedEvent::qbeTraceIn {{0x00000091, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x0000007E, 0x00000020, 0x00000048, 0x00000032}

16:13:42.887 |   ProviderOpenCompletedEvent::qbeTraceIn

        Reason           : 0x8CCC0075

        SequenceNumber   : 5

        ProviderInfo     : {0x00000068, 14, 8.6.2.20000-2 }

        ClientHeartbeat  : 0

        ServerHeartbeat  : 0

        Description      : {0x00000076, 33, Directory login failed - timeout }

        bMonitorCallPark : 0

        ProviderId       : 117440522

        DSCPForCTI2Apps  : 0x00000000

        bEnableIpv6      : 0x00000000

        unicodeUserID    : {0x00000098, 2, 1, 2,  }

        daysPswdToExp    : 4294967295

        totalDevices  : 775040566

16:13:42.887 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:13:42.887 |   ProviderClosedEvent::Trace

        dummyHeader.dwLen =28

        dummyHeader.dwType =0

        dwMagicCookie =0xFFFFDDDD

        dwProtocolVersion =0x000D0001

        dwPDUNumber =155

        dwHeaderSize =32

        dwFixedSize =4

        dwVariableSize =0

16:13:42.887 |   ProviderClosedEvent::Trace

                  

16:13:32.730 HDR|10/22/2012 CiscoTSP001.tsp,Special
16:13:32.730 |   ProviderOpenRequest::qbeTraceOut seq# =0x00000005
16:13:32.731 |   ProviderOpenRequest::qbeTraceOut {{0x00000104, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x00000003, 0x00000020, 0x0000006C, 0x00000080}
16:13:32.731 |   ProviderOpenRequest::qbeTraceOut
        ProviderName             : {0x0000008C, 18, CiscoTSP 8.6(2.7) }
        LoginUserID              : {0x000000B0, 10, 5, 2, katr }
        ApplicationID            : {0x000000EA, 25, CiscoTSP001-172.20.40.26 }
        QBEClientVersion         : {0x0000009E, 18, CiscoTSP 8.6(2.7) }
        ProviderEventFilter = {0x000000DA, 16, 4} :
            {bDeviceRegistered: 0xFFFFFFFF, bDeviceUnRegistered: 0xFFFFFFFF, bDirectoryChangeNotify: 0xFFFFFFFF, bDeviceConfigChangedNotify: 0xFFFFFFFF}
        WantServerHeartbeat     : 0x0000001E
        CMAssignedApplicationID : 0x00000000
        PluginName              : {0x00000103, 9, CiscoTSP }
        bLightWeightProviderOpen: 0x00000000
        SingleSignOnTicket      : {0x00000000, 0, }
        AuthenticationType      : 0
        bOldDeviceLineFetch     : 0x00000000
16:13:32.734 |   ProviderOpenResponse::qbeTraceIn seq# =0x00000005 result =0x00000000
16:13:32.734 |   ProviderOpenResponse::qbeTraceIn {{0x0000008B, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x00000004, 0x00000020, 0x00000034, 0x0000003F}
16:13:32.734 |   ProviderOpenResponse::qbeTraceIn
        Result          : 0x00000000
        ProviderInfo    : {0x00000054, 14, 8.6.2.20000-2 }
        ClientHeartbeat : 30
        ServerHeartbeat : 30
        PluginVersion   : {0x00000062, 10, 8.6.2.2-0 }
        PluginLocation  : {0x0000006C, 39, http://10.1.10.10/plugins/CiscoTSP.exe }
        dwProviderId    : 117440522
        bisFIPSEnabled  : 0x00000000
16:13:42.886 |   ProviderOpenCompletedEvent::qbeTraceIn {{0x00000091, 0x00000000}, 0xFFFFDDDD, 0x000D0001, 0x0000007E, 0x00000020, 0x00000048, 0x00000032}
16:13:42.887 |   ProviderOpenCompletedEvent::qbeTraceIn
        Reason           : 0x8CCC0075
        SequenceNumber   : 5
        ProviderInfo     : {0x00000068, 14, 8.6.2.20000-2 }
        ClientHeartbeat  : 0
        ServerHeartbeat  : 0
        Description      : {0x00000076, 33, Directory login failed - timeout }
        bMonitorCallPark : 0
        ProviderId       : 117440522
        DSCPForCTI2Apps  : 0x00000000
        bEnableIpv6      : 0x00000000
        unicodeUserID    : {0x00000098, 2, 1, 2,  }
        daysPswdToExp    : 4294967295
        totalDevices  : 775040566
16:13:42.887 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595
16:13:42.887 |   ProviderClosedEvent::Trace
        dummyHeader.dwLen =28
        dummyHeader.dwType =0
        dwMagicCookie =0xFFFFDDDD
        dwProtocolVersion =0x000D0001
        dwPDUNumber =155
        dwHeaderSize =32
        dwFixedSize =4
        dwVariableSize =0
16:13:42.887 |   ProviderClosedEvent::Trace

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Any help on this will be greatly appreciated.

thanks,

Kapil

12 Replies 12

Graham Old
Level 7
Level 7

It looks like its just getting a timeout. Is this the first time you have accessed this cluster by TAPI.

Is the Cisco CTIManager running on all servers.

Does the user ID you are using have all the CTI boxes checked and is it a member of the "Standard CTI enabled" group

Graham

Thanks for your reply.

I've a set of users using some home grown application, they said it was working fine but stopped for a week. When doing the TSP test, they noticed the issue which I mentioned above and brought to my notice. I tried it at my end and found they do have issue in CTI connection to CUCM.

No changes have been made on CUCM side, it was working with version 8.6 in the past.

Yes, CTI Manager is running on the CUCM servers which I put in inside my TSP configuration.

Yes, End user has "Standard CTI Enabled" group assigned.

I've associated a SCCP hard-phone and a dummy CTI Port with the end user also.

Let me know if there is something more I can check.

I am wondering why I don't see WAVE folder/OERMSETUP.INF installing the 64bit TSP plugin.

The log out put I shared earlier was from dbg2 file. dbg1 file has following logs:

16:10:29.084 HDR|10/22/2012 CiscoTSP001.tsp,Error

16:10:29.084 |   CSelsiusTSPWaveList::Init() *ERROR* Failed to get ISelsiusNTWaveCtl interface.

16:10:29.084 |   SelsiusTSP::InitializeComObjects() *ERROR* Failed m_WaveList->Init(). hr=0x80040154

16:10:39.261 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:11:30.409 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:12:20.562 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:13:02.721 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:10:29.084 HDR|10/22/2012 CiscoTSP001.tsp,Error

16:10:29.084 |   CSelsiusTSPWaveList::Init() *ERROR* Failed to get ISelsiusNTWaveCtl interface.

16:10:29.084 |   SelsiusTSP::InitializeComObjects() *ERROR* Failed m_WaveList->Init(). hr=0x80040154

16:10:39.261 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:11:30.409 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:12:20.562 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

16:13:02.721 |   CQBEHelperBase::ProviderOpen() *ERROR* Provider open failed.  result=-1932787595

The provider object is just the initial connection. It has CTI server IP, user ID and password. This just looks like a basic can't connect.

If it was working and has stopped for everyone try restarting the CTI Manager. Do you have anything else on your system using CTI, CCX or Unity for example.

You could also try running a wireshark capture and see what is going on with the network.

Graham

Are you saying I don't need WAVE driver installed on my PC to see the Cisco Line and succesfully intiate a test call using dialer.exe?

I am testing it from my PC. I don't have any CTI application installed yet.

I'll move ahead with Wireshark captures tomorrow, thanks for the suggestion.

You only need the wav drivers if your program is going to send and receive the audio streams.

If you are just controlling an external phone (or IP Comminicator) you don't need the wav drivers.

Graham

Kapil Atrish
Level 3
Level 3

I engaged TAC and the engineer pinpointed following error from the CTI Logs:

Login User Id:platju Reason code.:-1932787595

This is the Cisco documentation on this error code:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/jtapi_dev/8_6_1/constantfieldvalues.html

The engineer suspected LDAP server is not able to authenticate CTI based connections correctly although HTTP based connections (CCMUSER Web Page access) or JTAPI based connections (UCCX) are working fine.

We created an application user in CUCM and the Dialer.exe showed Cisco Line as expected. The engineer did assign all CTI roles (Not only Standard CTI Enabled) except Secure CTI ones. The End User didn't work no matter what we try.

As of now, I've asked the AD team to look at their side or engage Microsoft to debug it at their end. Hopefull that'll resolve the issue.

Hi

Did you try repointing your CUCM AD configuration to the global catalog (i.e. tct port 3269) instead of the DC port (389)? Obviously make sure that the server you are pointing at is a GC.

That often resolves timeout issues.


Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

LDAP Port For When the LDAP Server Is a Global Catalog Server

3268—When SSL is not required.

3269—When SSL is required. (If you enter this port number, make sure that you check the Use SSL check box.

We've done LDAP integration on Port 3268. That was one of the things I verified day 1 and TAC also double checked today.

Regarding, if the server is GC or not, that I've not checked. I'll check it now.

Thanks,

Kapil

Are you using LDAPS?

If so try with LDAP as ctimanager uses openssl for ldap auth which is different to the webgui

Hi Zane,

We are using Microsoft AD as LDAP Server. We engaged Microsoft support who ran a utility on one of the domain controller and confirmed that LDAP authentication on port 3268 is successful.

TAC engineer later pointed out that we may be hitting the following BUG and advised an upgrade:

Bug ID: CSCts99665

CTI Authentication failure + OutOfMemoryError:

Curerrently waiting for an opportunity to ugprade our CUCM cluster.

thanks,

Kapil

Scott Harris
Level 1
Level 1

I still dont see anyone explain why the directory "Wave Drivers" or the file "OEMSETUP.INF" does not exist. Anyone?