|Summary:||ASTERISK-18720: chan_sip stops frquently working (deadlock)|
|Reporter:||Frank-Michael Wittig (cpuvampier)||Labels:|
|Date Opened:||2011-10-13 12:17:48||Date Closed:||2011-10-31 13:39:52|
|Environment:||Ubuntu 10.04 64Bit Dell PowerEdge R410 4GB Dualcore I7 Sangoma Voicetime USB Sip<->Sip only||Attachments:||( 0) output.txt|
|Description:||SIP Channel stops responding after dialing local channels.|
Signalling between the partys are successfull done. (Both local partys keep ringing).
After updateing? the ringing hint status the complete chan_sip stops working.
Stoping A* (core stop now) wouldn't help in this case, Kill -9 is the only option
|Comments:||By: Richard Mudgett (rmudgett) 2011-10-13 18:28:22.039-0500|
From the core show locks this appears to be the timerfd issue that is fixed in v1.8.7. (ASTERISK-18142, ASTERISK-18197, ASTERISK-18166)
Are you using res_timing_timerfd?
By: Frank-Michael Wittig (cpuvampier) 2011-10-14 04:18:42.123-0500
thank you for your response.
We are using Kernel 2.6.38-11-generic.
Yes, res_timing_timerfd is build in.
Also the res_timing_dahdi with ztdummy,
and ztdummy is replaced by Sangoma Voicetime drivers, to provide an external
Timeingsource from this Sangoma USB Dongle.
Because we are running no internal cards in this maschine,
and so on we have a good experince with this Device in conference's with many party's.
Meanwhile i've tested it on 1.8.7 and it will not block the chan_sip by now.
One behavior is still visible, sometimes the B-Party's are ringing endless, like before but the chan_sip isn't blocked.
They never got an sip bye.
By: Richard Mudgett (rmudgett) 2011-10-17 10:55:28.979-0500
We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Leif Madsen (lmadsen) 2011-10-31 13:39:52.367-0500
This really looks like you're filing two issues in a single report, which makes triaging the issues very difficult. As the primary issue you've reported is already fixed in Asterisk 188.8.131.52, I'm closing this report. If you wish to open another issue for your other problem, please do so and provide the requested information along with it. Thanks!