- Educational Resources
- Development Tools & Configurations
- Compliance Testing
The Avaya ACE Foundation Toolkit APIs are no longer supported by DevConnect: developers are advised to use the Avaya Breeze™ APIs to create custom snap-ins.
About the Foundation Toolkit
The Avaya Agile Communication Environment™ (Avaya ACE™) Foundation Toolkit supports the development of communications-enabled solutions that leverage capabilities provided by Avaya Aura® Session Manager.
The Foundation Toolkit comprises the following components:
- Foundation Runtime Services: The Foundation Runtime Services are installed on the Avaya ACE server and provide the underlying media and communications capabilities used by sequenced and endpoint applications. The services are accessed via the Foundation Toolkit APIs.
- Foundation Toolkit APIs: The Java APIs enable the development of custom applications that access the Foundation Runtime Services.
- The Foundation Toolkit API is a relatively low level interface that provides a rich set capabilities and supports the development of sequenced and endpoint applications. A basic knowledge of Session Initiation Protocol (SIP) is useful for debugging client applications that use the API.
- The Sequenced Template API provides an easy-to-use interface for the rapid development of sequenced applications. The API provides simple methods designed to perform common sequenced application actions, such as allowing, blocking or redirecting calls.
- Foundation SDK: The Foundation SDK comprises developer documentation, sample applications and the client-side Java APIs.
- Avaya Media Server: The Avaya Media Server supports the media capabilities provided by the Foundation Toolkit Media service, including the ability to host and play messages, to collect DTMF digits, to record calls, and to set up and manage ad hoc conferences.
Sequenced Application Development
A sequenced application is one of a series of client applications that are invoked in a predefined order by Session Manager during call set up to add custom features to calls. Sequences are defined at user level for both the origination (calling party) and termination (called party) sides of calls. When a call is initiated, the caller's instance of Session Manager routes the SIP session initiation request through each application in the caller's origination sequence, then the callee's instance of Session Manager (which may or may not be the same as the caller's) routes the request through each application in the callee's termination sequence, before finally delivering the call to one of the callee's SIP endpoint devices.
The Foundation Toolkit API enables the creation of sequenced applications that leverage the capabilities of the following Foundation Runtime Services:
- Proxy Routing Service allows the application to inspect the call (i.e. read SIP header details) and choose whether to proxy the call onwards unaltered, redirect the call to a different endpoint address or reject the call. The Proxy Routing Service supports capabilities such as call barring, call screening and call logging.
- B2BUA (Back-to-back User Agent) Routing Service allows the client application to insert itself into the call path so that it can control the call and, in conjunction with the Media Service (see Complementary Foundation Runtime Services, below), inject media services into the call. The B2BUA Routing Service supports capabilities such as Interactive Voice Response (IVR) processing, call recording, playing announcements in calls and collecting DTMF digits. Note, however, that the service does not support the creation of conference calls.
Endpoint Application Development
An endpoint application is a client application that acts as the origination or destination endpoint in a SIP call flow. An endpoint application has its own public address in the form of a SIP or SIPS URI, which is known as its "Address of Record". The Foundation Toolkit supports three different types of endpoint application:
Calls are made directly to the application's own address-of-record: the application is the intended callee. Such applications are referred to as "Named" because they have a public identity, i.e. their address-of-record, that users deliberately call to access them. An example is a dial-in conferencing application.
Calls are made to a user's address-of-record, but are forwarded or redirected to the application's address-of-record, perhaps by a Sequenced application in the intended callee's termination sequence. These are known as "Delegate" applications because they have been delegated to handle calls on behalf of a user. An example is a voicemail application to which calls are forwarded when the intended callee is unavailable. Note that a voicemail application can also act a Named application when users call it directly to access their voicemails.
Virtual Endpoint Applications
Calls are made to a user's address-of-record but are received by the application, which is registered as one of the user's contact devices at that address. These are known as "Virtual Endpoint" applications because they act as a virtual representation of a real-life user. An example is a personal assistant application.
The Foundation Toolkit API enables the creation of endpoint applications that leverage the capabilities of the following Foundation Runtime Services:
- Registration Service enables a client application to register against an Address of Record.
- Virtual Endpoint Service enables a client application to make outbound calls, process inbound calls and move dialogs between calls, thereby allowing the injection of media services into calls and the creation of conference calls.
Note that sequenced applications cannot act as endpoints and therefore cannot be registered against an Address of Record.
Complementary Foundation Runtime Services
The Foundation Toolkit API also enables client applications to access capabilities provided by the following Foundation Runtime Services:
- Application Binding Service enables a client application to bind itself to an Avaya ACE server and listen for status changes affecting the binding.
- Dialog State Event Service enables a client application to subscribe and respond to dialog events generated when the state of a call changes, for example, from confirmed to terminated.
- Inbound Dialog Service enables a client application to listen for inbound calls.
- Media Service enables a client application to inject media services into a call.
- Registration Event Service enables a client application to subscribe and respond to events generated when endpoints are registered or deregistered against an Address of Record.
Required Network Elements
The communications network elements required by the Foundation Toolkit are:
- Avaya ACE server: on which the Foundation Runtime Services are deployed.
- Avaya Aura System Manager: provides various management services including the configuration of application sequences.
- Avaya Aura Session Manager: routes calls through a sequence of applications, or to and from endpoint applications.
- Avaya Media Server - required to provide media services, such as call recording, playing announcements and creating conference calls, using the Foundation Toolkit Media Service.
- Avaya Aura Communication Manager deployed as a feature or evolution server: an optional element which may be included in application sequences.