Summary:	ASTERISK-19469: Execution of audio playbacks from call time limits (Dial application 'L' option) do not reflect configured options
Reporter:	Seth Miller (smiller)	Labels:
Date Opened:	2012-03-02 20:37:51.000-0600	Date Closed:	2018-01-02 08:30:33.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:	10.1.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Ubuntu Server 11.10	Attachments:	( 0) issue_19469_full_log.zip
Description:	I am experiencing buggy operation regarding call time limits (Dial application 'L' option) with different symptoms on two different servers, both running 10.1.2. On one machine the command: exten => 461,1,Dial(SIP/461,45,L(220000:180000:60000)) results in the initial notice being played properly and the call terminating at the proper time, but 'repeat' warnings are played intermittently, sometimes one or two warnings will be played at the requested 60-second intervals and at other times no warnings will be played. On a second machine (again, also running 10.1.2) the same command will result in an initial warning of 'you have 2 minutes and 59 seconds' (instead of the correct '3 minutes', as occurs on the server above), and then the call will terminate approx. 20-30 seconds later (with nothing unusual in the log.) In both cases the CLI debug log shows: -- Executing [461@LocalSets:1] Dial("SIP/360-0000000e", "SIP/461,45,L(220000:180000:60000)") in new stack > Limit Data for this call: > timelimit = 220000 ms (220.000 s) > play_warning = 180000 ms (180.000 s) > play_to_caller = yes > play_to_callee = no > warning_freq = 60000 ms (60.000 s) > start_sound = > warning_sound = timeleft > end_sound = so it would appear that all is normal. I'm seeing no related errors in the CLI or error logs. The problem is 100% repeatable on both machines. It seems very odd to see different bugs using an identical command on two separate machines running the exact same OS and Asterisk software versions, and very similar if not identical .conf files.
Comments:	By: Matt Jordan (mjordan) 2012-03-13 09:26:04.782-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information In addition, your dialplan would also be useful in debugging this issue.  If using SIP, the sip.conf from each machine, as well as a SIP debug trace would be needed. By: Seth Miller (smiller) 2012-03-15 16:36:11.171-0500 Sorry for not including logs. I have attached a verbose/SIP log detailing the failure: when 180000 ms (3 minutes) is specified as a call length warning parameter using the Dial 'L' argument the message 'two minutes and 58 seconds' (instead of '3 minutes') is announced. Also on occasion the call terminates early but this is not easily reproducible (the incorrect time stamp is 100% reproducible however.) Additionally, the maximum call length value seems to also have some effect on the problem, i.e when a 200000 ms call length is specified the correct 'you have three minutes' message is played, however at some point above this value the fault begins to occur (the test example uses a 250000 ms maximum call length.) I have also included all .conf files in use (in which I have a bare minimal configuration.) Also note that the original report was for version 10.1.2 but the fault also exists with (at least) 1.8.8.2 and 1.8.10 (attached example is for 1.8.10). I am seeing this problem now on two servers but strangely enough the problem does not seem to manifest itself on a third machine, even when using identical parameters. Please let me know what other information or logs you may require. Thanks, Seth By: Matt Jordan (mjordan) 2012-03-22 15:42:02.609-0500 What timing sources are being used on each server? By: Seth Miller (smiller) 2012-03-22 16:17:11.718-0500 Using dahdi software timing on each machine. Appears to be working normally (?) as far as I can tell: asteriskpbx@clf-vsp:~$ dahdi_test -v Opened pseudo dahdi interface, measuring accuracy... 8192 samples in 8191.952 system clock sample intervals (99.999%) 8192 samples in 8191.304 system clock sample intervals (99.992%) 8192 samples in 8191.704 system clock sample intervals (99.996%) 8192 samples in 8191.704 system clock sample intervals (99.996%) 8192 samples in 8192.279 system clock sample intervals (99.997%) 8192 samples in 8191.145 system clock sample intervals (99.990%) --- Results after 6 passes --- Best: 99.999% -- Worst: 99.990% -- Average: 99.994970% By: Seth Miller (smiller) 2012-11-16 18:49:46.508-0600 Can you verify whether this issue has been duplicated/confirmed, and if it is being actively addressed? Thanks - By: Joshua C. Colp (jcolp) 2012-11-16 19:40:21.254-0600 When there are updates they will be posted to this issue. If you require immediate assistance you can try to get a community developer interested in your issue or post a bounty on the asterisk-biz mailing list. By: Joshua C. Colp (jcolp) 2017-12-19 06:10:37.580-0600 Bridging has undergone a major rewrite and with it the functionality mentioned here. Are you still experiencing this as of Asterisk 13? By: Asterisk Team (asteriskteam) 2018-01-02 08:30:33.887-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines