Skip to content


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)))