C++/VB - TSP setting hCall to idle after creating conference

Asked By fdecker

02-Feb-10 07:19 PM

Was just testing a different TSP for a PBX with multiple TSP's that
can be installed.  When creating a direct conference from an existing
call, it creates the conference just fine, but as soon as it does I am
left with only 2 call handles, the hConsultCall and the hConf.  The
hCall from the original call goes idle.  The TSP reports REMOVECALL in
its capabilities, but if I try to remove just one call from my
remaining call handles, it just idles all the calls.  Would you call
this a bug or a design feature? ;)  Any thoughts from this TB log?
Thanks!

lineInitialize returned SUCCESS
num line devs =3D 17
lineOpen returned SUCCESS
Calling lineMakeCall
hLine=3Dx103a4
lphCall=3Dx339348
lpszDestAddress=3Dx12ecec
dwCountryCode=3Dx0
lpCallParams=3Dx0
lineMakeCall returned x10291
received LINE_REPLY
device=3Dx0
cbInst=3Dx0
param1=3Dx10291,
param2=3Dx0,
param3=3Dx10371,
received LINE_CALLSTATE
device=3Dx10371
cbInst=3Dx0
param1=3Dx8, DIALTONE
param2=3Dx0,
param3=3Dx0,
received LINE_CALLSTATE
device=3Dx10371
cbInst=3Dx0
param1=3Dx20, RINGBACK
param2=3Dx0,
param3=3Dx0,
received LINE_CALLINFO
device=3Dx10371
cbInst=3Dx0
param1=3Dx0,
param2=3Dx0,
param3=3Dx0,
received LINE_CALLINFO
device=3Dx10371
cbInst=3Dx0
param1=3Dx18040, CALLID CALLERID CALLEDID
param2=3Dx0,
param3=3Dx0,
received LINE_CALLINFO
device=3Dx10371
cbInst=3Dx0
param1=3Dx18040, CALLID CALLERID CALLEDID
param2=3Dx0,
param3=3Dx0,
received LINE_CALLSTATE
device=3Dx10371    <-------------------- first call connected (10371)
cbInst=3Dx0
param1=3Dx100, CONNECTED
param2=3Dx0,
param3=3Dx0,
received LINE_CALLINFO
device=3Dx10371
cbInst=3Dx0
param1=3Dx18040, CALLID CALLERID CALLEDID
param2=3Dx0,
param3=3Dx0,
Calling lineSetupConference
hCall=3Dx10371
hLine=3Dx103a4
lphConfCall=3Dx339380
lphConsultCall=3Dx3393b8
dwNumParties=3Dx3
lpCallParams=3Dx0
lineSetupConference returned x101f9
received LINE_REPLY
device=3Dx0
cbInst=3Dx0
param1=3Dx101f9,
param2=3Dx0,
param3=3Dx10260,
received LINE_CALLSTATE
device=3Dx10371   <----------------------- first call goes conferenced
cbInst=3Dx0
param1=3Dx800, CONFERENCED
param2=3Dx0,
param3=3Dx0,
received LINE_CALLSTATE
device=3Dx10260    <----------- second call goes on hold pending conf,
should be handle to the conf
cbInst=3Dx0                          (10260)
param1=3Dx1000, ONHOLDPENDCONF
param2=3Dx0,
param3=3Dx0,
received LINE_CALLSTATE
device=3Dx1034f  <-------- third call goes to the dialing state, this
is the actual 2nd =E2=80=9Cphysical=E2=80=9D call
cbInst=3Dx0		this should be the handle to the consult call (1034f)
param1=3Dx8, DIALTONE

03-Feb-10 06:39 AM

Fred,
if the TSP does not maintain a proper conference call handle tree,
then I regard this a TSP bug.
But do(es) the issue(s) occur also if you do the lineDial() correctly on the
consultCall and not like shown below wrongly on the confCall?

Doing lineDial() on the confCall should return LINEERR_INVALCALLSTATE
instead of dialling /reporting on the consultCall.
So this seems to be another TSP bug.

The duplicate LINECALLSTATE_DALTONE for the consultCall and
LINECALLSTATE_CONNETED for the confCall  seems to be TSP bugs too.

Regarding "REMOVECALL ": are you refering to LINECALLFEATURE_REMOVEFROMCONF
?
A lineRemoveFromConference() should only remove that conference leg that is
referenced in the call handle, i.e. hCall or hConsultCall. The call state
must be LINECALLSTATE_CONFERENCED.
If you want to remove your own party instead then you would use lineDrop()
on the hConfCall in LINECALLSTATE_CONNETED.

What TSP are you using?

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

03-Feb-10 04:14 PM

Andreas,

TAPI Browser was guessing the wrong call handles on the lineDial.
Same with lineAddToConference.  I had to check the calls in the TB
middle window and manually type in the handles over what it put in
there.  Is this normal?  I had to try it a few times in order to enter
everything in time before my setup conference failed because the
phones only hold a dialtone for a short time ;)

Quick question: Where is it documented that dial functions return a
call handle in param3 of the LINE_REPLY?  I have looked everywhere and
all I can find is that this parameter is "unused".

This is the Call Manager Express TSP.  The regular call manager works
fine.  It looks like we will be working with the company to fix it.

Here is the new log with comments:

lineInitialize returned SUCCESS
num line devs = 17
Calling lineOpen
hLineApp=x800003ff
dwDeviceID=x10
lphLine=x338528
APIVersion=x20000
dwExtVersion=x0
dwCallbackInstance=x0
dwPrivileges=x6
dwMediaModes=x4
lpCallParams=x0
lineOpen returned SUCCESS
Calling lineMakeCall  <------------------- dial first call
hLine=x101be
lphCall=x339348
lpszDestAddress=x12ed74
dwCountryCode=x0
lpCallParams=x0
lineMakeCall returned x10102
received LINE_REPLY
device=x0
cbInst=x0
param1=x10102,
param2=x0,
param3=x10057,
received LINE_CALLSTATE
device=x10057
cbInst=x0
param1=x8, DIALTONE
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x100000, DISPLAY
param2=x0,
param3=x0,
received LINE_CALLSTATE
device=x10057
cbInst=x0
param1=x20, RINGBACK
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x0,
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x100000, DISPLAY
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x18040, CALLID CALLERID CALLEDID
param2=x0,
param3=x0,
received LINE_CALLSTATE
device=x10057   <------------------ First call is hCall [10057]
cbInst=x0
param1=x100, CONNECTED
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x100000, DISPLAY
param2=x0,
param3=x0,
received LINE_CALLINFO
device=x10057
cbInst=x0
param1=x18040, CALLID CALLERID CALLEDID
param2=x0,
param3=x0,
Calling lineSetupConference
hCall=x10057    <---------------------  correct hCall is set

05-Feb-10 03:48 AM

Fred,
I do not think that TB20 is "guessing" a call handle.
It takes the one that is highlighted in the middle pane as default.



I do not have a documentation for this either.



If you want to use TAPI 2.x then you need to use lineInitializeEx() instead
of lineInitialize().




Interesting question: what is the content of *lphConfCall ?
Unfortunately "Dump buffer contents" does not show the relevant mem.


Yes, seems to be.


Yes, seems to be.


Yes, seems to be.