problem with second call
Jerry
several days I'm not making progress .. thus the call for help.
I've been asked to convert some old (15 yr old) DOS legacy home-brew
networking software to work under windows. It requires that I dial from a
current Windows machine TO a 2400 baud hayes-compatible modem. In the old
version, I just opened the comm port and sent AT commands to the modem.
Obviously, in the Windows world, this doesn't fly, so I've turned to TAPI.
I've had little problem making the connection by using the following
sequence (condensed and with all error checking removed). In the real code,
every call's retcode is checked and I've got messages going to a log file
...
retcode = lineInitialize( &hLineApp, ...
dwDeviceID = -1;
for (i = 0; i < lines && dwDeviceID == -1; i++)
{
pLineDevCaps = GetDevCaps(hLineApp, i, &dwAPIVersion); (function calls
negotiateapiversion for each iteration (1.4))
if (pLineDevCaps->dwMediaModes & LINEMEDIAMODE_DATAMODEM &&
pLineDevCaps->dwLineFeatures & LINEFEATURE_MAKECALL)
dwDeviceID = i;
free(pLineDevCaps);
if (dwDeviceID != -1)
break;
}
if (dwDeviceID == -1) // no suitable device
{
KillConnection();
return -1;
}
retcode = lineOpen(hLineApp ....
memset(&lineCallParams, 0, sizeof(LINECALLPARAMS));
lineCallParams.dwTotalSize = sizeof(LINECALLPARAMS);
lineCallParams.dwMinRate = 2400;
lineCallParams.dwMaxRate = 2400;
lineCallParams.dwMediaMode = LINEMEDIAMODE_DATAMODEM;
retcode = lineMakeCall(hLine, ....
peekmessage loop waits for line_reply or timeout and sets bConnected if ok
if (bConnected == 0) // timed out
{
KillConnection();
return -1;
}
lpDeviceID = (LPVARSTRING)malloc(sizeof(VARSTRING));
lpDeviceID->dwTotalSize = sizeof(VARSTRING);
lineGetID(0, 0, hCall, LINECALLSELECT_CALL, lpDeviceID,"comm/datamodem");
if (lpDeviceID->dwNeededSize > lpDeviceID->dwTotalSize)
{
lpDeviceID = (LPVARSTRING)realloc(lpDeviceID, lpDeviceID->dwNeededSize);
lpDeviceID->dwTotalSize = lpDeviceID->dwNeededSize;
lineGetID(0, 0, hCall, LINECALLSELECT_CALL, lpDeviceID,"comm/datamodem");
}
hComm = *((LPHANDLE)((char *)lpDeviceID + sizeof(VARSTRING)));
(hcomm is then used to set commstates, baud, etc)
The call connects ok and I establish communcation with the other end. When
I disconnect I go thru the following sequence ... the various handles are
global and obvious in their meaning .. Again, in the real code, all return
codes are checked and output to a log file. This is the code for
'KillConnection'
if( hComm)
{
retcode = CloseHandle( hComm );
hComm = NULL;
}
if(hCall)
{
retcode = lineDrop( hCall, NULL, 0 ); // Drop the call
if (retcode>0)
retcode = waitreply(retcode); (waits for line_reply)
while (gCallState != LINECALLSTATE_IDLE)
peekmessageloop(); (waits for linecallstate_idle)
retcode = lineDeallocateCall(hCall);
hCall = NULL;
}
if(hLine)
{
retcode = lineClose(hLine);
hLine = NULL;
}
if(hLineApp)
{
lineShutdown( hLineApp);
hLineApp = NULL;
}
This code runs without error and the call is terminated.
However, if I then try to establish another call, all code runs without
error until I get to the lineOpen command, which returns
LINEERR_OPERATIONFAILED.
What in the world am I doing wrong? Here's the output from my log file ...
Nov 03 10:57:20 - Program started...
Nov 03 10:57:24 - Received ID_CALL msg (initiates call)
Nov 03 10:57:24 - calling lineinitialize
Nov 03 10:57:24 - retcode = 0x0
Nov 03 10:57:24 - after lineinitialize, hLineApp = 0x800003ff
Nov 03 10:57:24 - after lineinitialize, lines = 0x7
Nov 03 10:57:24 - b4 getdevcaps
Nov 03 10:57:24 - calling lineNegotiateAPIVersion
Nov 03 10:57:24 - retcode = 0x0
Nov 03 10:57:24 - version = 0x10004
Nov 03 10:57:24 - calling lineGetDevCaps
Nov 03 10:57:24 - retcode = 0x0
Nov 03 10:57:24 - calling lineGetDevCaps (after changing memory
allocation)
Nov 03 10:57:24 - retcode = 0x0
Nov 03 10:57:24 - after getdevcaps, deviceID = 0x0
Nov 03 10:57:24 - calling lineopen
Nov 03 10:57:24 - hLineApp = 0x800003ff
Nov 03 10:57:24 - dwDeviceID = 0x0
Nov 03 10:57:24 - hline = 0x0
Nov 03 10:57:24 - dwAPIVersion = 0x10004
Nov 03 10:57:24 - retcode = 0x0
Nov 03 10:57:24 - after lineOpen, hLine = 0x10277
Nov 03 10:57:24 - calling linemakecall
Nov 03 10:57:24 - retcode = 0x10255
Nov 03 10:57:24 - after lineMakeCall, hCall = 0x0
Nov 03 10:57:24 - after linemakecall
Nov 03 10:57:24 - b4 idle loop
Nov 03 10:57:24 - linemakecall return = 0
Nov 03 10:57:24 - line reply
Nov 03 10:57:24 - Line Reply
Nov 03 10:57:24 - Dialing...
Nov 03 10:57:25 - Proceeding
Nov 03 10:57:44 - linecallstate connected
Nov 03 10:57:44 - Connected
Nov 03 10:57:44 - after idle loop
Nov 03 10:57:44 - after idle loop, hCall = 0x10233
Nov 03 10:57:44 - INFO request rec'd (1)
(successful comm received from the other end)
Nov 03 10:57:52 - Received ID_DISCONNECT msg (user clicked
'disconnect')
Nov 03 10:57:52 - CloseHandle called on hComm = 0x708
Nov 03 10:57:52 - succeeded
Nov 03 10:57:52 - calling lineDrop on hCall = 0x10233 (we wait for
LINE_REPLY before proceeding)
Nov 03 10:57:54 - LINECALLSTATE_DISCONNECTED
Nov 03 10:57:54 - LINECALLSTATE_IDLE (we wait for
IDLE before calling linedeallocatecall)
Nov 03 10:57:55 - retcode = 0x0
Nov 03 10:57:55 - calling lineDeallocateCall on hCall = 0x10233
Nov 03 10:57:55 - retcode = 0x0
Nov 03 10:57:55 - Call Dropped
Nov 03 10:57:55 - calling lineClose on hLine = 0x10277
Nov 03 10:57:55 - retcode = 0x0
Nov 03 10:57:55 - Line Closed
Nov 03 10:57:55 - lineShutdown called on hLineApp = 0x800003ff
Nov 03 10:57:55 - retcode = 0x0
Nov 03 10:57:55 - Line Shutdown
Nov 03 10:58:02 - Received ID_CALL msg (user
initiates the second call)
Nov 03 10:58:02 - calling lineinitialize
Nov 03 10:58:02 - retcode = 0x0
Nov 03 10:58:02 - after lineinitialize, hLineApp = 0x800003cc
Nov 03 10:58:02 - after lineinitialize, lines = 0x7
Nov 03 10:58:02 - b4 getdevcaps
Nov 03 10:58:02 - calling lineNegotiateAPIVersion
Nov 03 10:58:02 - retcode = 0x0
Nov 03 10:58:02 - version = 0x10004
Nov 03 10:58:02 - calling lineGetDevCaps
Nov 03 10:58:02 - retcode = 0x0
Nov 03 10:58:02 - calling lineGetDevCaps
Nov 03 10:58:02 - retcode = 0x0
Nov 03 10:58:02 - after getdevcaps, deviceID = 0x0
Nov 03 10:58:02 - calling lineopen
Nov 03 10:58:02 - hLineApp = 0x800003cc
Nov 03 10:58:02 - dwDeviceID = 0x0
Nov 03 10:58:02 - hline = 0x0
Nov 03 10:58:02 - dwAPIVersion = 0x10004
Nov 03 10:58:02 - retcode = 0x80000048 (OOPS)
Nov 03 10:58:02 - after lineOpen, hLine = 0x0
Nov 03 10:58:02 - lineopen error
Nov 03 10:58:02 - LINEERR_OPERATIONFAILED
Nov 03 10:58:03 - lineOpen error
Nov 03 10:58:03 - Unable to start a TAPI Function
Nov 03 10:58:04 - Received ID_DISCONNECT msg
Nov 03 10:58:04 - lineShutdown called on hLineApp = 0x800003cc
Nov 03 10:58:04 - retcode = 0x0
Nov 03 10:58:04 - Line Shutdown
I'd surely appreciate any guidance or insight. I'm under the gun on this
thing. Sorry this is so long.
Jerry
![Andreas Marschall [MVP TAPI]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUdVhINZ75uvCzmDvRIjAQ_KkFrrjQd-XqxpwhoppRsppj2w5gW=s40-c)
Andreas Marschall [MVP TAPI]
news:11mki45...@corp.supernews.com...
> I'm new to tapi so I know I must be doing something dumb here, but after
> several days I'm not making progress .. thus the call for help.
>
> I've been asked to convert some old (15 yr old) DOS legacy home-brew
> networking software to work under windows. It requires that I dial from a
> current Windows machine TO a 2400 baud hayes-compatible modem. In the old
> version, I just opened the comm port and sent AT commands to the modem.
> Obviously, in the Windows world, this doesn't fly, so I've turned to TAPI.
Jerry,
You may want to take a look at the TapiComm sample from P-SDK.
See my TAPI and TSPI FAQ:
Q: Is there any sample code available ?
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_Is_there
--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK
TAPI / TSP Developer and Tester
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
* 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.
Jerry
more than I need to do. Can you give me a clue as to what would cause the
LINEERR_OPERATIONFAILED on lineOpen, when no other errors have occurred.
There is precious little doc on the meaning of this error.
"Andreas Marschall [MVP TAPI]" <Andreas....@I-B-A-M.de> wrote in
message news:OulTs0J4...@TK2MSFTNGP10.phx.gbl...
Andreas Marschall [MVP TAPI]
> Actually, I've stared at TapiComm until my head exploded, since it does WAY
> more than I need to do. Can you give me a clue as to what would cause the
> LINEERR_OPERATIONFAILED on lineOpen, when no other errors have occurred.
> There is precious little doc on the meaning of this error.
Jerry,
This error constant is used when there no specific info available what has
caused the error...
See my TAPI and TSPI FAQ:
Q: Where are TAPI errors codes defined ?
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_Where_are
Especially see my Toto® Tool TAPI_Error_Codes.
Can you reproduce the issue with TAPI Browser TB20 ?
I.e. if you encounter the LINEERR_OPERATIONFAILED from within your app,
is it then possible to lineOpen() with TB20?
Please post a TB20.log and enable Options/LogParameters and /ShowTimeStamps in
TB20.
See my TAPI and TSPI FAQ:
Q: Where can I download TAPI Browser ?
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_Where_can
Q: Is there a user guide available for TAPI Browser TB20 ?
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_Is_there_1
Andreas Marschall [MVP TAPI]
> I'm new to tapi so I know I must be doing something dumb here, but after
> several days I'm not making progress .. thus the call for help.
>
> I've been asked to convert some old (15 yr old) DOS legacy home-brew
> networking software to work under windows. It requires that I dial from a
> current Windows machine TO a 2400 baud hayes-compatible modem. In the old
> version, I just opened the comm port and sent AT commands to the modem.
> Obviously, in the Windows world, this doesn't fly, so I've turned to TAPI.
Jerry,
another option might be LINEBEARERMODE_PASSTHROUGH.
Please see MSDN for details.
Jerry
program. It compiled and linked without error. When I run tapicomm, it
lets me dial once, and it lets me disconnect .. but when I click the icon to
redial, it crashes before the 'dial' dialog appears ... crashes with
'unhandled win32 exception'
"Andreas Marschall [MVP TAPI]" <Andreas....@I-B-A-M.de> wrote in
message news:OulTs0J4...@TK2MSFTNGP10.phx.gbl...
Andreas Marschall [MVP TAPI]
> I took a closer look at tapicomm, and it's doing stuff very similar to my
> program. It compiled and linked without error. When I run tapicomm, it
> lets me dial once, and it lets me disconnect .. but when I click the icon to
> redial, it crashes before the 'dial' dialog appears ... crashes with
> 'unhandled win32 exception'
Jerry,
You may want to take a look at the modem log to see if there is anything
suspicious at re-open.
See my TAPI and TSPI FAQ:
Q: What is the ModemLog ?
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_What_is_12
Jerry
extremely impressed with your diligence and support in this news group. I'm
reporting back what I found in the hopes that someone else may benefit ..
As it turned out, the reason that lineOpen was failing on the second attempt
was because I had used LINECALLPRIVILEGE_OWNER |
LINECALLPRIVILEGE_MONITOR on the lineOpen command. When I changed this to
LINECALLPRIVILEGE_NONE, the second lineOpen succeeded. At that point, I
started seeing a failure on the second call to lineMakeCall
(LINEERR_RESOURCEUNAVAIL). A little digging found that the hComm handle
was not being closed properly on the disconnect, making it unavailable for
use on subsequent calls. At this point I can connect/disconnect repeatedly
without any problems.
Thanks again.
Jerry
"Andreas Marschall [MVP TAPI]" <Andreas....@I-B-A-M.de> wrote in
message news:#7yfrDK4...@tk2msftngp13.phx.gbl...
Andreas Marschall [MVP TAPI]
> Andreas .. first of all, let me thank you for your help/guidance. I'm
> extremely impressed with your diligence and support in this news group. I'm
> reporting back what I found in the hopes that someone else may benefit ..
Jerry, thanks for your feedback.
> As it turned out, the reason that lineOpen was failing on the second attempt
> was because I had used LINECALLPRIVILEGE_OWNER |
> LINECALLPRIVILEGE_MONITOR on the lineOpen command. When I changed this to
> LINECALLPRIVILEGE_NONE, the second lineOpen succeeded.
Using LINECALLPRIVILEGE_NONE does not open the COM port at lineOpen() but only
at lineMakeCall().
With LINECALLPRIVILEGE_NONE you won't get notifications on incoming calls.
> At that point, I
> started seeing a failure on the second call to lineMakeCall
> (LINEERR_RESOURCEUNAVAIL). A little digging found that the hComm handle
> was not being closed properly on the disconnect, making it unavailable for
> use on subsequent calls. At this point I can connect/disconnect repeatedly
> without any problems.
:-)
I guess now it works with LINECALLPRIVILEGE_OWNER | LINECALLPRIVILEGE_MONITOR
at lineOpen() too?
> Thanks again.
You are welcome.
Jerry
port would be opened in different places, but as you predicted, the program
now works properly with LINECALLPRIVILEGE_OWNER |
LINECALLPRIVILEGE_MONITOR .
In retrospect, it makes sense in that you may want to open the line not to
make a call, but to wait for an incoming call. In my case there's no need
to answer incoming calls, only to make outgoing ones. Thanks for the
insight.
"Andreas Marschall [MVP TAPI]" <Andreas....@I-B-A-M.de> wrote in
message news:uUUThiL...@TK2MSFTNGP10.phx.gbl...
Andreas Marschall [MVP TAPI]
> Great call, Andreas! I hadn't tried that, and didn't know that the serial
> port would be opened in different places, but as you predicted, the program
> now works properly with LINECALLPRIVILEGE_OWNER |
> LINECALLPRIVILEGE_MONITOR .
> In retrospect, it makes sense in that you may want to open the line not to
> make a call, but to wait for an incoming call. In my case there's no need
> to answer incoming calls, only to make outgoing ones. Thanks for the
> insight.
Jerry, you are welcome.
The difference is intentionally: if you don't need incoming calls then you
problably may not to block the COM port / the modem while you don't need it
for outgoing calls.
UniModem.TSP has a specialty with this: even when using _only_
LINECALLPRIVILEGE_MONITOR it doesn't open the COM port if there is no other
TAPI requesting LINECALLPRIVILEGE_OWNER for this device (but if there is this
other app then both apps get LINE_APPNEWCALL messages).
Usually one would expect to always get incoming call notifications when using
LINECALLPRIVILEGE_MONITOR _only_, which is actually the case with other TSPs.