TSP Bug? LINE_CALLINFO messages come in AFTER the call is idle?

[fdecker]

It seems a PBX manufacturer isn't followomg the TAPI spec for sending
messages about a call after it has entered the idle state. We
deallocate the call as soon as it goes idle and have seen now that a
new version of the TSP for a major PBX manufacturer changed its
behavior and "broke" our code.

This PBX is sending the LINE_CALLSTATE message of IDLE, and then later
sending LINE_CALLINFO messages about that call to tell me the number
or owners and monitors have changed. The MSDN clearly says in the
LINE_CALLINFO help:

"No LINE_CALLINFO messages are sent for a call after the call has
entered the idle state. Specifically, changes in the number of owners
and monitors are not reported as applications deallocate their handles
for the idle call."

As usual with the MSDN, it is not clear its language. However, I read
this as "You can't send any messages for a call to a call that has
entered the idle state because applications usually deallocate their
handles for that call as soon as it goes idle and they therefore will
have a problem recieiving a message for an already deallocated call".

The "as" portion is confusing because the other definition of as could
be read, "monitors are not reported WHILE applications deallocate
their handles". In either case at least, it seems clear that you
don't send these messages on idle calls.

This seems to be a serious bug in the new version of this TSP. Since
we embed out code in a control, the entire control would have to be
rewritten to try to deal with trying to remember a table of idle calls
that we deallocated and then try to ignore any messages that come in
when they aren't supposed to. I believe I need to contact the PBX
manufacturer and have them fix the TSP. Would you agree? I thought
there was another section of the TAPI spec I saw that even said that
no other messages for a call should come in after it is in the idle
state, and that the idle message was the last message to be sent on a
call, but I can't find that, so maybe it is this reference I am
remembering about LINE_CALLINFO messages. If you can point me to any
other proof I can use to send to the manufacturer, I would appreciate
it.

Fred

[Andreas Marschall [exMVP TAPI]]

"fdecker" <fdecker...@aol.com> schrieb im Newsbeitrag
news:3b71b842-b61d-4f89...@f16g2000yqm.googlegroups.com...

> It seems a PBX manufacturer isn't followomg the TAPI spec for sending
> messages about a call after it has entered the idle state. We
> deallocate the call as soon as it goes idle and have seen now that a
> new version of the TSP for a major PBX manufacturer changed its
> behavior and "broke" our code.

Fred,
are you saying that you receive a LINE_CALLINFO message for a hCall that you
previously deallocated (i.e. lineDeallocateCall() already returned)?
If so, are deallocation and message reception taking place nearly at the
same time?
Maybe this is some race condition caused by multi-threading (maybe even only
on multi-core CPUs)
That shouldn't occur, but anynway you may want to make your app more robust
in this case by just ignoring any message (of course except LINE_APPNEWCALL)
for a hCall that you have not currently in your list of active calls.

> This PBX is sending the LINE_CALLSTATE message of IDLE, and then later
> sending LINE_CALLINFO messages about that call to tell me the number
> or owners and monitors have changed. The MSDN clearly says in the
> LINE_CALLINFO help:
>
> "No LINE_CALLINFO messages are sent for a call after the call has
> entered the idle state. Specifically, changes in the number of owners
> and monitors are not reported as applications deallocate their handles
> for the idle call."

You are quoting the description for TAPI LINE_CALLINFO message.
The description for TSPI LINE_CALLINFO message doesn't have the 2nd
sentence.

> As usual with the MSDN, it is not clear its language. However, I read
> this as "You can't send any messages for a call to a call that has
> entered the idle state because applications usually deallocate their
> handles for that call as soon as it goes idle and they therefore will
> have a problem recieiving a message for an already deallocated call".
>
> The "as" portion is confusing because the other definition of as could
> be read, "monitors are not reported WHILE applications deallocate
> their handles". In either case at least, it seems clear that you
> don't send these messages on idle calls.
>
> This seems to be a serious bug in the new version of this TSP. Since
> we embed out code in a control, the entire control would have to be
> rewritten to try to deal with trying to remember a table of idle calls
> that we deallocated and then try to ignore any messages that come in
> when they aren't supposed to. I believe I need to contact the PBX
> manufacturer and have them fix the TSP. Would you agree? I thought
> there was another section of the TAPI spec I saw that even said that
> no other messages for a call should come in after it is in the idle
> state, and that the idle message was the last message to be sent on a
> call, but I can't find that, so maybe it is this reference I am
> remembering about LINE_CALLINFO messages. If you can point me to any
> other proof I can use to send to the manufacturer, I would appreciate
> it.

Please note that the LINE_CALLINFO messages with
LINECALLINFOSTATE_NUMMONITORS / LINECALLINFOSTATE_NUMOWNERDECR /
LINECALLINFOSTATE_NUMOWNERINCR
are not generated by a TSP but by TAPISRV since only TAPISRV knows this.
I just checked with two instanced of TB20, both set to not auto-deallocate
call on idle
and a TSP of mine that definitely doesn't use the mentioned
LINECALLINFOSTATE_ constants.
So this is no TSP issue.
BTW the OS I tested was XP/SP3, so it doesn't seem to be any new "feature"
of TAPISRV.

--
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
TAPI development around the world (Frappr! map):
http://www.frappr.com/TAPIaroundTheWorld
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no
rights.

[fdecker]

Hi Andreas,

Yes, this device is sending a LINE_CALLINFO message after a call is
idle and after I deallocate it. I *can* of course rewrite things to
ignore the message, but hoping to get the device manufacturer to fix
the TSP. However, from what you are saying, their may be some
confusion as to whether the TSP is doing something to cause this, or
it is a function of TAPISRV. What confuses me is that the previous
version of the TSP from this major manufacturer did not do this. In
addition, out of dozens of other devices and PBXs we continue to use
on a daily basis, no other device has done this. Any ideas what might
have changed with this PBX to cause this? Perhaps there is something
else that changed that I am missing in that another application is
running somewhere, but I think at this point there are no other TAPI
instances.

Fred

[fdecker]

Here is some more info. I wonder if this version of the TSP
mistakenly is writing to the call info structure, perhaps writing
zeros for things they aren't changing and thereby overwriting those
fields with a call to TSPI_lineSetCallData? Note that this is from
our TeleScope utility, so it shows things in "TeleTools Speak". The
things starting with "On" are events that fire to correspond to TAPI
messages. The numbers in square brackets show the call handle. I
made our low-level tapi message visible, which is normally hidden
since we have discreet events for these messages. You can see the
call go idle at 11.173, we deallocate at 11.189. We then get 3
messages almost 50ms later, a LINE_ADDRESSSTATE, then the 2
LINEC_CALLINFO messages saying that the number of owners and monitors
were decremented.

26:11.173 OnCallIdle [000100BC]
26:11.189 OnCallEnd [000100BC]
Call.Ended = 10:26:10
26:11.236 OnTAPIMessage
Line.Handle = [000102F0]
Message = LINE_ADDRESSSTATE [00000000]
Parameter 1 = [00000000]
Parameter 2 = LINEADDRESSSTATE_NUMCALLS[00000020]
Parameter 3 = [00000000]
26:11.361 OnTAPIMessage
Call.Handle = [000100BC]
Message = LINE_CALLINFO [00000001]
Parameter 1 = LINECALLINFOSTATE_NUMMONITORS[00002000]
Parameter 2 = [00000000]
Parameter 3 = [00000000]
26:11.470 OnTAPIMessage
Call.Handle = [000100BC]
Message = LINE_CALLINFO [00000001]
Parameter 1 = LINECALLINFOSTATE_NUMOWNERDECR[00001000]
Parameter 2 = [00000000]
Parameter 3 = [00000000]

Here is a TAPI Browser log of the same thing:

10:26.4.589 : received LINE_CALLSTATE
device=x10256
cbInst=x0
param1=x2, OFFERING
param2=x1, ACTIVE
param3=x2, MONITOR
lineGetCallInfo returned x0, hLine=x103d4
10:26.4.714 : received LINE_CALLINFO
device=x10256
cbInst=x0
param1=x1c000, TRUNK CALLERID CALLEDID
param2=x0,
param3=x0,
10:26.4.714 : received LINE_CALLSTATE
device=x1019a
cbInst=x0
param1=x1, IDLE
param2=x0,
param3=x0,
10:26.4.714 : lineGetCallStatus returned SUCCESS
Call x1019a deallocated on IDLE
10:26.4.730 : received LINE_CALLINFO
device=x1019a
cbInst=x0
param1=x2000, NUMMONITORS
param2=x0,
param3=x0,
10:26.10.777 : received LINE_CALLSTATE
device=x10256
cbInst=x0
param1=x1, IDLE
param2=x0,
param3=x0,
10:26.10.808 : lineGetCallStatus returned SUCCESS
Call x10256 deallocated on IDLE
10:26.10.855 : received LINE_CALLINFO
device=x10256
cbInst=x0
param1=x2000, NUMMONITORS
param2=x0,
param3=x0,
10:26.10.855 : received LINE_CALLINFO
device=x10256
cbInst=x0
param1=x1000, NUMOWNERDECR
param2=x0,
param3=x0,

Fred

[Andreas Marschall [exMVP TAPI]]

"fdecker" <fdecker...@aol.com> schrieb im Newsbeitrag

news:f9842c32-cdbf-4177...@c3g2000yqd.googlegroups.com...

Fred,
if TAPISRV sends LINECALLINFOSTATE_NUMMONITORS or
LINECALLINFOSTATE_NUMOWNERxxx then another TAPI must be there (or have been
there), otherwise I'd consider it a a bug in TAPISRV.
What about TAPISRV dependant services like FAX or RAS?