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

Mikael Fredin mikael at wiraya.com
Thu May 15 06:34:40 CDT 2014


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/2d15ac17/attachment.html>


More information about the asterisk-users mailing list