Callback Addon

Definition

From Wikipedia, the free encyclopedia
In telecommunications, a callback (also written as call-back) occurs when the originator of a call is immediately called back in a second call as a response.

In order to use a callback service, a subscriber is allocated a unique number, which must first be dialled in order to trigger a return call. This is known as a Direct Inbound Dialing (DID) number (Access Number). Where Caller ID is available, it may be possible to use the same DID number for many different subscribers, as the callback system will be able to recognize each subscriber's registered number.

On hearing a ringing tone for a few seconds, the subscriber simply hangs up and awaits the callback. On receiving this, usually within a few seconds, the customer picks up the phone and dials the required number.

The cost of making a telephone call via callback consists of two parts, as the caller is effectively paying for an outbound and an inbound call at the same time. If it costs 20 US cents a minute to call Nigeria from the US, and 8 cents a minute to call Spain from the US, then the caller will pay a total of 28 US cents a minute.

NOTE: If you want to use Callback, make sure your DID provider sends correct CallerID information. Without CallerID, you will not be able to use Callback.

Common Callback diagram

Implementation in MOR

Callback in MOR is implemented in very simple way. It's enough to tell the system the Access Number (DID) and the way Callback should act. All of this will be described in following paragraphs.

Supported Callback methods in MOR, listed by initialization method (which triggers Callback), are:

• Call
• Over GUI
• Over Email
• Over API

Who pays for not authenticated call?

First of all, by the nature of Callback it is important to know that before calling back to the user, the system does not know who the user is (when not using ANI). For example, it does not know whether the user is a client, whether he has an account in the system, and so on.

This means that when the system makes the callback to the user and the user picks up, the call is ANSWERED, but the system still does not know who the user is. Let's say the user unsuccessfully tries to enter a PIN several times. Then he hangs up. The call is ANSWERED. Does the user pay for this call? No. Who pays? You, as the owner of the system. It's sad, but true.

Callback User, Callback Device and Callback Tariff

In order to keep track of Callback calls, you need to configure MOR in the proper way. For this we need:

1. Callback User
2. Callback Device
3. Callback Tariff

Callback User is the user who will pay for answered but not authenticated calls to the user. 100% of the time, this user is the system owner. But creating a new user in MOR lets you keep track of all Callback activity in your system. The other reason to have Callback User (and not use the System Admin account) is the ability to create and assign a Callback Tariff to this user.

Callback Device is the necessary entity in MOR which will actually 'make' callback calls to user. The type and other details do not matter. This device is pure virtual.

Callback Tariff – a separate tariff which should be assigned to the Callback User. In this tariff you enter rates only to those destinations from which you expect the user will make an Initiation Call. This is important! Make sure you do not have some Inmarsat rates defined here. Guess how much you will pay if the user initiates a callback from Inmarsat and, when he gets the call, enters the PIN several times incorrectly and hangs up? In short, this tariff decides from which destinations you allow users to initiate callback.

Types of Callback in MOR

Callback in MOR can be classified three ways depending on how the user is authenticated/authorized:

1. By User Device's PIN.
2. Using ANI (Automatic Number Identification).
3. By the Calling Card's Number/PIN (or just the PIN).

Callback with Device's PIN authentication/authorization

The main part here is that user gets authenticated/authorized when he enters Device PIN. System checks for such PIN in database and if user is found – user can proceed.

Callback Using ANI (Automatic Number Identification)

This way of Callback is extended User auth. by PIN Callback. In order to ask user for Device's PIN system checks user's CallerID (ANI). If such CallerID is found in database – user gets authenticated/authorized and can proceed entering destination. If CallerID is not found – user is asked to enter his Device's PIN number.

Attention! It is very easy to fake CallerID so be careful when you are enabling Callback with ANI. Anybody can put anybodies CallerID and use your service for free.

Callback By Calling Card's Number/PIN (or only PIN)

This type of Callback lets user enter Calling Card's Number/PIN to get authenticated/authorized. System checks for such Calling Card in database. If call is made – it is assigned to particular Calling Card.

Rule about Users and Cards:

Users and cards are not related at all. That means:

1. User (as entity in MOR) can't have Cards.
2. Card (as entity in MOR) can't belong to some User.

Setting Callback in MOR

In order to setup Callback in the MOR you need:

1. Callback User
2. Callback Device
3. Callback Tariff
4. Access Number (DID)
5. Calling Card or Auth. by PIN Dial Plan

The work flow is as follows:

1. Create Callback User
2. Create Callback Device to the Callback User
3. Create Callback Tariff and fill it with rates to destinations from which you want to allow users to initiate callback
4. Assign Callback Tariff to Callback User
5. Make sure you have Calling Card or Auth. by PIN Dial Plan
6. Create Callback Dial Plan and assign Calling Card or Auth. by PIN Dial-Plan to Callback Dial Plan
7. Assign Callback Dial Plan to some DID

---

See also:

• WEB Callback
• Callback over Email
• API Callback
• Callback setup example
• 217 Callback not initiated because device not found by ANI
• Can't setup callback
• Callback and Calling Cards