Extended Line Services (or Device Specific Line Services) include all service provider defined extensions to the API. The API defines a mechanism that enables service provider vendors to extend the Telephony API using device specific extensions. The API only defines the extension mechanism, and by doing so provides access to device specific extensions, but the API does not define their behavior. Behavior is completely defined by the service provider.
The Telephony API 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 API.
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 API.
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 API.
Two functions, lineDevSpecific and lineDevSpecificFeature, and two related messages, LINE_DEVSPECIFIC and LINE_DEVSPECIFICFEATUREs, are provided whose only purpose is to provide a vendor specific extension mechanism. The lineDevSpecific operation and associated LINE_DEVSPECIFIC message enables an 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 lineDevSpecific function is generic in that little interpretation of the parameters is made by the API. The interpretation of the parameters is defined by the service provider and must be understood by an application that uses them. The parameters are simply passed through by the Telephony DLL form the app to the service provider. 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.
lineDevSpecific
Device specific escape function.
LINE_DEVSPECIFIC
Device specific message.
For convenience, a more specialized escape function is also provided. It is similar to lineDevSpecific, but places interpretation on some of the parameters. The function lineDevSpecificFeature and associated LINE_DEVSPECIFICFEATURE message allows an application 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 lineDevSpecificFeature is also vendor-specific.
lineDevSpecificFeature
Device specific escape function to allow sending switch features to the switch.
LINE_DEVSPECIFICFEATURE
Device specific message sent to the application's callback as an indication of 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.