Summary:ASTERISK-07262: chan_sip not closing channel when RTP goes idle in channel not exting in real life
Reporter:Jon Brüel (jb)Labels:
Date Opened:2006-06-30 08:36:23Date Closed:2006-07-31 16:33:54
Versions:Frequency of
Description:The symptom is that Asterisk repitively tries to disconnect calls which do not exist with the following type of CLI message:

Jun 30 14:22:59 NOTICE[2242]: chan_sip.c:11450 do_monitor: Disconnecting call 'SIP/100000001758-e4db' for lack of RTP activity in 15065 seconds

The channel may or may not be listed when issuing a show channels command or using the manager interface.

When Asterisk goes into this mode, the CPU-load may incease to above 50% and it becomes unstable: calls are lost, BLFs are not updated, Autoattendants or queue information is heard after the call has been connected. In situations, where the CPU-load does not increase, the side effects are not observed.

The situation is likely to happen when the Asterisk is stressed, e.g. when a recompile is done live, or when the Internet connection from our hosting centre to the customer suffers from packet loss.

In typical setup with 200 extensions connected, the situation happens once a month - too often for customers expecting at least 99,99% availability.

The only way to stop the error situation is to restart Asterisk.

The system runs Fedora Core 2.6.5-1.358.


Possibly related to 0003811: chan_sip not closing channel when RTP goes idle due to a faulty SIP device.

Comments:By: Serge Vecher (serge-v) 2006-06-30 10:04:36

please read BUG GUIDELINES to avoid getting any more negative karma -- all sip bugs must be accompanied by a SIP Debug showing the problem.

1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete log to file and _attach_ said file to the bug.

By: Jon Brüel (jb) 2006-07-04 02:36:02

I'm working on reproducing the error with the logging asked for. The test is done on live systems outside working hours, and it might take some weeks before I return with results.

By: Olle Johansson (oej) 2006-07-05 01:46:53

Also, please turn on sip history and dumphistory so we can see the history of the call when it is disconnected. That way we will be able to trace this call.

By: Kevin P. Fleming (kpfleming) 2006-07-31 16:33:53

This has been fixed in branch 1.2 (revision 38611) and trunk (revision 38612). Please test and reopen this bug if the problem recurs.