When providing a service to a wholesale customer an owner of the Sippy Softswitch needs to allow as many simultaneous sessions as possible while at the same time prohibiting the customer to overuse his balance.


To achieve this goal the Sippy Softswitch starting from version 5.3 extends the allowed maximum duration of an active call in real time. The algorithm is changed only for Accounts's balance and works like this:

  • A call comes in. The Sippy tries to allocate money for the first period of time.
  • If the balance is sufficient then the call is allowed to connect and continue at least for this first period.
  • The call connects and some time before the allocated time is over the Sippy tries to allocate additional period of time to extend the duration of the call.
  • If this allocation is successful then the maximum allowed call duration is extended accordingly.
  • This re-allocation is repeated until either balance is over or Max Session Time of an Account is reached.
  • When the next re-allocation is unsuccessful the Sippy does not extend the max call duration anymore and the call is disconnected by Session Timeout when it reaches the max call duration which was set previously.


There are two possible algorithms of the session time allocation.

  • Average Call Duration (ACD) only - every new allocation tries to acquire exactly one more ACD. This algorithm fails if the ACD is 5 seconds or less.
  • Incremental - the Sippy tries to acquire 10 seconds first and twice as much as previously attempted duration until it reaches either 200 seconds or ACD, whichever is bigger. Further allocation till Session Timeout is performed according to the tables below


New allocation attempt is performed 5 seconds before Session Timeout for the call.


Example

Lets assume that:

  • Interval 1 = 10 seconds
  • Interval N = 15 seconds
  • Price 1 = $6 / minute
  • Price N = $4 / minute


ACD algorithm, ACD = 140 seconds

Timeline
Try To Allocate
Actually Allocated Period
Session Timeout
Blocked Balance
Connect + 0 seconds140 seconds145 seconds145 seconds$1+$9=$10
Connect + 140 seconds140 seconds150 seconds295 seconds$10+$10=$20
Connect + 290 seconds140 seconds150 seconds445 seconds$20+$10=$30


Incremental algorithm for the case when ACD <200 (ACD = 140)

Timeline
Try To Allocate
Actually Allocated Period
Session Timeout
Blocked Balance
Connect + 0 seconds
10 seconds
10 seconds
10 seconds
$1
Connect + 5 seconds
20 seconds
30 seconds
40 seconds
$1+$2=$3
Connect + 35 seconds
40 seconds
45 seconds
85 seconds
$3+$3=$6
Connect + 80 seconds
80 seconds
90 seconds
175 seconds
$6+$6=$12
Connect + 170 seconds160 seconds165 seconds340 seconds
$12+$11=$23
Connect + 335 seconds200 seconds210 seconds550 seconds$23+$14=$37
Connect + 545 seconds200 seconds210 seconds
760 seconds$37+$14=$51
Connect + 755 seconds200 seconds210 seconds970 seconds$51+$14=$65


Incremental algorithm for the case when ACD >200 (ACD = 230)

Timeline
Try To Allocate
Actually Allocated Period
Session Timeout
Blocked Balance
Connect + 0 seconds
10 seconds
10 seconds
10 seconds
$1
Connect + 5 seconds
20 seconds
30 seconds
40 seconds
$1+$2=$3
Connect + 35 seconds
40 seconds
45 seconds
85 seconds
$3+$3=$6
Connect + 80 seconds
80 seconds
90 seconds
175 seconds
$6+$6=$12
Connect + 170 seconds160 seconds165 seconds340 seconds
$12+$11=$23
Connect + 335 seconds230 seconds240 seconds580 seconds$23+$16=$39
Connect + 575 seconds230 seconds240 seconds
820 seconds$39+$16=$55
Connect + 815 seconds230 seconds240 seconds1060 seconds$55+$16=$71


This algorithm is available only in the new version of the strackerd, which can be enabled by setting 'system/strackerd/binary' option to a value 'pkg' in the system_config table. This option is unavailable via XML-RPC API and can be tuned manually only.


The time allocation algorithm can be chosen with the option 'system/strackerd/next_duration_algorithm' in the system_config table. The available values are 'ACD' (default) and  'incremental'. This option is unavailable via XML-RPC API and can be tuned manually only.