[asterisk-dev] Urgent development consultancy wanted

[Alistair Cunningham]

On 22/05/12 16:43, Mark Michelson wrote:
> I have a second suggested revision that may be the problem-solver you
> are looking for, though. I fixed an issue where hangup frames were being
> "missed" sometimes, leading to stuck channels in revision 357761. This
> change is present in Asterisk 1.8.12.0.
>
> I don't necessarily know that this revision will fix your problems, but
> it's better than offering nothing, though :)
>
> If you have debug logging on, and you are not using native bridging (I
> assume this because a local channel is involved), you should typically
> see a level 1 debug message from ast_generic_bridge() that says "Didn't
> get a frame from channel: blah" when a channel hangs up. If you *don't*
> see this message on the calls that correspond to the stuck channels,
> then there's a good chance the revision I pointed to would fix the problem.

Thank you. We are using /n in the Dial() to the local channel. I wonder 
if removing it might help?

We've just upgraded one of the machines in the cluster to 1.8.12.0 and 
the problem still exists. Interestingly, the user who was testing 
reported that the destination handset kept ringing after the Dial() 
timeout, so presumably no CANCEL was sent (sip debug wasn't on at the 
time unfortunately), and I do see this:

chan_sip.c: Hanging up zombie call. Be scared.

I see the following for the parent channel (which is the one that's stuck):

res_agi.c: SIP/didprovider-00000035 hungup
res_agi.c: <SIP/didprovider-00000035>AGI Tx >> HANGUP

So clearly the hangup is getting through to that channel. Those are the 
last lines for that thread ID in /var/log/asterisk/full.

Alistair Cunningham
+1 888 468 3111
+44 20 799 39 799
http://integrics.com/