Callback trigger

The user informs the system of his desire to make a callback call in one of several available ways. The part of the system capable of interacting with the end user in some way and, upon receiving certain information from him, initiating the callback process, is called the callback trigger. Several types of callback triggers are available, and of course new ones can be invented and developed.

This is perhaps the most common trigger type; it is available in PortaSIP as a built-in IVR application.

The task of this module is to:

• Intercept an incoming call and collect information about the ANI number.
• Authenticate this number with PortaBilling.
• Disconnect the incoming call.
• Establish an outgoing call to the destination (the caller’s number).
• Once this call is connected, hand over call processing to the callback engine which will do the rest (give the balance, ask for destination, etc.).

The user dials a certain access number, the call is forwarded by his telco operator and the incoming call arrives to PortaSIP where a callback trigger application is configured. The application does not answer the call; instead it records the originating phone number (ANI or CLI number) and then disconnects it. Since the call is never connected, the end user is not charged by the telco operator. Now the application has the user’s phone number and can therefore initiate a call back to him. Then an IVR is initiated which gives the user his current balance and prompts him for the destination number, etc.

Needless to say, this service only works when the correct caller info is delivered to PortaSwitch. If information about a user’s phone number is not available during an incoming call or if it is garbled (for instance, only the four last digits are discernible) then there is no way to call back the user. Usually, you can only rely on ANI information for calls made within the same country. Thus, if you have an access number in the Czech Republic and your users make calls from within the Czech Republic (fixed or mobile phones), you receive correct ANI information. But if someone calls your access number from Slovakia or France, there is a high chance that either no ANI will be provided at all, or else it will be provided in a local format such as 02345464 (no country code), in which case it is impossible to determine whether this number is actually in the Czech Republic, Slovakia or France unless a correct translation rule is applied to the ANI number.

This is a slightly different approach to the callback function described above. In a situation where a correct ANI number is not likely to be available, one of the remaining options is to allocate an access number to each of your callback users.

Each access number is associated with a Callback calling IVR application and is provisioned as the account ID in PortaBilling. Therefore, every callback user has an account in PortaBilling with an account ID that is equal to the callback access number. The user then enters the user’s actual phone number into the account’s properties (in the Associated Number field on the Service configuration panel).

When the user wishes to make a callback call, he simply makes a call to his dedicated access number. Every incoming call to this number will be dropped, but the system is triggered to initiate a call to the phone number associated with this access number. After that, the call is handled similarly to an ANI callback.

Thus, the DNIS callback functions as follows:

• It intercepts the incoming call and gets information about the DNIS number (access number dialed by the customer).
• Authenticates this number with PortaBilling.
• Disconnects the incoming call.
• Establishes an outgoing call to the number specified in the Associated Number property for the account in PortaBilling.
• After the call is connected, the trigger relays call processing to the callback engine which does the rest (gives the balance, asks for destination, etc.).

One definite advantage of this method is that it can be used by callers located in one country who have been provisioned access numbers from a different country.

A disadvantage is that you will need a relatively large quantity of access numbers.

This is yet another type of callback. Here a caller is not authenticated by the ANI number. The ANI number is noted by the trigger and the call is dropped. The so-called internal account is authenticated and authorized for the call leg to the party initiating the callback. Therefore, the internal account must be provisioned in the system and defined for the trigger.

After the callback is established to the party that initiated it, the IVR is brought up, prompting the caller to enter the PIN. After the PIN number is collected, the system searches for an account in PortaBilling with the same account ID as the PIN entered by the caller. Once found, the account is authorized for the outgoing call leg. Upon successful authorization, the call is handled the same way as in the ANI callback.

The PIN callback trigger functions as follows:

• It intercepts the incoming call and records information about the ANI number.
• Checks for the internal account.
• Authenticates the internal account with PortaBilling.
• Disconnects the incoming call.
• Establishes an outgoing call to the destination (the caller’s number).
• And after the call is connected, relays call processing to the callback engine.
• The callback engine collects the PIN number and authenticates the PIN with PortaBilling.
• Upon successful PIN authentication, the callback engine performs further call processing (gives the balance, asks for destination, etc.).

The advantage of this method is the ability of the service provider to prevent service abuse, allowing the system to initiate callbacks to only a certain number of destinations. This is achieved by assigning a special tariff to the internal account’s product.

The ANI / DNIS / PIN callback trigger configuration consists of associating an access number with a callback calling IVR application and customizing the general parameters for the application. These include languages and authentication by ANI, DNIS or PIN.

The step-by-step configuration of the ANI Callback trigger can be found in the Setting up an ANI Callback handbook. For the complete overview of the available IVR application configuration parameters, please also consult the APPENDIX A. Configuration parameters for IVR applications section.

The purpose of this module is to allow end users to initiate callback calls by filling in a form on the web interface.

When a user wants to initiate a callback call, he just goes to your website, enters all the required information (username, password, phone number, etc.) and clicks the Submit button to initiate the call. This request is delivered to the callback trigger via HTTP or HTTPS, and the callback call is initiated.

The workflow of the web callback trigger is as follows:

• The customer retrieves the web form and fills in values such as account ID, password, first number, second number, etc.
• By pressing the submit button the customer’s request goes to the CGI script (hosted on PortaSIP).
• The script processes the input parameters and then relays the callback request.

A sample HTML document that contains a form with callback parameters is built in, and available upon the configuration of web callback. This document is only an example of the required parameters; you can customize it (change text and colors, insert pictures, etc.) or even design the form to be a part of your existing customer portal. However, it is important that all of the form’s parameters and their names be left unchanged.

You may also entirely omit this web form where users fill in data and press the submit button. In this case, the HTTP request for callback would be sent from another application.

An advantage of this method is that the user can enter all the required information in one place. A disadvantage is that the user needs access to the Internet in order to use the service.

The following are the types of web callback:

This type of callback provides a convenient way for a user to get connected to the helpdesk or central office.

• The user provides his account ID (PIN) and the phone number.
• The second number is pre-defined in the application configuration.
• The system checks with billing that the account provided is valid and allowed to establish a call to the given number (the user’s phone number).
• When the user answers, the second call (to the pre-defined number) is established.
• After the second call is established, the two calls are bridged together.

This is the typical callback scenario, in which all of the information is provided by filling in the web form.

• The user provides his account ID (PIN), service password and two phone numbers (the first is the number the user wants to be called back to and the second is the number of the remote party the user wants to reach).
• The system checks with PortaBilling that the account provided is valid and allowed to initiate a call to the first number.
• When the user answers, he hears the current balance and maximum allowed call duration while the second number is being dialed.
• When the second call is answered, the two calls are bridged together.

This type of callback is a convenient way for a user to request a call to the user’s phone from the service provider’s helpdesk (at the expense of the service provider).

• The user provides the phone number where he wants to be called.
• The system authenticates the internal account for the call to the user’s phone number.
• After the call is established, the system establishes an outgoing call to the pre-defined number in the application configuration.
  Since the first outgoing call is established without any authentication, to prevent service abuse, make sure that unauthorized users may not access the web callback trigger for hosted mode.

Configuration

The configuration of a web callback trigger is performed via the admin web interface. A detailed description of the web callback trigger instance configuration is described in the Setting up WEB Callback Services handbook.

• The purpose of this module is to allow users to request callback calls via sending an email.  The workflow of the email callback is as follows: The user composes an email according to the pre-defined format and sends it to a specific email address (e.g., callback@yourdomain.com). The message format:

  P AAAA YYYY SN XXXXXXXX DN NNNNNNNN,

  where AAAA is callback account; YYYY is the service password; XXXXXXXX is the phone number to which the callback should be established; NNNNNNNN is the destination number.Example:

  P 6192345678 1ak45 SN 6581433653 DN 420212345678

• When the email arrives to PortaSIP, the mail filter parses the information contained in it and passes it to the callback trigger.
• The trigger authenticates the account provided in the email and relays the call processing to the callback engine.
• The callback engine then initiates the call legs.

One small advantage of this method over web callback is that while in some office environments users are not permitted to browse the web, they can still send and receive emails.

The configuration of the email callback trigger is performed via the admin web interface. A detailed description of the email callback trigger instance configuration is described in the Setting up Email Callback Services handbook.