CF2.0 WM5 Comms help required please

  • Thread starter Thread starter Tym Huckin
  • Start date Start date
Hi ctacke,
I think you may be a bit confused. They are two completely separate things.
Megapipe's product provides serial transfer protocols like kermit and the
like. OpenNETCF's is for the telephony API (TAPI), which is used for
controlling something like a GMS modem (dial numbers, intercept phone calls,
etc).
Click to expand...

Right. I was looking for "TAPI windows mobile" and found this control,
but now I can see the TAPI-based modem operation it is only available
in theirs ActiveX or .NET control (not .NET CF).
http://www.mw6tech.com/megapipe/net/megapipe.html

But, having you read the previous post, do you know if this is
possible (like Tym Huckin asked):
- Make a call from a GSM built in modem into a PDA (like XDA/XDAII)
with TAPI
- Get the handle of the comm and send binary/ascii data, WITHOUT IP
(no RASDial, no PPP, etc)
(like a simple terminal application)
(I know this IS possible, I'm just asking for a sample working code)

The nearest I went was to discover "TapiComm" C++ sample from the P-
SDK. But this is now deprecated and doesn't compile any more with
VS2005.

So, I think this MUST BE a trivial question, but... please "how do
I...?"

Many thanks for your info, or hints about getting that info
 
Offhand no, I don't know, but then I'm not our resident TAPI expert. I'll
see if I can get an answer for you from our guy who is. I'm inlined to
think no, though, as how would you pass the data if you don't have a
protocol like TCP for delivery confirmation, routing, etc.? You're thinking
something akin to a raw serial port? How would the receiver handle the
incoming data?
 
Hi ctacke,
I'll see if I can get an answer for you
from our guy who is.
Click to expand...

Many thanks!!! It would be very nice.

You're thinking something akin to
a raw serial port? How would the
receiver handle the incoming data?
Click to expand...

Yes, I'm thinking something similar to a raw serial port, once the
connection is established. The receiver must wait for incoming
(formated) data, and then emit a response to that.

No need to route anything because when the GSM modem call an analog
one, the phone network does all the routing. The connection is then
point-to-point from the point of view of the software. You write here,
and it arrives at the other endpoint (just like a TCP socket).

Again, many thanks for your help
 
Yes, but how does it arrive? In what "format"? I assume you'd then want
the receiver to get a handle to the incoming call? And then do what? Call
ReadFile on that handle? That pre-supposed a stream interface layer below
to handle the read, which TAPI certainly doesn't expose.

Again, I'll ask, but logically I have doubts about whether this is possible.

-Chris
 
Yes, but how does it arrive? In
what "format"? I assume you'd
then want the receiver to get a
handle to the incoming call?
And then do what? Call
ReadFile on that handle?
That pre-supposed a stream
interface layer below to handle
the read, which TAPI certainly
doesn't expose.
Click to expand...

Uhm... I was hoping that this handle TAPI returns could be used with
serial comms (or another stream interface layer in this case). Not
with TAPI itself. Only need TAPI to make the call.

The problem sits on the fact that I can not directly use the COM port
the GSM modem has (you said it too), so I must "dial" the GSM modem
with TAPI, and then use a handle, if available, to send the data with
other API.

I read in other newsgroups that once the connection is established
(with this XDA PPC with GSM modem), the system creates a new COM Port,
called "COM9:", so you can connect to it and send and receive data. To
make it more portable between different PPC brands, maybe I can
enumerate available ports at the beginning, then make a call with
TAPI, enumerate ports again and connect to the new one (just a guess,
If you ask your colleague he maybe laughs at this :-) oops...). Or
maybe a simpler solution exists.

How the other endpoint receives the data is not worrying me at the
moment, because I want to test with a receiving Windows 98 computer
with Hyperterminal and an analog modem (so no problem, the software
there it is done).
 
Hi ctacke, did you talk with your colleague about this?

FYI, in other post I'm also participating, a person says that he was
able to "dial" the internal modem with this TAPI CallParams:

lpCallParams->dwBearerMode = LINEBEARERMODE_DATA;
lpCallParams->dwMediaMode = LINEMEDIAMODE_DATAMODEM;
(Language is eVC++ 4.0)

So, I think that if TAPI has been ported to .NET with your Telephony
API, it has to be possible to get to the data transfer stage!!! at
last.... :-)

Thanks for your time
 
The consensus is that you can actually use TAPI and then get a handle which
can be used for serial-like comms (with WriteFile, etc.). I don't have a
sample as it's evidently not the easiest thing to get working.
 
Hi ctacke,
The consensus is that you can actually
use TAPI and then get a handle which
can be used for serial-like comms (with
WriteFile, etc.). I don't have a sample
as it's evidently not the easiest thing
to get working.
Click to expand...

Ok, but your Telephony API (opennetcf.org) is capable of let me "get a
handle" ? I have to test it now! BTW, I downloaded your trial and
samples and could not get them to work (?!). Maybe it is I lack some
required libraries, I will check it again.

The question about "get a handle" was the original one, so it remains
unanswered :-(

But at least this procedure is the right one!!

I was told how to get a HANDLE with eVC++, when TAPI tells the line is
connected:
case LINECALLSTATE_CONNECTED:
..........
..........
hCommFile = *((LPHANDLE)((LPBYTE)lpVarString + lpVarString ->
dwStringOffset));

So you can get the handle this way. Now... the question is, will it be
possible to get the handle in a more-or-less way with your Telephony
API. I will see...

(btw, credit of above code goes to Fabio, comments in this group:)
http://groups.google.com/group/micr...read/thread/30c8cffdaf1481ff/c4b8011a096833a1

Please, make any comment you like in the meanwhile. I can't test it
right now, but I will do and post here the results.

Many thanks!!
 
Sorry, in the previous code I forgot to write the call where
lpVarString is loaded:

So the code is:
case LINECALLSTATE_CONNECTED:
..........
lReturn = lineGetID(0, 0, g_hCall, LINECALLSELECT_CALL, lpVarString, "comm/datamodem");
..........
hCommFile = *((LPHANDLE)((LPBYTE)lpVarString + lpVarString -> dwStringOffset));
Click to expand...

g_hCall is set before: lineMakeCall(g_hLine, &g_hCall,
lpszDialableSubstring, 0, lpCallParams)

All this code comes from TapiCode.C (original TapiComm sample from the
SDK, removed in 2003, google for TapiComm.zip if you need it).
 
Back
Top