Callback

The main idea behind callback is that when user A wishes to have a phone conversation with user B, he does not make an outgoing call to user B (as he would do with normal telephony service); instead:

• He initiates a callback call (we will discuss the available methods for triggering a callback later).
• The system establishes a call to A, and instead of originating the call, A actually answers it (in most telephony networks a subscriber does not pay for incoming calls, so this call is free for A).
• The system establishes a call to B and then bridges the two calls together so that A and B can communicate.

The previous topic described the callback service from an end user perspective. Now let’s look at the internal architecture of this solution. There are three main components of callback:

• Callback trigger
• Callback engine
• Authorization and billing

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 Built-in 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.

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.

The callback engine is a component of the VoIP network that actually establishes calls to A and B and bridges them together. The functions that the callback engine must perform are as follows:

• It includes an interface for configuring a callback trigger which transfers the required call information to the callback engine.
• Performs call authorization in PortaBilling to ensure that the user is allowed to make the call and has sufficient funds to cover it.
• Correctly establishes and connects outgoing calls.
• Disconnect calls when caller has exceeded his credit limit.
• Reports call duration and other relevant call information to PortaBilling so the call will be correctly charged.

The callback engine in PortaSIP does just that. It works in close conjunction with the callback trigger. After the callback trigger gathers the initial information (ANI number, account and password) and performs the initial account authentication/authorization, the callback engine performs further call processing.

A detailed description of the callback call flow will better illustrate its functions:

• When a new request is received from the callback trigger (e.g., for phone numbers 12065554123 and 16047770456) including the username and password for the account trying to establish the call, a request to establish call leg A (to number 12065554123) is sent to PortaSIP server.
• PortaSIP authorizes call leg A in PortaBilling.
• Upon successful call leg A authorization, PortaSIP asks PortaBilling for the optimal routing for destination number 12065554123 and establishes the outgoing call to the first destination number.
• After call leg A is connected (i.e. the user picks up the phone), it sends a request to PortaSIP to establish call leg B (to number 16047770456) if no additional actions are required from the user’s side (i.e. to enter the PIN, the destination number, etc.).
• PortaSIP authorizes call leg B as well, but differently: PortaBilling is informed that there are two simultaneous calls, i.e. to 12065554123 and 16047770456. Thus PortaBilling calculates the maximum allowed call duration so that the sum of the charges for both calls according to the appropriate rates will not be greater than the current balance.
• If authorization is successful, PortaSIP obtains the routing for the second destination number and establishes the outgoing call.
• When the user of the second phone number (16047770456) answers, PortaSIP starts a timer. Notification that call leg B is connected is sent to the callback engine.
• Call legs A and B are bridged together and users of phone numbers 12065554123 and 16047770456 can now start their conversation.
• When one of the users hangs up, the callback engine sends a request to PortaSIP to disconnect the other call leg as well. The same happens if call leg B is disconnected because the time has run out (the time for call leg B is calculated based on the time for call leg A); the callback engine will request that call leg A be disconnected as well.
• PortaSIP sends accounting information to PortaBilling so that the account is charged for two call legs (to 12065554123 and 16047770456). Two xDRs appear in the database, and its balance is modified accordingly.

Compared to similar software solutions, the callback engine in PortaSIP has the following principal advantages:

• No specialized hardware since the callback engine is the part of PortaSIP.
• This is the “out of the box” solution. To enable callback, simply perform the application configuration on the web interface.

The billing system must support a type of call authorization which is specific to callback services. For normal service (e.g., using prepaid cards) the question for authorization is, “If account 12065554123 has $5 available, and tries to call 861234567, is he allowed to talk at all and, if yes, for how long?” In this case, the billing system finds the applicable rate for 861234567 (let us assume it is $0.10/min, rounded to 60-second increments) and then calculates the allowed maximum duration as 5/0.10=50 minutes. This task becomes more complicated as the rating formula is more complex, including multiple intervals and special surcharges (a.k.a. billing tricks).

With callback, it becomes more complicated still. Now the question is, “If account 12065554123 has $5 available, and tries to call 861234567 and 42029876543 at the same time, for how long should he be allowed to talk?”

Thus the maximum allowed call duration must be calculated in such a way that the sum of the charges for the first and second calls does not exceed $5. Since rates for China and the Czech Republic will most certainly be different, and the rates will include different intervals and surcharges, this task becomes quite complicated and is therefore not supported by most billing systems. However, PortaBilling supports special callback authorization, and is available to provide authorization for advanced callback services.

After the call has been completed, billing should take appropriate action to calculate the call charges, write an xDR to the database and modify the account’s balance as well as any other applicable tasks. PortaBilling supports all of the callback features described and allows you to implement flexible rating for callback services.

Yes, you can set up this service, however, there is a high chance that the customer’s ANI information will not be relayed correctly to PortaSwitch – so the system may be unable to determine the customer’s callback number. In this type of case you can offer your customers DNIS callback.

Yes, you can set up such a service bundle so that callback call (leg A) is initiated to your customers’ SIP phones. However, be aware that in this case, voicemail, follow-me and other call redirect options will not work if the call is not answered.