C++/VB - Contradictory info in MSDN for lineOpen (dwAddressMode, dwPrivileges)

Asked By fdecker

17-Nov-09 12:33 PM

I am experimenting with devices that have multiple addresses to have
applications be able to ignore messages if they are not on the address
I want on a given line.  However the MSDN is less than clear in how
anyone would implement this:

1.	MSDN says in the lineOpen documentation that we must open the line
with dwAddresMode =3D LINEADDRESSMODE_ADDRESSID and specify the
dwAddressID in the LINECALLPARAMS structure. It even says that if you
don=92t specify a valid address or the LINECALLPARAMS structure is
invalid, you will get an error in lineOpen, yet in the LINECALLPARAMS
help it  says the dwAddressMode member cannot be
LINEADDRESSMODE_ADDRESSID for the lineOpen function call and if that
is not set, the dwAddressID is ignored!

2.	Further, MSDN states that setting the lineOpen dwPrvileges to
LINEOPENOPTION_SINGLEADDRESS only affects the ownership of calls that
are created by a TSP with the LINE_NEWCALL message/ What about calls
that aren=92t indicated with LINE_NEWCALL?  If an inbound call arrives
and is in the offering state, does the TSP consider this a call
created by TAPI and issue the LINE_NEWCALL?  Likewise, if I dial an
outbound call, is LINE_NEWCALL fired?  The help seems to imply that
LINE_NEWCALL is basically for when you start an application or maybe a
TSP on a device that could already have calls and these existing calls
can be reported to you.

100 points to anyone who truly understands this and can explain it ;)

Fred

18-Nov-09 01:36 AM

Fred,
on TSPI level call handles can only be generated in two ways:
1st by TAPISRV, e.g. via TSPI_lineMakeCall(), TSPI_linePickup(),
TSPI_lineUnpark();
2nd by TSP via LINE_NEWCALL.
In the 1st case TAPISRV provides the TSP with HTAPICALL htCall and expects
the TSP to fill in LPHDRVCALL lphdCall;
in the latter case TSP provides HDRVCALL hdCall and expects TAPISRV to fill
in LPHTAPICALL lphtCall.
So *all* calls that are not created via a TAPI / TSPI functions are created
via LINE_NEWCALL.
And there is no LINE_NEWCALL for calls that are generated via TAPI / TSPI
functions.



An inbound call is never generated by TAPISRV but always by the TSP via
LINE_NEWCALL.



How dod you dial?
- Via TSPI_lineMakeCall(): no LINE_NEWCALL
- Manually at the physical phone: LINE_NEWCALL



LINE_NEWCALL is a TSPI message and is not presented to TAPI apps.
TAPI2 app get a LINE_APPNEWCALL message instead.
The TSP should report pre-existing calls (existing before TSPI_lineOpen()
took place) via LINE_NEWCALL (if it can detect them).
LINE_NEWCALL is mandatory for every call to generated by the TSP.
Without LINE_NEWCALL there can be no calls (except the ones created by
TAPISRV via TSPI_lineMakeCall() etc.).
Each LINE_NEWCALL should be immediately followed by the initital
LINE_CALLSTATE message for this call.

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

22-Nov-09 03:07 PM

Hi Andreas,

How about the MSDN help?  Did you see where I see the help for
lineOpen says to limit messages to a single address you must set
dwAddresMode = LINEADDRESSMODE_ADDRESSID, yet in the LINECALLPARAMS
help is specifically says you cannot do that?  I think the call params
section must be wrong, but wondering how it got like that.  I updated
the new comments you can put into MSDN and sent the TAPI guys a note.
Hopefully they can fix it or tell me why I am wrong in my
interpretation.

Fred