Modified-Prepaid-Application

Here you can find the new version CallingCard Applications

This is the manual for the modified version of the PrePaid Application.

This Version is already outdated – if you need the actual version, then send me a mail to madmin at dialog-telekom dot at
I will upload the new version / docu soon

What can you do with it ?

• Your customers can call your Asterisk Server with the running prepaid application
• The prepaid application will then authenticate the user on his CID, credit, card activated (the other version used a PIN Code) and stores the tariff, expires and credit information
• The Caller gets informed about his credit
• The Caller is requested to enter a destination number
• The prepaid application then authorizes the caller (can we route this caller to this destination)
• The prepaid application calculates the remaining duration of the actual call (based on tariffrate tables), informs the caller about this and sets a timeout
• The prepaid application connects the Caller to the destination (you can configure a Carrier-Preselect-Code based on the destinations)
• After disconnecting the call Asterisk Server updates the credit of the Caller-CID and stores the concerning Call-Detail-Records with CallingPartyNumber, CalledPartyNumber, CallSetupTime, Duration, Charge and the remaining credit

What do you need to run it ?

• Asterisk (developed on cvs head – but it should not be a problem to use it with stable)
• Postgresql (developed on 7.4 – older version should also work)

Configuration

• Postgresql Database
• prepaid.conf File
• extensions.conf File

• Sequence 1

Authenticate the caller
Checks if the cid is in the table “cid” and if the correspondending calling card is already activated (table card – field activated). The whole thing gets done via the postgresql function asterisk_authenticate(cid)

• Sequence 2

Authorize the caller
Checks if the calling card has enough credit and is not expired. Checks also if a second calling card for this cid is avaible.

• Sequence 3

Does the user have already entered a destination
It is possible to store the calling card application number + pause + destination number into the mobile phonebook – in this case the system skips the credit message and jumbs directly to the destination routable decision.

• Sequence 4

Destination routable
Load from table providerdestination all possible routes (various provider). Then checks which provider is cheaper with the providerrate table. It also loads the data from the table provider (providertech/carriercode/providerip). Last it checks which tariff is being used and then it returns all the data to the calling card application.