Kazoo Rating Engine

Build Your Own Rating Engine

Here are the steps to easily add your own rating engine to Kazoo (and bypass the HotOrNot WhApp).

How calls are rated in Kazoo

When a new call is received in the ecallmgr application, a rating request is published onto the AMQP bus. Any application bound for those rate request events will receive the JSON payload and can optionally respond with a rate response. The first valid response received will be the rate applied to the call.

Rate Request JSON

Kazoo generates a rate request payload published onto the callmgr exchange with a routing key of rate.req. The JSON payload will look something along the lines of:

Rate Request JSON:



Description of the Rate Request JSON payload:

```Field:Description Value : Required To-DID: The dialed number The dialed number off the INVITE Yes Call-ID: The unique identifier for this channel String: Yes Event-Category: The class of event Rate: Yes Event-Name: The name of the event Req: Yes Msg-ID: The ID of this rate request message String: Yes Server-ID: The name of the AMQP queue of the sender, empty if no response is needed String: Yes App-Name: The name of the application that published the request String: Yes App-Version: The version of the application that published the request String: Yes Node: The Erlang VM node name of the sender String: Yes Options: Arbitrary list of strings set by sender, usually used by receiving to filter list of applicable rates List of strings: No

## Direction

The direction of the call, relative to Kazoo; 
outbound: meaning from **Kazoo** to the endpoint and 
inbound: meaning from the endpoint to **Kazoo**
inbound/ outbound:No

Account-ID: The **Kazoo** account ID associated with this cal (if any)
String: No
From-DID : The Caller ID number (if available)
String: No

Route Response JSON

Any application which receives rate requests and wishes to respond will need to publish the response to the targeted exchange using the Server-ID from the rate request payload as the routing key. Assuming the request above, a potential response would be constructed thusly:

Rate Response JSON:



**Description of the Rate Response JSON payload:**

Value: Required
Rate: The cost of the rate
Float: Yes
Call-ID: Identifier of the channel
Event-Category: Class of message
Event-Name: Name of the message type
Resp: Yes
App-Name: Name of the responding application
String: Yes
App-Version: Version of the responding application
String: Yes
Msg-ID: The ID from the request payload that identifies the request message
String: Yes
Node: The responder's node (useful mostly for debugging)
String: Yes
Server-ID: Empty, since no response to this message will be sent
Rate-Increment: How many seconds before Rate is applied
Integer (defaults to 60): No
Rate-Minimum: Minimum number of seconds to bill the call for, regardless of call duration
Integer, defaults to 60: No
Discount-Percentage: Apply a discount to the cost of the call
Integer: No
Surcharge: Flat amount to bill the call (in addition to per-minute charges)
Float: No
Rate-Name: Arbitrary name for the rate
String: No
Base-Cost: (Rate * (Rate-Minimum div 60)) + Rate-Surcharge
Float: No
Update-Caller-ID: If `true`, will prepend the Callee ID name with the rate of the call
Boolean, defaults to `false`: No

Rate Field

The rate fields (Rate, Rate-Increment, etc) will be set on the channel and available in the Custom-Channel-Vars of the resulting CDR. A simple formula is used to calculate the cost of the call:      R = Rate RI = Rate-Increment RM = Rate-Minimum Sur = Surcharge Secs = Billing Seconds When RM 60 = Sur + ((RM / 60) * R) When RM = 60 = Sur + ((RM / 60) * R) + ceiling((Secs - RM) / RI) * ((RI / 60) * R)))    

Edit this page here