Difference between revisions of "Mor authorize: Too low balance for more simultaneus calls!!!"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Image:audio.png]] SYSTEM ERROR. CODE 212. Too low balance to make another call.
This user already has an active call and part of his balance is reserved for this call.
The remaining balance is not enough to start a new call.
Increase the user's balance to allow him to make more calls at the same time.
For more information, please consult the 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.
The reason can be that your user is PREPAID and he has not enough balance to cover more simultaneous calls.




= Old logic =
= Old logic =


MOR uses algorithm to reserve balance when call is made to be safe if user is prepaid.
To be safe if the user was prepaid, MOR used an algorithm to reserve the balance when a call was made.


That way when second, third, etc calls are made - MOR checks free - not reserved balance and decides should it allow to dial or not.
That way when the second, third, or more calls were made, MOR checked the free (not reserved) balance and decided whether it should allow dialing 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:
To lower the security level and allow users with a low balance to dial out several times, go to '''/etc/asterisk/mor.conf''' and change to:


  min_frozen = 1
  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.
That way you are taking the risk of incurring a loss if the user talks for more than frozen_time (default 90s). For example, if the user makes a call, his balance is frozen for 90s with the rate to current destination. If the user talks more, you can incur a loss.


----
----
<br><br>
<br><br>
= New logic =
= New logic =


From 2008 October 24 new simplified algorithm is implemented.
From 24 October 2008,  a new, simplified algorithm has been implemented.


Previous one left possibility to take loss if prepaid user talks more then reserved time. '''This new algorithm eliminates possibility to receive loss.'''
The old one left open the possibility of taking a loss if the prepaid user talked for more than the reserved time. '''This new algorithm eliminates possibility of incurring a loss.'''


Actual versions: app_mor.so 0.6.18 and 0.7_pre44
Actual versions: app_mor.so 0.6.18 and 0.7_pre44.


The complete explanation is here: [[Prepaid Logic]].


== Explanation ==
<br><br>
 
=See also=
It is applied to Prepaid users only.
* [[Hangupcause Codes]]
 
* [[Prepaid Logic]]
In /etc/asterisk/mor.conf value frozen_time describes the maximum time for the call of prepaid users.
 
When user makes call, his balance is frozen by the amount which is necessary to make maximum length of the call (frozen_time).
 
If user talks less time - his part of the balance is unfrozen and correct amount is deducted.
 
If user talks time which is equal to frozen_time, then his call end automatically after frozen_time minutes.
 
 
== Example ==
 
/etc/asterisk/mor.conf frozen_time = 3
 
Call minute to Lithuania MOB costs 0.2 EUR/min
 
Prepaid user in his balance has 8 EUR.
 
When user makes first call to Lithuania MOB:
* MOR freezes his balance worth of 6 EUR (30 min * 0.2 EUR/min)
* Now user has 8 EUR in his balance where 6 EUR are frozen (2 EUR left free).
* Call limit for this call is 30 minutes
 
When user makes second call to Lithuania MOB (first call is in progress):
* MOR freezes remaining 2 EUR of user not-frozen balance
* Now user has 8 EUR frozen balance and 0 left as unfrozen
* Call limit for this call is 10 min (2 EUR / 0.2 EUR/min)
 
When user makes third call to Lithuania MOB (first and second calls are in progress):
* Call is dropped because no free balance to cover the call
 
When user hangups first call, lets say after 12 minutes:
* His balance is unfrozen by 6 EUR
* His balance is deducted for 2.4 EUR (12min * 0.2 EUR/min), so now user will have total balance 5.6 EUR (8 - 2.4) where 2 EUR is still frozen by second call.
* Now user can make 4th call why 2nd is still in progress, and the length of the 4th call would be (5.6 - 2) / 0.2 = 18 minutes
 
When user hangups second call which length is say 9 minutes (and there were no 4th call) then we have such situation:
* Balance is unfrozen by 2 EUR
* Call price is 9 * 0.2 = 1.8 EUR, so users balance will be 5.6 - 1.8 = 3.8 EUR. And non of this amount is frozen.
 
If user talks 10min in second call - this call is ended by system automatically.
 
----
 
Such logic does not allow any loss to the system owner. It applies more strict rules but this payoffs in a long run.
 
 
<br>
== Special case ==
 
''(Active from app_mor.so 0.7.2)''
 
When only 1 simultaneous call is allowed for device and/or user (Call Limit = 1) then frozen_balance is not used.
 
E.g. '''Call will last till balance will run out'''.
 
'''NOTE''': 2 hours is hardcoded call limit for all calls. If balance allows longer calls then 2 hours - call will be limited to 2 hours.
 
If user has Call Limit not 1, but his one device (D1) has Call Limit == 1 and another device (D2) Call Limit not 1 , then device D1 will be able to make 1 simm. call with duration 2h, and ONLY if it is enough balance to cover for frozen_time - device D2 '''calls''' will be limited to frozen_time.

Latest revision as of 23:31, 23 May 2010

Audio.png SYSTEM ERROR. CODE 212. Too low balance to make another call. 

This user already has an active call and part of his balance is reserved for this call. 
The remaining balance is not enough to start a new call. 
Increase the user's balance to allow him to make more calls at the same time.
For more information, please consult the 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

To be safe if the user was prepaid, MOR used an algorithm to reserve the balance when a call was made.

That way when the second, third, or more calls were made, MOR checked the free (not reserved) balance and decided whether it should allow dialing or not.

To lower the security level and allow users with a low balance to dial out several times, go to /etc/asterisk/mor.conf and change to: 

min_frozen = 1

That way you are taking the risk of incurring a loss if the user talks for more than frozen_time (default 90s). For example, if the user makes a call, his balance is frozen for 90s with the rate to current destination. If the user talks more, you can incur a loss.



New logic

From 24 October 2008, a new, simplified algorithm has been implemented.

The old one left open the possibility of taking a loss if the prepaid user talked for more than the reserved time. This new algorithm eliminates possibility of incurring a loss.

Actual versions: app_mor.so 0.6.18 and 0.7_pre44.

The complete explanation is here: Prepaid Logic.



See also

Retrieved from "https://wiki.kolmisoft.com/index.php?title=Mor_authorize:_Too_low_balance_for_more_simultaneus_calls!!!&oldid=7423"