2.4.3 Extended Line Services
Extended Line Services (or Device Specific Line Services) include all service provider defined extensions to the SPI. The SPI defines a mechanism that enables service provider vendors to extend the Telephony SPI using device specific extensions. The SPI only defines the extension mechanism, and by doing so provides access to device specific extensions, but the SPI does not define their behavior. Behavior is completely defined by the service provider.
The Telephony SPI consists of scalar and bit flag constant definitions, data structures, functions, and callback messages. Procedures are defined that enable a vendor to extend most of these as follows:
For extensible scalar data constants, a service provider vendor may define new values in a specified range. As most data constants are DWORDs, typically the range 0x00000000 through 0x7FFFFFFF is reserved for common future extensions, while 0x80000000 through 0xFFFFFFFF are available for vendor specific extensions. The assumption is that a vendor would define values that are natural extensions of the data types defined by the SPI.
For extensible bit flag data constants, a service provider vendor may define new values for specified bits. As most bit flag constants are DWORDs, typically a specific number of the lower bits are reserved for common extensions while the remaining upper bits are available for vendor specific extensions. Common bit flags are assigned from bit zero up; vendor specific extensions should be assigned from bit 31 down. This provides maximum flexibility in assigning bit positions to common extensions versus vendor specific extensions. A vendor is expected to define new values that are natural extensions of the bit flags defined by the SPI.
Extensible data structures have a variable sized field that is reserved for device specific use. Being variable sized, the service provider decides the amount of information and the interpretation. A vendor that defines a device specific field is expected to make these natural extensions of the original data structure defined by the SPI.
Two functions, TSPI_lineDevSpecific and TSPI_lineDevSpecificFeature, and four related messages, LINE_DEVSPECIFIC, LINE_CALLDEVSPECIFIC, LINE_DEVSPECIFICFEATURE, and LINE_CALLDEVSPECIFICFEATURE, are provided whose only purpose is to provide a vendor specific extension mechanism. The TSPI_lineDevSpecific operation and associated LINE_DEVSPECIFIC and LINE_CALLDEVSPECIFIC messages allow the TAPI DLL's client application to access device-specific line, address, or call features that are unavailable via the Basic or Supplementary Telephony Services. The parameter profile of the TSPI_lineDevSpecific function is generic in that little interpretation of the parameters is made by the SPI. Device handle parameters have TSPI-defined meanings and are translated appropriately between the application and the Service Provider. Generic parameters are simply passed through unmodified. The interpretation of the generic parameters is defined by the service provider and must be understood by an application that uses them. An application that relies on device specific extensions will not generally work with other service providers; however, applications written to the Basic and Supplementary Telephony Services will work with the extended service provider.
The TAPI DLL's implementation for the device-specific functions and messages is "pass-through". The TAPI DLL does not examine or modify the "generic" device-specific parameters and buffers. The TAPI DLL does take care of mapping back and forth between the application-level opaque handle values used at the TAPI level and the Service Provider level opaque handle values used at the TSPI level.
There is an important consequence of the pass-through nature of the generic parts of the device-specific extensions when this handle-translation issue is considered. A Service Provider has no way to relate the handles used at the TSPI level to those appearing at the TAPI level except by passing them through the predefined handle parameters and fields. Any handle put into the generic extension area is untranslated by the TAPI DLL as it is passed between application and Service Provider. The designer of a Service Provider extension should generally not define extensions that pass handles in this way.
The appropriate approach when defining a device-specific extension that needs to refer to specific devices without using handles is to refer to them using their absolute device identification. The device ID used in opening a line at the TAPI level, for example, is strictly the same value that is used at the TSPI level to open the line. Similarly, a (line device ID, address ID) tuple that uniquely identifies an address at the TAPI level uses the same values to identify the same thing at the TSPI level. This is the motivation for the TSPI_lineSetDeviceIDBase procedure. It adjusts the Service Provider's device ID numbering to be the same as the numbering used at the TAPI level. This gives the Service Provider designer the flexibility to use device IDs to identify devices in device-specific extensions.
TSPI_lineDevSpecific
Device specific escape function.
LINE_CALLDEVSPECIFIC
Device specific message related to a call.
LINE_DEVSPECIFIC
Device specific message related to a line.
For convenience, a more specialized escape function is also provided. It is similar to TSPI_lineDevSpecific, but places interpretation on some of the parameters. The function TSPI_lineDevSpecificFeature and associated LINE_DEVSPECIFICFEATURE and LINE_CALLDEVSPECIFICFEATURE messages allow the TAPI DLL to emulate button presses at the line's feature phone. As feature phones and the meanings of their buttons are vendor-specific, feature invocation using TSPI_lineDevSpecificFeature is also vendor-specific.
TSPI_lineDevSpecificFeature
Device specific escape function to allow sending switch features to the switch.
LINE_CALLDEVSPECIFICFEATURE
Device specific message sent to the application's callback as an indication of call-related features sent to the switch.
LINE_DEVSPECIFICFEATURE
Device specific message sent to the application's callback as an indication of line-related features sent to the switch.
As mentioned earlier, there is no central registry for manufacturer IDs. Instead a unique ID generator is made available as part the Telephony Developer Toolkit.