Controlling the amount of calls passing through your softswitch is a very important task and in order to ensure that the actual amount of calls that have been routed is equal to the expected amount, you need to understand the mechanism of controlling the CPS rate.


The task of controlling calls is particularly important to cope with unpredictable spikes of new calls that may arrive at the softswitch. Call spikes should be handled properly to make sure that the least possible number of calls is rejected and that the CPS value is not exceeded.  

For example:


During the time frame of 1 minute 60 calls are received. The initials CPS (Calls per Second) might mislead you to think of CPS in terms of a perfect ratio of seconds to calls of 1:1.  In actuality, calls do not arrive in perfect ratios of 1:1.  Consider what happens if 50 calls are received in the first 5 seconds and 10 calls in the last 55. Should the softswitch reject 45 out of 50 calls that came in the first 5 seconds?


To handle the situation above, our developers created a mechanism called the Token Bucket which dynamically controls the call rate.  The Token Bucket is full of tokens and the number of tokens in the bucket depends on the CPS value of your softswitch.  The Token Bucket is constantly, linearly refilled with new tokens to ensure that it is full.  The Token Bucket capacity is equal to the CPS value of your softswitch multiplied by the cost of the call in tokens and by 60 seconds.  The Token Bucket cannot hold more tokens than its capacity. Each call has its own cost in tokens. In order to pass the calls, we need to extract the correct amount of tokens out of the bucket. If the amount necessary is not available, the call will be rejected.


Here is a simple example:

  • CPS is 1 and the bucket is full
  • One call costs 100 tokens
  • Bucket filling speed is CPS * Call cost (100 tokens per second)
  • Bucket size is CPS * Call cost * 60 seconds (6000 tokens)


Now, going back to the scenario of 50 calls in the first 5 seconds...

If we receive 50 calls in 5 seconds all of them will pass through; however, only 1500 tokens will remain in the bucket (decrease of 5000 tokens on calls and increase of 500 tokens on re-filling flow).


If we receive another portion of 55 calls in the next 5 seconds, only 20 of them will pass and the rest of them will be rejected; however, if the portion is smaller (10 calls during next 50 seconds) all of them will pass successfully.


The possible errors when the CPS limit is exceeded:

The negative values in the customer CDRs result field can be interpreted using the following table:

-18 | Call Per Second (CPS) Limit On Account Exceeded
-19 | Call Per Second (CPS) System Limit Exceeded
-26 | Call Per Second (CPS) Limit On Connection Exceeded
-31 | Call Per Second (CPS) Limit On Customer Exceeded (starting from 5.0)
-33 | Call Per Second (CPS) Limit On Auth Rule Exceeded (starting from 2020)
-39 | Call Per Second (CPS) Overall Limit Exceeded (starting from master)

For inbound calls there will be the following SIP error codes:

403, 'Account in Use %d' % self.i_account
403, 'Call rate too high for account %d' % self.i_account
403, 'Call rate too high'
503, 'Call rate too high per connection'