TSPI Versions
Mohit
Can any one tell me, what is the latest version of TSPI and if possible,
then can any one provide me the version history along with its value for TSPI
version negotiation (i.e., line versions and extension versions.)
Thanks,
Mohit
![Andreas Marschall [exMVP TAPI]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUdVhINZ75uvCzmDvRIjAQ_KkFrrjQd-XqxpwhoppRsppj2w5gW=s40-c)
Andreas Marschall [exMVP TAPI]
news:59FE287D-AD1A-4C8F...@microsoft.com...
Mohit,
the extension versions are totally TSP-specific, so there is no general
versioning or history.
For the ExtVersion, ExtensionID and DevSpecific stuff you need to check the
particular TSP decumentation from the TSP manufacturer.
Regarding TSPIversion:
a TSP #includes <TSPI.H> which itself #cludes <TAPI.H>.
Prior to #include <TSPI.H> the TSP needs to #define TAPI_CURRENT_VERSION.
Please see TSPI.H for "#if TAPI_CURRENT_VERSION" Preprocessor Directives for
different versions and their effects.
IIRC the History is:
#define TAPI_CURRENT_VERSION 0x00010003 // TAPI 1.3 16-bit starting with Win
3.x
#define TAPI_CURRENT_VERSION 0x00010004 // TAPI 1.4 16-bit starting with
Win95(RTM)
#define TAPI_CURRENT_VERSION 0x00020000 // TAPI 2.0 32-bit starting with
NT4(RTM)
#define TAPI_CURRENT_VERSION 0x00020001 // TAPI 2.1 32-bit starting with
Win95(via Update) / Win98(RTM) / NT4(SP3)
#define TAPI_CURRENT_VERSION 0x00020002 // TAPI 2.2 32-bit starting with
Win2000
#define TAPI_CURRENT_VERSION 0x00030000 // TAPI 3.0 32-bit starting with
Win2000
#define TAPI_CURRENT_VERSION 0x00030001 // TAPI 3.1 32-bit starting with XP
AFAIK there are no specific define TAPI_CURRENT_VERSION for 64-bit OS, so
the ones for 32-bit are valid.
Unless a TSP needs to support its own MSP (TAPI 3.x) I recommend using:
#define TAPI_CURRENT_VERSION 0x00020002
--
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.
Mohit
> .
>
Actually what I was trying to ask was, when TAPISRV sends
TSPI_lineNegotiateTSPIVersion() or TSPI_lineNegotiateExVersion() it provides
the lower and higher version values in dwLowVersion and dwHighVersion
parameters. So, these parameter contains TAPI version value (i.e., 1.x, 2.x
or 3.x) or it is a provider specific version values?
If these are the provier specific version values then from where the TAPISRV
gets those values and put it in TSPI_lineNegotiateTSPIVersion() and
TSPIlineNegotiateExtVersion()?
Thanks,
Mohit
Andreas Marschall [exMVP TAPI]
> Actually what I was trying to ask was, when TAPISRV sends
> TSPI_lineNegotiateTSPIVersion() or TSPI_lineNegotiateExVersion() it
> provides
> the lower and higher version values in dwLowVersion and dwHighVersion
> parameters. So, these parameter contains TAPI version value (i.e., 1.x,
> 2.x
> or 3.x) or it is a provider specific version values?
Mohit,
the dwLowVersion and dwHighVersion in TSPI_lineNegotiateTSPIVersion()
contain always TAPI version values (e.g. 0x00020001 for TAPI 2.1),
the dwLowVersion and dwHighVersion in TSPI_lineNegotiateExtVersion() contain
TSP-specifc values values that have nothing to do with TAPI versions.
> If these are the provier specific version values then from where the
> TAPISRV
> gets those values and put it in TSPI_lineNegotiateTSPIVersion() and
> TSPIlineNegotiateExtVersion()?
The TSP-specific version values in TSPI_lineNegotiateExtVersion() are taken
by TAPISRV from lineNegotiateExtVersion(), i.e from the calling TAPI
application.
Mohit
"Andreas Marschall [exMVP TAPI]" wrote:
> "Mohit" <Mo...@discussions.microsoft.com> schrieb im Newsbeitrag
> news:E976AC78-18CE-432D...@microsoft.com...
> > Actually what I was trying to ask was, when TAPISRV sends
> > TSPI_lineNegotiateTSPIVersion() or TSPI_lineNegotiateExVersion() it
> > provides
> > the lower and higher version values in dwLowVersion and dwHighVersion
> > parameters. So, these parameter contains TAPI version value (i.e., 1.x,
> > 2.x
> > or 3.x) or it is a provider specific version values?
>
> Mohit,
> the dwLowVersion and dwHighVersion in TSPI_lineNegotiateTSPIVersion()
> contain always TAPI version values (e.g. 0x00020001 for TAPI 2.1),
> the dwLowVersion and dwHighVersion in TSPI_lineNegotiateExtVersion() contain
> TSP-specifc values values that have nothing to do with TAPI versions.
>
So in this case, if TAPI application supports only version 3.x and the TSP
is not supporting version 3.x then the result of calling
TSPI_lineNegotiateTSPIVersion() will be LINEERR_INCOMPATIBLEAPIVERSION or
TAPISRV will play any role in such case?
> > If these are the provier specific version values then from where the
> > TAPISRV
> > gets those values and put it in TSPI_lineNegotiateTSPIVersion() and
> > TSPIlineNegotiateExtVersion()?
>
> The TSP-specific version values in TSPI_lineNegotiateExtVersion() are taken
> by TAPISRV from lineNegotiateExtVersion(), i.e from the calling TAPI
> application.
>
So in this case, the TAPI application should be aware of extension version
of the TSP?
Means the manufacturer needs to provide the extension versions supported by
TSP in advance?
> --
> 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.
>
>
>
> .
>
Andreas Marschall [exMVP TAPI]
> Thakns Andreas,
Mohit, you are welcome.
> So in this case, if TAPI application supports only version 3.x and the TSP
> is not supporting version 3.x then the result of calling
> TSPI_lineNegotiateTSPIVersion() will be LINEERR_INCOMPATIBLEAPIVERSION or
> TAPISRV will play any role in such case?
No TAPISRV will function as a mapper for TAPI3 apps.
So any 32-bit TSP will be implicietly able to be used from TAPI3 by design
of TAPISRV.
A TSP only needs to explicitely support TAPI 3.x if it has its own MSP.
> So in this case, the TAPI application should be aware of extension version
> of the TSP?
Exactly.
A TAPI app using DevSpecifc stuff from a TSP needs be aware of the TSP
specification regarding the TAPI Extended Services incl. ExtVersion.
> Means the manufacturer needs to provide the extension versions supported
> by
> TSP in advance?
Yes, without the TSP documentation from the manufacturer
TAPI Extended Services cannot be used properly.
Mohit
> > So in this case, if TAPI application supports only version 3.x and the TSP
> > is not supporting version 3.x then the result of calling
> > TSPI_lineNegotiateTSPIVersion() will be LINEERR_INCOMPATIBLEAPIVERSION or
> > TAPISRV will play any role in such case?
>
> No TAPISRV will function as a mapper for TAPI3 apps.
> So any 32-bit TSP will be implicietly able to be used from TAPI3 by design
> of TAPISRV.
> A TSP only needs to explicitely support TAPI 3.x if it has its own MSP.
>
>
So, if the TSP does not have an MSP and it supports only 2.x functions, then
what will TAPISRV will do? will it fill 3.x in lpdwAPIVersion or will it fill
2.x in lpdwAPIVersion against lineNegotiateAPIVersion() called by TAPI
application?
what i am trying to ask is, is it possible that the TAPISRV communicates
with TSP as per 2.x functions and with TAPI application, as per 3.x functions
(no MSP or wave driver is present)?
>
> --
> 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.
>
>
>
> .
>
Andreas Marschall [exMVP TAPI]
> So, if the TSP does not have an MSP and it supports only 2.x functions,
> then
> what will TAPISRV will do? will it fill 3.x in lpdwAPIVersion or will it
> fill
> 2.x in lpdwAPIVersion against lineNegotiateAPIVersion() called by TAPI
> application?
Mohit,
it will be 2.x.
lineNegotiateAPIVersion() is TAPI 1.x/2.x function, hence the TAPI app is
1.x/2.x too, and it doesn't make any sense to try to negotiate 3.x.
You may want to try it yourself with MS TAPI Browser TB20 / TB3x an check
what your TAPISRV is negotiating with your TSP.
> what i am trying to ask is, is it possible that the TAPISRV communicates
> with TSP as per 2.x functions and with TAPI application, as per 3.x
> functions
> (no MSP or wave driver is present)?
Yes, TAPISRV works as a mapper.