Windows 8 TAPI Issues RRS feed

  • Question

  • I have a problem with a TAPI application under Windows 8 that has no problems running in Windows 7.  I am installing the Avaya tapi 2.0 driver from their IP Office suite, which does install fine and the Avaya Phone Manager Lite does see the phone system after setting the option in the tapi device.  So far, both Win7 and Win8 agree and work identically.

    However, with the application I've written, along with several other tapi programs out there, they all fail in one way or another with inbound events from the phone switch.  These same programs work fine under Win7.

    I've tried disabling the firewall, running the applications as Administrator, but nothing seems to work.  Clearly there has been a change somewhere in Win8 but I cannot find it.


    Wednesday, December 12, 2012 12:53 PM

All replies

  • Bump.  Anyone?
    Tuesday, December 18, 2012 3:32 PM
  • I have a similar problem but with Windows Server 2012. Installation seems to be fine, and all drivers seem to be in place, but i can't really use it. I'd guess Avaya will release an updated User CD with support for Win8/2012 within the next few months. 
    Friday, January 4, 2013 12:33 PM
  • i also have this problem.

    outgoing calls is working but incomming calls are not working.

    Thursday, January 10, 2013 12:30 PM
  • I am seeing the same issue with a TSP.  I have put my observations on google groups.. link below


    Best I can tell is that the tapi service is destroying the inbound call on receipt of a LINEEVENT LINE_NEWCALL and

    you can proceed beyond that point.  I had seen some thread of thought regarding having a MediaMode property

    mismatched, but as you, nothing changed and had been working fine in XP/Windows 7.  Not sure of the next step

    to get beyond TAPI killing off the call before it get's started.

    Wednesday, January 16, 2013 9:35 PM
  • I am seeing the same issue with a TSP.

    Tom, which TSP are you having problems with?  
    Wednesday, January 16, 2013 9:45 PM
  • A competitive product offering to Avaya.  I believe this to be a tapisrv issue.

    On the Avaya system, prior to accepting an inbound call, you could enable tracing for 'tapisrv' by executing

    the following in a command window:    "netsh  ras  set   tracing  tapisrv  enable".   Then try your inbound call.

    The trace log will be located in %SystemRoot%\tracing\tapisrv.LOG.  When operating correctly (within the context of

    XP/Windows 7),  the following line entries would be recorded.  NOTE:  The two LineEventProcSP' entries

    are the two LINEEVENT messages that TSP  generates to TAPI ( a.) LINE_NEWCALL and (b.) LINE_CALLSTATE)

    when handling an inbound call.

    [4984] 15:46:18:464: [INFO ] LineEventProcSP: HTapiLine=0000000000010300, HTapiCall=0000000000000000, msg=1f4,       P1=x5f48790, P2=x5f487b0, P3=x0
    [4984] 15:46:18:464: [TRACE] LineEventProc
    [4984] 15:46:18:464: [TRACE] CreatetCall: enter, ptLine=0000000005025B30
    [4984] 15:46:18:464: [INFO ] CreatetCall: calling NewObject ptCall 0000000005025C50
    [4984] 15:46:18:464: [TRACE] CreatetCall: NewObject returned 0x101ee
    [4984] 15:46:18:464: [TRACE] CreatetCall: exit, new ptCall=0000000005025C50
    [4984] 15:46:18:464: [INFO ] LineEventProcSP: HTapiLine=0000000000010300, HTapiCall=00000000000101EE, msg=2, P1=x2, P2=x1, P3=x0

    When not working on Windows 8, a trace looks like:

    [3344] 15:37:25:615: [INFO ] LineEventProcSP: HTapiLine=00000000000103BB, HTapiCall=0000000000000000, msg=1f4, P1=x187b06c0, P2=x187b06e0, P3=x0
    [3344] 15:37:25:615: [TRACE] LineEventProc
    [3344] 15:37:25:615: [TRACE] CreatetCall: enter, ptLine=000000EA18125250
    [3344] 15:37:25:615: [INFO ] CreatetCall: calling NewObject ptCall 000000EA18125370
    [3344] 15:37:25:615: [TRACE] CreatetCall: NewObject returned 0x10322
    [3344] 15:37:25:615: [TRACE] CreatetCall: exit, new ptCall=000000EA18125370
    [3344] 15:37:25:662: [TRACE] DestroytCall: enter, ptCall=x000000EA18125370

    The tapisrv is killing the call immediately after creation.

    Also note that when finished testing, you need to turn tracing off by executing

    the following in a command window:

             "netsh  ras  set   tracing  tapisrv  disable"

    Can you try an confirm observations?

    Thursday, January 17, 2013 4:28 PM
  • I did the netsh test and here are my results:

    [1348] 10:37:09:551: [INFO ] LineEventProcSP: HTapiLine=00000000000103BB, HTapiCall=0000000000000000, msg=1f4, P1=x2000000c, P2=x10121278, P3=x0
    [1348] 10:37:09:551: [TRACE] LineEventProc
    [1348] 10:37:09:551: [TRACE] CreatetCall: enter, ptLine=000000F17F9D5280
    [1348] 10:37:09:551: [INFO ] CreatetCall: calling NewObject ptCall 000000F17F9D53A0
    [1348] 10:37:09:551: [TRACE] CreatetCall: NewObject returned 0x10344
    [1348] 10:37:09:551: [TRACE] CreatetCall: exit, new ptCall=000000F17F9D53A0
    [1348] 10:37:09:551: [TRACE] DestroytCall: enter, ptCall=x000000F17F9D53A0
    [1348] 10:37:09:651: [INFO ] LineEventProcSP: HTapiLine=00000000000103BB, HTapiCall=0000000000000000, msg=1f4, P1=x2000000c, P2=x10121278, P3=x0
    [1348] 10:37:09:651: [TRACE] LineEventProc
    [1348] 10:37:09:651: [TRACE] CreatetCall: enter, ptLine=000000F17F9D5280
    [1348] 10:37:09:651: [INFO ] CreatetCall: calling NewObject ptCall 000000F17F9D53A0
    [1348] 10:37:09:651: [TRACE] CreatetCall: NewObject returned 0x10333
    [1348] 10:37:09:651: [TRACE] CreatetCall: exit, new ptCall=000000F17F9D53A0
    [1348] 10:37:09:651: [TRACE] DestroytCall: enter, ptCall=x000000F17F9D53A0
    [1348] 10:37:09:752: [INFO ] LineEventProcSP: HTapiLine=00000000000103BB, HTapiCall=0000000000000000, msg=1f4, P1=x2000000c, P2=x10121278, P3=x0
    [1348] 10:37:09:752: [TRACE] LineEventProc
    [1348] 10:37:09:752: [TRACE] CreatetCall: enter, ptLine=000000F17F9D5280
    [1348] 10:37:09:752: [INFO ] CreatetCall: calling NewObject ptCall 000000F17F9D53A0
    [1348] 10:37:09:752: [TRACE] CreatetCall: NewObject returned 0x10322
    [1348] 10:37:09:752: [TRACE] CreatetCall: exit, new ptCall=000000F17F9D53A0
    [1348] 10:37:09:752: [TRACE] DestroytCall: enter, ptCall=x000000F17F9D53A0
    [1348] 10:37:12:214: [INFO ] LineEventProcSP: HTapiLine=00000000000103BB, HTapiCall=0000000000000000, msg=0, P1=x0, P2=x20, P3=x0
    [3368] 10:37:12:214: [INFO ] Got a line spevent, htLine = 0x103bb, htCall = 0x0, dwMsg = 0x0
    [3368] 10:37:12:214: [TRACE] LineEventProc
    [3368] 10:37:12:214: [TRACE] SendMsgToLineClients - enter
    [3368] 10:37:12:214: [INFO ] SendMsgToLineClients - number of Clients:1
    [3368] 10:37:12:214: [INFO ] SendMsgToLineClients: Msg:0 -- Param1:0
    [3368] 10:37:12:214: [INFO ] FMsgDisbled: dwAPIVersion<= TAPI_VERSION3_0, msg will be enabled
    [3368] 10:37:12:214: [TRACE] FMsgDisabled return 0
    [3368] 10:37:12:214: [TRACE] WriteEventBuffer - enter
    [3368] 10:37:12:214: [TRACE] WriteEventBuffer: SetEvent 0000000000000480 for local client
    [7772] 10:37:12:214: [TRACE] GetAsyncEvents: enter (TID=7772)
    [7772] 10:37:12:214: [INFO ] M ebfused:x28  pEvtBuf: 0x000000F17F9D1460  pDataOut:0x000000F17F9D1460  pDataIn:0x000000F17F9D1488
    [7772] 10:37:12:214: [TRACE] GetAsyncEvents: return dwUsedBufferSize:x28

    Indeed, the DestroyCall is logged.  I passed on your previous information to my Tapi library provider to see what they saw, and here is their response:

    Hi John, I can not read the trace very well. But the situation he describes is the same. The problem in our TSP was the following: When sending the LINE_NEWCALL message to TAPI to notify TAPI about a new call, a pointer to a TAPICALL is passed as a DWORD. The MSD says to cast the parameter &htCall to a DWORD. http://msdn.microsoft.com/en-us/library/windows/desktop/ms725235%28v=vs.85%29.aspx

    htLine = (HTAPILINE) hLineDevice;
    htCall = (HTAPICALL) 0;
    dwParam1 = (DWORD)(HDRVCALL) hdCall;
    dwParam2 = (DWORD)(LPHTAPICALL) &htCall;
    dwParam3 = (DWORD) 0;


    void CALLBACK Line_Event(
      HTAPILINE htLine,
      HTAPICALL htCall,
      DWORD dwMsg,
      DWORD_PTR dwParam1,
      DWORD_PTR dwParam2,
      DWORD_PTR dwParam3

    On Windows 8 64-Bit, this value is bigger than a DWORD. This lets the event fail and causes TAPI to close the call immediately.

    From this I gather that the parameter dsParam2 in Windows 8 x64 is incorrect causing the problem.  Hopefully this combination of information will help Microsoft figure out the issue.


    Thursday, January 17, 2013 4:42 PM
  • Thanks for the update.

    Ensuring that the invocation casting matches the signature (e.g. using DWORD_PTR) corrects the problem.

    I don't know why Microsoft had the mismatch specified to begin with.

    Friday, January 18, 2013 2:06 PM
  • Are you saying that the problem still lies in the TSP (incorrect casting) or that the library calling the TSP is not calling it correctly?

    Friday, January 18, 2013 2:10 PM
  • The TSP had been following the Microsoft convention of invoking the callback as:

       with m_pfnEventProc == Line_Event from above.....

       old method invocation  (with failure exhibited)

       m_pfnEventProc(  m_htLine,
                                  (DWORD) this,
                                  (DWORD) &m_htCall,
                                  (DWORD) 0 ) ;

       modified method invocation ( all working as it was pre Windows 8 - 64bit )

       m_pfnEventProc(  m_htLine,
                                  (DWORD_PTR) this,
                                  (DWORD_PTR) &m_htCall,
                                  (DWORD_PTR) 0 ) ;

    Friday, January 18, 2013 2:30 PM
  • Maybe I phrased that incorrectly.  From your diagnosis, is it the TSP that is at fault, or the library that talks to the TSP?

    I'm still trying to get the latest TAPI driver from Avaya to continue my own testing, and will report any changes once I have that.


    Friday, January 18, 2013 2:40 PM
  • The correction in on the TSP side.  Something changed in Microsoft's implementation of their TAPI layer that

    is no longer in sync with what they specify in their own documentation.

    I don't know why their specification had one cast the last three parameters to something other than what the

    callback was defined to take in the first place.


    Friday, January 18, 2013 2:50 PM
  • Ok, I understand now.  Thanks!
    Friday, January 18, 2013 2:51 PM
  • Hi John,

    We have the same issue as you with the TAPI driver on Windows 8 - I am currently keeping an eye out / searching for an updated driver / solution to this issue.

    Can we agree to post anything we find on this thread?



    Tuesday, January 22, 2013 9:25 AM
  • That is the goal, Rich.  Thanks for helping. 
    Tuesday, January 22, 2013 1:17 PM
  • I have same problem on Windows Server 2012. Avaya Tapi (tapiQ4Maint2012 and AddTapi.Net 3) is able to dial out, but no incomming events. If anybody finds a solution (or Avaya updates their Tapi), please post it here.



    • Edited by M O J O Friday, January 25, 2013 6:36 AM
    Friday, January 25, 2013 6:29 AM
  • Hi all,

    this problem also occurs with our alcatel-lucent-tsp on windows 8 x64.
    Sometimes I love MS...changing the tapi assuming all manufacturers update their tsps.

    Found a working TSP but costs 5 Licenses 269€...also available for avaya

    Thursday, March 7, 2013 9:16 AM
  • Anyone have any word on a fix from Microsoft yet?

    Wednesday, April 10, 2013 6:59 PM
  • No, nothing yet :( Considering downgrading to Win7....
    Tuesday, April 16, 2013 2:12 PM
  • Hi all,

    Same problem with windows 8 ...

    I'm able to make a call with my appli, but no event fired when receving a call.

    Any news about an update correcting this problem ?

    Isnt there a way to temporary solve the problem, by changing a register's key, like there:


    • Edited by Jul67ien Wednesday, July 3, 2013 9:16 AM add a comment (url link)
    Wednesday, July 3, 2013 8:32 AM
  • Any news about an update correcting this problem ?

    Isnt there a way to temporary solve the problem, by changing a register's key

    Unfortunately there is no quick fix via registry setting.

    This issue can only be solved

    • either by MS undoing the interface changes on TSPI level
    • or by the TSP manufacturers adaption their TSPs to the changed TSPI behaviour

    To sum things up here is the situation as I understand it.

    Problem: Incoming calls are not reported via TAPI

    Affected OS:

    • Windows 8 (x64 version only)
    • Windows Server 2012 (there is only a x64 version)

    Affected TSP (feel free to report addional info, e.g. version, fix available etc.)

    • Avaya TAPI
    • Acatel-Lucent TSP
    • NEC TSP (for PBX NEC SL1100)
    • Siemens HiPath TAPI 120/170 (V2 R1.66.0)

    With the latter TSP I reproduced the issue myself on a MS Surface Pro (with Win8x64).
    The other TSPs have been reported by others.

    Technical background:

    The issue is caused by TAPISRV (Telephony Service) not processing LINE_NEWCALL correctly on the affected OS,
    presumable due to additional parameter type checking for the dwParams in LINEEVENT / PHONEEVENT.
    It is about DWORD vs. DWORD_PTR.
    The issue is only existing on x64 OS because there those two types a different: (unsigned long) vs. (unsigned __int64)
    In x86 they are the same (unsigned long), hence in x86 there is no issue.

    Best Regards
    Andreas Marschall
    Microsoft® MVP for TAPI / Windows® SDK / Visual C++® 2003-2008
    TAPI / TSP Developer and Tester
    My TAPI and TSPI FAQ:
    My Toto® Tools (a collection of free, mostly TAPI related tools):
    * Please post all messages and replies to the forum so all may benefit from the discussion.
    * This posting is provided “AS IS” with no warranties, and confers no rights.

    Sunday, July 28, 2013 10:43 PM
  • According to this page on the Avaya DevConnect site, an upgrade to Avaya TAPI will resolve the issue for Avaya IP Office users, of which I am one..


    However, despite the fact that the software used to be available to freely download, you now have to have a log in, and have registered your system with them using an SSO number?!!? That's something I don't have anywhere.

    Is anyone else able to download the update and post it somewhere more accessible?

    Here's a link to the download https://support.avaya.com/downloads/download-details.action?contentId=C20138291430361300_6&productId=P0160

    Hope this helps....


    Thursday, September 26, 2013 9:28 AM
  • Hi,

    Microsoft Developer Support has reviewed this further.  The MSDN documentation has added a note from the community additions on using DWORD_PTR versus DWORD for 64-bit TSPI vendors and for clients sending the message.


    On x64 builds of an application,  the code in this page needs to be updated to address the values not fitting into the space DWORD.  This should be changed to:

      dwParam1 = (DWORD_PTR)(HDRVCALL) hdCall;
      dwParam2 = (DWORD_PTR)(LPHTAPICALL) &htCall

    Thank you,


    Wednesday, October 9, 2013 2:44 PM
  • Hi,

    the LINE_CREATE message seems to be affected too.  As per MS spec:

    LINE_CREATE htLine = (HTAPILINE) 0; htCall = (HTAPICALL) 0; dwMsg = (DWORD) LINE_CREATE; dwParam1 = (DWORD) hProvider; dwParam2 = (DWORD) TempDeviceId; dwParam3 = (DWORD) 0;

    Not many TSPs actually support dynamic line creation, so not all may be affected. Still, a similar note in the LINE_CREATE page may be appropriate.

    Regards, Christoph

    Monday, December 23, 2013 10:36 AM
  • Is there any hope of Microsoft rolling this back? This is really a poor, unnecessary and destructive change. The problem does NOT exist in any previous operating system including Windows 7, 64bit. This problem was introduced in Windows 8 64bit and Windows Server 2012 64 bit. Not only does it break many other TSPs not listed here, but it breaks quite a bit of TAPI code in many applications. In particular, trying to make an ActiveX control that works in Visual Studio through the generated interop assemblies has proven thusfar impossible.
    Wednesday, March 12, 2014 6:49 PM