Callback Addon

From Kolmisoft Wiki
Jump to navigationJump to search

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

Common callback diagram.png




Implementation in MOR

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

Supported Callback methods in MOR divided by initialization method (what triggers Callback):



Who pays for not authenticated call?

First of all by the nature of Callback it is important to know, that before calling back to User System does not know who is the User (when not using ANI) – e.g. is it client, has he an account in the system and so on.

That means – when system makes callback to the user and user pickups – the call is ANSWERED, but still – system does not know who the user is. Let's say user tries to enter PIN several time but unsuccessfully. Then he hang-ups. Call is ANSWERED. Does user pays for this call? No. Who pays? You, as owner of the system. Sad but that's true about Callback.




Callback User, Callback Device and Callback Tariff

In order to keep track of Callback calls you need to configure MOR in proper way. For that 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. In 100% of the time this user is system owner. But creating new user in MOR let's you keep track of all Callback activity in your system. The other reason to have Callback User (and not use System Admin account) is ability to create and assign Callback Tariff to this user.

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

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




Types of Callback in MOR

Callback in MOR can be divided in three separate parts by the way user is authenticated/authorized:

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




Callback with Device's PIN authentication/authorization

Callback with pin auth schema.png


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)

Callback with ani auth schema.png


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)

Callback with cc schema.png


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: