Summary:	ASTERISK-25460: UDP leak
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2015-10-09 23:10:06	Date Closed:	2015-11-10 19:14:31.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	11.20.0	Frequency of Occurrence
Related Issues:	is related to ASTERISK-24837 chan_sip calls to Asterisk result in file descriptors growing exponentially while channels remain up
Environment:	Linux 2.6.32	Attachments:
Description:	My app plays files and collects DTMF, plus dials out a fraction of the inbound calls. I have 1200 channels all the time, 12 hours a day. After an hour or so, the UDP handles reach 55.000 and I reset the process. My rtp.conf has a range from 5.000 to 60.000. Any idea how to see why the handles keep piling up?
Comments:	By: Asterisk Team (asteriskteam) 2015-10-09 23:10:08.567-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Private Name (falves11) 2015-10-10 20:42:21.380-0500 This issue looks similar to ASTERISK-16023 but I am sure it is only a coincidence By: Private Name (falves11) 2015-10-10 20:50:27.371-0500 I found a very simple way to reproduce this bug. In sip.conf, set contex=reject, where "reject" is a context that does not exist. The UDP port count goes 60.000 in less than 3 minutes, at least in my box. Asterisk responds with 404 Not Found. Basically, Asterisk is not closing any of the allocated ports,ever. I can give access to my box to anybody who wants to see it. Please contact me to v e n e f a x g m  a i l By: Rusty Newton (rnewton) 2015-11-10 18:07:09.669-0600 I've had some time to attempt reproduction of your issue. I'm unable to reproduce it by following your instructions (though the instructions are not very clear). {quote} I can set up a test bed, it has to be two machines back to back, and use a script to start the channels. I already did provide the script, however, I am uploading it again. If you agree, then contact me for the credentials and you can see it. As I said before, there is no dialplan. Just a simple script that generates calls and when they connect, calls Echo(). Once the channels are up, check the issue with lsof. I cannot imagine a simpler description than this, but maybe I am wrong. In case yo want to try again, please set up two machines, one sends and one receives calls and plays music on hold, two lines of code. {quote} I setup two machines, Asterisk A : Asterisk 13.6.0 Asterisk B : Asterisk 11.20.0 On A I used your script to generate calls with the PJSIP channel driver. B receives the calls and uses the sip.conf you provided with only a change to the host address for the demo peer. I tested in two cases. Case one: Calls received by B are answered and put into music on hold using dialplan as you described. {noformat} [reject] exten = s,1,Answer() exten = s,2,Musiconhold() {noformat} Case two: B has empty extensions.conf , Calls received by B are rejected by asterisk as the context 'reject' does not exist. In both cases, with hundreds of calls up and established, and thousands of calls processed, the file handles and UDP ports allocated both appear sane and *do not* increase exponentially. As the calls hangup the UDP ports and file handles decrease as expected. I viewed them using the same commands you use to be sure we are measuring the same way. Since no one else is reporting these issues and we cannot reproduce the issues following your instructions the burden is on you to produce a step by step guide demonstrating how to reproduce the issue from scratch. There is likely a missing element in your environment or configuration that is required for the problem to occur. It'll be up to you to figure this out and demonstrate what that element is. I'll leave these issues in Waiting on Feedback for a couple more weeks to give you a chance to hunt down this missing element and communicate to us what it is. I'll also repeat that we do not provide tech support via this issue tracker. We will not be logging onto your machine to look at the issue. We don't have the time or resources to do that. If you need help locating the issue I encourage you to hire a developer or consultant to assist you in tracking down the crucial details needed to reproduce the problem and demonstrate the bug in a way where we can go fix it. Please discuss the file handle leak issue *only* on this issue ASTERISK-24837. Please discuss the UDP port leak issue *only* on ASTERISK-25460. By: Private Name (falves11) 2015-11-10 18:45:59.350-0600 Please close the case.