VoIP Mailing List Archives

[mikael at wiraya.com]

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@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.

[mikael at wiraya.com]

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@wiraya.com (mikael@wiraya.com)> wrote: