Re: LINECALLSTATE_CONNECTED -> delay

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance




"ReTF" <re.tf@xxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:u$ZHgvvgFHA.3256@xxxxxxxxxxxxxxxxxxxxxxx
> 10:54.18.695 : Calling lineOpen
> 10:54.18.960 : lineOpen returned SUCCESS

ReTF,
what deMediamodes did you use? (Maybe _DATAMODEM ?)
Check "Params" check box...

Btw. I asked to
> > enable Options/LogParameters


> 10:54.26.441 : Calling lineGetID

What szDeviceClass did you use? (Maybe "comm/datamodem")
Check "Params" check box...

I recommend using lineGetID on the call (of course after connect).


> 10:54.26.456 : lineGetID returned SUCCESS
> VARSTRING
> dwTotalSize=x1000
> dwNeededSize=x1c
> dwUsedSize=x1c
> dwStringFormat=x4, BINARY
> dwStringSize=x4
> dwStringOffset=x18
> 00000000 xxxxxxxx xxxxxxxx xxxxxxxx ....

This binary doesn't look like struct of
HANDLE hComm; // file handle to data modem
CHAR szDeviceName[1]; // name of data modemPresumable you didn't use
szDeviceClass "comm/datamodem"...


> 10:54.48.121 : received LINE_APPNEWCALL
> device=x101f0
> cbInst=x0
> param1=x0,
> param2=x10212,
> param3=x4, OWNER
> 10:54.48.152 : received LINE_CALLSTATE
> device=x10212
> cbInst=x0
> param1=x2, OFFERING
> param2=x0,
> param3=x0,
> 10:54.51.659 : Calling lineAnswer
> 10:54.51.675 : lineAnswer returned x10245
> 10:54.51.690 : received LINE_CALLSTATE
> device=x10212
> cbInst=x0
> param1=x4, ACCEPTED
> param2=x0,
> param3=x0,
> 10:55.29.3 : received LINE_REPLY
> device=x0
> cbInst=x0
> param1=x10245,
> param2=x0,
> param3=x0,
> 10:55.29.19 : received LINE_CALLSTATE
> device=x10212
> cbInst=x0
> param1=x100, CONNECTED
> param2=x0,
> param3=x0,
>
> But the diference (10:55.29.3 - 10:55.29.19) is not true, I wait 20 seconds
> to '10:55.29.19 : received LINE_CALLSTATE' be showed in the log, and not
> 00:00.00.17

Maybe you are refering to the long dealy between:
> 10:54.51.659 : Calling lineAnswer

> 10:55.29.19 : received LINE_CALLSTATE
> param1=x100, CONNECTED

This may be the time required for protcol negotiation between modem on data
calls...

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



.



Relevant Pages

  • Re: Renaming Remotesp.tsp
    ... > 19:14.35.100: Calling lineInitializeEx ... > 19:14.41.208: lineInitializeEx returned SUCCESS ... > 19:14.54.898: lineOpen returned SUCCESS ... > 19:15.3.440: lineGetDevCaps returned SUCCESS ...
    (microsoft.public.win32.programmer.tapi)
  • Re: Renaming Remotesp.tsp
    ... 19:14.35.100: Calling lineInitializeEx ... 19:14.41.208: lineInitializeEx returned SUCCESS ... 19:14.54.898: lineOpen returned SUCCESS ... 19:15.3.440: lineGetDevCaps returned SUCCESS ...
    (microsoft.public.win32.programmer.tapi)
  • Re: Siemens HiPath 3000 PBX and CallerID
    ... 12:2.28.274: Calling lineNegotiateAPIVersion ... 12:2.28.274: lineNegotiateAPIVersion returned SUCCESS ... 12:2.48.573: lineOpen returned SUCCESS ... 12:4.18.122: lineGetCallInfo returned SUCCESS ...
    (microsoft.public.win32.programmer.tapi)
  • Re: using LineAnswer in TB20 - failed
    ... > 7:55.34.595: Calling lineGetCallInfo ... > 7:55.34.605: lineGetCallInfo returned SUCCESS ... > dwConnectedIDFlags=x20, UNKNOWN ... > 7:54.16.589: lineOpen returned SUCCESS ...
    (microsoft.public.win32.programmer.tapi)
  • Re: using LineAnswer in TB20 - failed
    ... For lineAnswer(), I tried again with TB20 and with following steps. ... 7:55.34.605: lineGetCallInfo returned SUCCESS ... 7:54.4.508: Calling lineInitializeEx ... 7:54.16.589: lineOpen returned SUCCESS ...
    (microsoft.public.win32.programmer.tapi)