[asterisk-users] Call file problem, DelayedRetry/retrying spite MaxRetries: 0

[Mikael Fredin]

Forgot to mention some important things.

Asterisk versions I have tried this one and got the error: 1.8.16 and
1.8.27.

 "core show channels" will show 0-10 channels when this happens (the true
count), but the "core show calls" and the call counter for active calls
after "core show channels" will show a very high amount of calls
(150-250+), this during times when we'd not expect to have close to that
amount.

Googling a bit gives people with the same problem but no solutions, one
with asterisk 1.4 who also reports weird call/channel counts.






On 15 May 2014 13:34, Mikael Fredin <mikael at wiraya.com> wrote:

> I am using Realtime extensions as well, in case that would matter.
>
> 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'
>
>
>
>
> Asterisk code:
>
>        if (o->retries <= o->maxretries) {
>                 now += o->retrytime;
>                 if (o->callingpid && (o->callingpid == ast_mainpid)) {
>                         safe_append(o, time(NULL), "DelayedRetry");
>                         ast_log(LOG_DEBUG, "Delaying retry since we're
> currently running '%s'\n", o->fn);
>                         free_outgoing(o);
>                 } else {
>                         /* Increment retries */
>                         o->retries++;
>                         /* If someone else was calling, they're presumably
> gone now
>                            so abort their retry and continue as we were...
> */
>                         if (o->callingpid)
>                                 safe_append(o, time(NULL), "AbortRetry");
>
>                         safe_append(o, now, "StartRetry");
>                         launch_service(o);
>                 }
>                 return now;
>         }
>
>
>
>
> Sure, I could just disable the retry check and add :
> if (FALSE) {
> And it will always expire should this occur...
>
> But I'm not sure if this is a good idea or not, and it would be nice not
> having to do that on every upgrade.
>
>
> Anyone have experience with what's going on?
>
> The file can be written to, since safe_append seems to be able to write to
> the file.
>
> This only happens once in a while, which makes it hard to track down.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140515/4abd01ac/attachment.html>