[asterisk-bugs] [JIRA] (ASTERISK-23745) Call file problem, DelayedRetry/retrying spite MaxRetries: 0

[Mikael Fredin (JIRA)]

Mikael Fredin created ASTERISK-23745:
----------------------------------------

             Summary: Call file problem, DelayedRetry/retrying spite MaxRetries: 0
                 Key: ASTERISK-23745
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23745
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Core/PBX, PBX/pbx_spool
    Affects Versions: 1.8.27.0, 1.8.16.0
         Environment: Red Hat Enterprise Linux Server release 5.9 (Tikanga)
HP ProLiant DL360 G7, 24 GB RAM, 24 cores
            Reporter: Mikael Fredin


Following problem arises from time to time, a call will successfully terminate:

[May 14 14:31:41] VERBOSE[3274] pbx_realtime.c:     -- Executing [t at project_init:1] Hangup("SIP/peer-2-00002f7e", "")
[May 14 14:31:41] VERBOSE[3274] pbx.c:   == Spawn extension (project_init, t, 1) exited non-zero on 'SIP/peer-2-00002f7e'

<bye message,  Really destroying SIP dialog, etc>

This is the call file:

Channel: SIP/peer-2/00numberhere
CallerID: "" <+calleridhere>
Extension: 123
SetVar: someid=123
Context: setup
WaitTime: 30
MaxRetries: 0
RetryTime: 300
Account: 123
Priority: 1


Some time after the call has hung up, the call file is still there and this is appended to the file:
StartRetry: 20354 1 (1400070906) (My note: Wed May 14 14:35:06 CEST 2014)

DelayedRetry: 20354 0 (1400070906) same time...

DelayedRetry: 20354 0 (1400071206) five minutes...

DelayedRetry: 20354 0 (1400071506) and so on...

DelayedRetry: 20354 0 (1400071806) never deleting this file

DelayedRetry: 20354 0 (1400072106) are we?

DelayedRetry: 20354 0 (1400072406) nope....

DelayedRetry: 20354 0 (1400072706) waiting for someone....

DelayedRetry: 20354 0 (1400073006) to do manual work




Asterisk log:
[May 14 14:35:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:40:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:45:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:50:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:55:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:00:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:05:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:10:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're currently running '/var/spool/asterisk/outgoing/callfile'

It happens only once in a while, my guess it happens when many call files are generated at once (I do use unique names for them, based on an auto_increment in a database). This will happen to a lot of call files, also, so it's not just one call file (seen 40+ get stuck like this).

core show channels will report far too many "active calls", but very few channels compared to "active calls" (and "core show calls" will show the same, too high, number).

So somehow, sometimes, something stops registering that calls are hanging up and that a call file should be removed.

Been thinking of skipping the check:
if (o->retries <= o->maxretries) {

On row 446 in pbx/pbx.c just to get the calls flowing, because I never want a retry on a call file (it would just skip to delete the file and report "expired without completion" instead). In fact, I have specified "MaxRetries: 0", so IMO I shouldn't get to the "Delaying retry" part anyways.

But not sure if that would be a good idea - I don't know the inner workings of asterisk and maybe things would start burning anyways. Especially considering something goes wrong with the active call count.





--
This message was sent by Atlassian JIRA
(v6.2#6252)