[ASTPPCOM-415] Max call length appears to be calculated wrong, depending on settings Created: 28/Apr/18  Updated: 01/Apr/21  Resolved: 01/Apr/21

Status: Done
Project: ASTPP Community
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: powerpbx Assignee: Samir Doshi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The system Call Max Length that is set in Configuration > Settings defaults to 144000 (24 minutes). It appears to interact with Origination rates to cause an incorrect calculation, depending on the origination rate.

If the call origination rate is 0.0200 6/6, max_call_length is correctly calculated as 24 minutes. This can be observed from fs_cli while making the call.

If I increase Call Max Length to 6000000, max_call_length is calculated as approx. 5000 minutes if I have a $50 credit in the prepay account.

It appears the problem code is located here;
https://github.com/iNextrix/ASTPP/blob/46f16a598b093842a1d8ca16a385dcb3d6f71bd2/freeswitch/scripts/astpp/lib/astpp.functions.lua#L326

if (tonumber(rates['cost']) > 0 ) then
		      maxlength = ( balance -  rates['connectcost'] ) / rates['cost']
		      
		      if ( config['call_max_length'] and (tonumber(maxlength) > tonumber(config['call_max_length']) / 1000)) then
				maxlength = config['call_max_length'] / 1000 / 60
			      Logger.info("[FIND_MAXLENGTH] LIMITING CALL TO CONFIG MAX LENGTH "..maxlength.."!!!")
		      end
		else
		      Logger.info("[FIND_MAXLENGTH] Call is free - assigning max length!!! :: " .. config['max_free_length'] )
		      maxlength = config['max_free_length']
		end      

It appears that when the calculation sets maxlength = config['call_max_length'] / 1000 / 60, it correct calculated system max call length. Otherwise it is set to maxlength = ( balance - rates['connectcost'] ) / rates['cost'], which is based on the account balance. I assume this is to adjust the max call length to the lesser of the two calculations. However, the calculation does not appear to be correct.



 Comments   
Comment by Samir Doshi [ 03/May/18 ]

Found the problem and it is fixed now in latest source.

Generated at Sat Feb 10 07:16:55 CET 2024 using Jira 8.13.3#813003-sha1:22ebedbb75c99b147c66f14e031dd8a2d214753a.