Difference between revisions of "Mor authorize: Too low balance for more simultaneus calls!!!"
| Line 1: | Line 1: | ||
[[Image:audio.png]] SYSTEM ERROR. CODE 212. Too low balance to make another call. | |||
This user already has active call and part of his balance is reserved for this call. | This user already has active call and part of his balance is reserved for this call. | ||
Remaining balance is not enough to start new call. | Remaining balance is not enough to start new call. | ||
| Line 37: | Line 37: | ||
=See also= | =See also= | ||
* [[Hangupcause Codes]] | * [[Hangupcause Codes]] | ||
* [[Prepaid Logic]] | |||
Revision as of 10:33, 19 October 2009
SYSTEM ERROR. CODE 212. Too low balance to make another call.
This user already has active call and part of his balance is reserved for this call. Remaining balance is not enough to start new call. Increase users' balance to allow him to make more calls at the same time. For more information please consult online manual at wiki.kolmisoft.com
The reason can be that your user is PREPAID and he has not enough balance to cover more simultaneous calls.
Old logic
MOR uses algorithm to reserve balance when call is made to be safe if user is prepaid.
That way when second, third, etc calls are made - MOR checks free - not reserved balance and decides should it allow to dial or not.
To lower security level and allow users with low balance to dial out several times, go to /etc/asterisk/mor.conf and change to:
min_frozen = 1
That way you are taking risk that you will take loss if user talks for more then frozen_time (default 90s). E.g. if user make a call, his balance is frozen for 90s with the rate to current destination. If user talks more - you can take loss.
New logic
From 2008 October 24 new simplified algorithm is implemented.
Previous one left possibility to take loss if prepaid user talks more then reserved time. This new algorithm eliminates possibility to receive loss.
Actual versions: app_mor.so 0.6.18 and 0.7_pre44
Full explanation is here: Prepaid Logic
