[asterisk-bugs] [Asterisk 0012801]: Digit timeout giving negative values

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12801 
====================================================================== 
Reported By:                xieliwei
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   12801
Category:                   Functions/func_timeout
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 120859 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-05-2008 21:29 CDT
Last Modified:              06-06-2008 18:03 CDT
====================================================================== 
Summary:                    Digit timeout giving negative values
Description: 
I'm not very sure if this is a freepbx or asterisk issue since both are
trunk versions and this is a fresh install. I'll be posting this bug report
for both freepbx and asterisk.

All instances of digit timeout seem to have negative time even though a
positive value was set:

IVR
    -- Executing [s at ivr-4:5] GotoIf("SIP/xx.xx.xx.xx-083c0e40", "1?begin")
in new stack
    -- Goto (ivr-4,s,8)
    -- Executing [s at ivr-4:8] Set("SIP/xx.xx.xx.xx-083c0e40",
"TIMEOUT(digit)=3") in new stack
    -- Digit timeout set to -2144.483
    -- Executing [s at ivr-4:9] Set("SIP/xx.xx.xx.xx-083c0e40",
"TIMEOUT(response)=10") in new stack
    -- Response timeout set to 10.000


Similarly for DISA
    -- Executing [1 at ivr-3:3] Goto("SIP/xx.xx.xx.xx-083c0e40", "disa,1,1")
in new stack
    -- Goto (disa,1,1)
    -- Executing [1 at disa:1] Set("SIP/xx.xx.xx.xx-083c0e40",
"TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to -2142.483
    -- Executing [1 at disa:2] Set("SIP/xx.xx.xx.xx-083c0e40",
"TIMEOUT(response)=10") in new stack
    -- Response timeout set to 10.000

Notice that response timeout still works as normal and that the timeout
seems to be overflowing as the negative values seem to change
proportionally to the value of timeout specified.

FreePBX version is trunk-5769
====================================================================== 

---------------------------------------------------------------------- 
 xieliwei - 06-06-08 18:03  
---------------------------------------------------------------------- 
This bug can be closed.

I confirm that a vanilla install does not exhibit this problem. Only when
FreePBX configuration is applied will this happen.

This scales down the cause to either a FreePBX bug or bad configuration on
my side. Either way, it is unlikely that Asterisk is the cause.

For the record, steps taken were:
1. Move all asterisk related items, mainly /etc/asterisk,
/usr/lib/asterisk, /var/lib/asterisk and /usr/sbin/asterisk to a storage
directory.
(Clearing of FreePBX items was not done as a vanilla install would not be
affected by its presence unless FreePBX was explicitly applied to it)
2. make distclean and compile asterisk from scratch with same
configuration and menuconfig selections.
3. Install was then confirmed not to be exhibiting this problem.
4. Install FreePBX
5. Problem occurs with my current FreePBX configuration applied.

I should explain that because I did not have time to do a clean VM install
and because I only wanted to confirm if the problem lies with FreePBX or
Asterisk, what I have done may be questionable. Apologies for that. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-06-08 18:03  xieliwei       Note Added: 0087918                          
======================================================================