[asterisk-dev] Urgent development consultancy wanted
acunningham at integrics.com
Tue May 22 10:03:35 CDT 2012
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 188.8.131.52.
> 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 184.108.40.206 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.
+1 888 468 3111
+44 20 799 39 799
More information about the asterisk-dev