[Home]

Summary:ASTERISK-16018: It crashes in rtp_timeput disconnect function
Reporter:Private Name (falves11)Labels:
Date Opened:2010-04-27 08:38:31Date Closed:2011-06-07 14:01:06
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_sip_crash.txt
Description:I am uploading the trace
Comments:By: Paul Belanger (pabelanger) 2010-04-27 08:50:22

More information is required (see below).  How do you reproduce the problem?
---
Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We\'d be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!

By: Private Name (falves11) 2010-04-27 09:10:51

I have an application that process millions of calls per day, always the same process. I see that it crashed and since it is compiled with debug information, I do a gdb asterisk core.xxx and take bt, and bt full. The trace should explain the issue. I have absolutely nothing more to add except show you my dialplan, but that will not help much. The calls are 100% SIP2SIP. My box and my dialplan are both open for inspection.
I wonder why we cannot get any useful information from traces alone. I cannot run my system with debug level, for in 150 open calls the system will be overwhelmed. Moreover, it crashes randomly.
I need to stay in 1.6 since it offers Sip Timers, and if nobody uses it and everybody hides in 1.4, it will never be stable. Please help me understand what can I do that does not kill my business.

By: Paul Belanger (pabelanger) 2010-04-27 09:59:29

falves11: This does not help us reproduce or debug your issue. At a minimum we need a dialplan, .config files and traces.  While a backtrace is helpful, specific steps to reproduce the issue also help to triage and move the issue along.

If you cannot make changes to your production machine, I suggest reproducing and collecting the information on a test box.

I also recommend the following:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

By: Private Name (falves11) 2010-04-27 10:52:24

Please close the case. I will go back to 1.4. I am unable to reproduce the issue or provide any additional information, plus my dialplan is not relevant since we ignore where it happened. I think it blew up when a call hit the rtp-timeout event.