Windows 8 TAPI Issues

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.

Help!

Answer 1

Bump.  Anyone?

Answer 2

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. 

Answer 3

i also have this problem.

outgoing calls is working but incomming calls are not working.

Answer 4

I am seeing the same issue with a TSP.  I have put my observations on google groups.. link below

https://groups.google.com/forum/?fromgroups=#!topic/microsoft.public.win32.programmer.tapi/dME3m6OQOh0

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.

Answer 5

I am seeing the same issue with a TSP.

Tom, which TSP are you having problems with?  

Answer 6

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?

Answer 7

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

LINE_NEWCALL

htLine = (HTAPILINE) hLineDevice;

htCall = (HTAPICALL) 0;

dwMsg = (DWORD) LINE_NEWCALL;

dwParam1 = (DWORD)(HDRVCALL) hdCall;

dwParam2 = (DWORD)(LPHTAPICALL) &htCall;

dwParam3 = (DWORD) 0;

http://msdn.microsoft.com/en-us/library/windows/desktop/ms725228%28v=vs.85%29.aspx

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.

John

Answer 8

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.

Answer 9

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?

Answer 10

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,
                               0,
                               LINE_NEWCALL,
                              (DWORD) this,
                              (DWORD) &m_htCall,
                              (DWORD) 0 ) ;

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

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

Answer 11

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.

Thanks.

Answer 12

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.

 

Answer 13

Ok, I understand now.  Thanks!

Answer 14

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?

Thanks

Rich

Answer 15

That is the goal, Rich.  Thanks for helping. 

Answer 16

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.

Thanks

Mojo

Answer 17

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
http://www.estos.de/produkte/treiber-und-middleware/ecsta-serie/fuer-alcatel-lucent-omnipcx-4400-serie.html

Answer 18

Anyone have any word on a fix from Microsoft yet?

Answer 19

No, nothing yet :( Considering downgrading to Win7....

Answer 20

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:

http://blog.tmcnet.com/blog/tom-keating/microsoft/windows-8-broke-my-tapi-dialing-but-problem-solved.asp

Answer 21

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:
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
My Toto® Tools (a collection of free, mostly TAPI related tools):
http://www.i-b-a-m.de/Andreas_Marschall's_Toto_Tools.htm
* 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.

Answer 22

According to this page on the Avaya DevConnect site, an upgrade to Avaya TAPI 1.0.0.38 will resolve the issue for Avaya IP Office users, of which I am one..

https://devconnect.avaya.com/public/forum/d_forum_3.jsp?t=13028&f=54

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....

Rich 

Answer 23

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.

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms725235(v=vs.85).aspx

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,

Nathan

Answer 24

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

Answer 25

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.