2.3.13.2 Version Negotiation
The TAPI DLL passes the Service Provider a range of interface versions over which it is willing to operate. The Service Provider compares this with the range of interface versions over which it is willing to operate. The Service Provider returns the highest version number where these ranges overlap. This signifies that the Service Provider is "willing" but not yet "committed" to operate at that version level. When the TAPI DLL opens the phone, it includes the negotiated version number as a parameter. A successful completion of the Open commits both the TAPI DLL and the Service Provider to operating that device at that interface version number until the phone is closed. TSPI Version negotiation typically happens just once.
Negotiation of a device-specific extension version can happen multiple times, both before and after the phone is opened. The TAPI DLL passes a version range, the Service Provider chooses and returns a value from this range. Normally, the Service Provider has device-specific extensions disabled. The TAPI DLL can enable a particular version level by invoking a "select" procedure. This commits both the TAPI DLL and Service Provider to operating at that extension version level until the selection is canceled. During the time that a device-specific extension is in effect, an attempt to negotiate an extension version level should allow only the version level that is currently in effect. After the device-specific extension is canceled, a different version can be negotiated and selected.
TSPI version negotiation necessarily happens very early in initialization after the driver is loaded. Several other operations need to be completed before the driver is ready for "normal" operations such as retrieving device capabilities and opening devices. These early initialization operations all accept an already-negotiated TSPI version number as a parameter. Once a device is opened, the TSPI version number takes effect for that device and survives as long as that device remains open. Thus a fine-detail look at initialization can be shown as follows:
A fine-grained view of initialization sequence is shown. The driver loads and unloads through symmetric triples of standard device driver messages. Once the driver is loaded, the TAPI DLL can negotiate the interface version, adjust the device ID number range for this device, and set up callbacks. Following that, "normal" operations such as capability queries, and open/close of devices can proceed.