[asterisk-bugs] [JIRA] (ASTERISK-25460) UDP leak

Rusty Newton (JIRA) noreply at issues.asterisk.org
Tue Nov 10 18:08:33 CST 2015


     [ https://issues.asterisk.org/jira/browse/ASTERISK-25460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-25460:
------------------------------------

    Assignee: Private Name
      Status: Waiting for Feedback  (was: Triage)

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.

> UDP leak
> --------
>
>                 Key: ASTERISK-25460
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25460
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.20.0
>         Environment: Linux 2.6.32
>            Reporter: Private Name
>            Assignee: Private Name
>
> 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?



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list