|
|
|
|
|
The interface provided by the IRAPI offers a standard development interface for voice-telephony applications. The IRAPI provides a high-level, C-language interface to accomplish both voice-processing and telephony functions. IRAPI's capabilities include:
The IRAPI includes a general mechanism for starting applications in response to network events.
The IRAPI is designed to allow application developers to write applications easily, while at the same time provide a rich set of options. In any API, these two goals can be in conflict. In order to avoid burdening commonly used functions with many parameters, library parameters are used to control seldom-needed, minor variations of a function's behavior. These parameters can be queried and set before the function is invoked. All parameters have defaults suitable for most applications. Parameters may be channel-specific or system-wide. For descriptions of the IRAPI commands that are available on the Avaya Interactive Response system, see IRAPI functions.
Application structure and control
The IRAPI supports voice applications that can serve multiple telephone channels simultaneously. Multi-channel applications typically manage each channel of the application independently. This usually involves maintaining state information for each channel.
Note:
Single-channel applications do not necessarily extend to a multi-channel applications easily, but multi-channel applications are often almost as easy to write as single-channel applications.
Most IRAPI functions that request voice and telephony services are asynchronous (that is, non-blocking) functions. These functions return immediately after initiating a service request rather than blocking until the service is complete. When a function returns, control is returned to the application so that it can perform other duties while the requested service is being carried out. These other duties may include servicing a separate telephone channel, accessing a host, or querying a database.
Control is passed between the IRAPI and the application. Applications pass control to the IRAPI so that the library can service requests from hardware devices in real time. The IRAPI passes control to the application by generating events. An event is the notification that the IRAPI gives to an application when some condition occurs. In the standard case, applications block in the IRAPI until an event is generated. Events are generated by many conditions. Most importantly, events are generated when asynchronously requested services are completed. Examples of service-completions include completing voice playing or recording, sending touch-tone digits, and the timeout of the IRAPI clock.
The IRAPI allows an application to associate an event with the specific service request (that is, specific IRAPI library calls) using a ``tag'' with the specific service requests from the IRAPI. Applications pass a tag to the IRAPI when voice or telephony services are requested. The tag is included with the event information returned to the application.
The IRAPI allows applications to control which events are reported as well as which conditions cause interrupts. An interrupt is the termination of voice/telephony functions when some condition occurs. Most IRAPI interrupts are controlled by the application, but there are some conditions that cause voice functions to terminate automatically (such as reaching end of a file during a play). Internally, interrupt processing for certain events (notably touch-tone arrivals) is handled as a special case to minimize response time to the event. Note that IRAPI interrupts are not the same as system events.
Resource allocation
The IRAPI provides applications with access to abstract capabilities and does not require the application to directly manage the hardware resources required to provide those capabilities.
The IRAPI attempts to make resources available when the application calls functions that implicitly require resources (for example, play or record). When a channel frees the resource, the IRAPI makes it available to other applications running on the platform. In addition, the IRAPI supports reserving, freeing, and querying of resources. Where required, an application may pre-allocate resources to guarantee that those resources are available when needed. When applications need to be isolated applications from each other to avoid resource contention, an application can be restricted to use a only subset of available resources.
The IRAPI provides consistent resource allocation failure modes for both explicit and implicit requests for dynamic resources. If a required resource is not immediately available, applications can fail the request immediately, arrange to wait for the resource forever, or wait for the resource for some fixed period of time. In the last case, if the resource is not available within the time period, the application is notified of the failure with an event.
Library states are used by the IRAPI library to maintain information about channel activities and to prevent applications from attempting illegal operation sequences. In most cases, applications respond to the events as they occur and seldom need to know the library state.
