The services provided by the line and phone abstractions of the Telephony API can be partitioned into three classes:
Basic Services are a minimal subset of core services. They must be provided by all service providers. The function contained in basic telephony roughly correspond to that of POTS. The basic telephony API subset is listed later in this chapter. Phone device services are not part of basic telephony.
Supplementary Services are the collection of all the services defined by the API, but not included in the basic telephony subset. It includes all so-called supplementary features found on modern PBXs including hold, transfer, conference, park, etc. All supplementary features are optional. This means that a service provider decides which of these services it does or does not provide. An application can query a line or phone device for the set of supplementary services it provides. Note that a single supplementary service may consist of multiple function calls and messages. It is important to point out that the Telephony API defines the meaning (i.e., behavior) for each of these supplementary features. A service provider should only provide a supplementary telephony service if it can implement the exact meaning as defined by the API; if not, the feature should be provided as an extended telephony service.
Extended Services (or Device Specific Services) include all service provider defined extensions to the API. A mechanism is defined in the API that allows service provider vendors to extend the Telephony API using device-specific extensions. Since the API only defines the extension mechanism, definition of the extended service behavior must be completely specified by the service provider.
The extension mechanism allows service provider vendors to define new values to enumeration types and bit flags, as well as to add fields to data structures. The interpretation of extensions is keyed off of the service provider's manufacturer ID. Special function and callbacks are provided in the API that allow an application to directly communicate with a service provider. The parameter profiles are again defined by the service provider. Vendors are not required to register in order to be assigned a unique Manufacturer ID. Instead, a utility is provided that allows each vendor to generate a unique vendor ID locally. The unique ID is composed of an IP network address, a random number, time of day.
In addition, a range of values are reserved to accommodate future extensions that are considered common.