Summary:	ASTERISK-25302: Error:Oh dear... we couldn't allocate a port for RTP instance
Reporter:	Vladimir Yordanov (vlado)	Labels:
Date Opened:	2015-08-04 08:16:07	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:
Versions:	13.4.0	Frequency of Occurrence	Frequent
Related Issues:
Environment:	CentOS 7, 150 lines	Attachments:	( 0) AsteriskCrashLogs2.txt ( 1) AsteriskNotSendingAudio.PNG ( 2) Dynamic_Messaging_call_flow_00000007.PNG ( 3) rtp.conf ( 4) sip.conf ( 5) udpdump.pcap
Description:	After a period of constant work (calls) this problem appears: "Oh dear... we couldn't allocate a port for RTP instance ..." and Asterisk  stops processing calls. The whole port range 10000-20000 appears blocked. Only restart of Asterisk frees the ports. Any ideas how this coud be resolved?
Comments:	By: Asterisk Team (asteriskteam) 2015-08-04 08:16:10.126-0500 The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process. By: Asterisk Team (asteriskteam) 2015-08-04 08:16:11.067-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: Rusty Newton (rnewton) 2015-08-04 15:50:58.822-0500 This is not a forum for support. If you don't have a bug that you can demonstrate with debug and a reproduction scenario then it isn't ready for the issue tracker yet. Please read through the issue tracker guidelines linked in the comment above before using the issue tracker in the future. There are mailing lists and forums available for community support. The community can help you determine whether you have a bug or not and narrow down what may be triggering it. http://www.asterisk.org/community/discuss http://forums.asterisk.org By: Vladimir Yordanov (vlado) 2015-08-05 09:12:19.557-0500 Thank you for your reply. We have started gathering debug logs and will post them shortly. About the reproduction scenario: - We try to perform 40000 calls for 3 hours. We are using 150 lines. Calls are equaly distributed. After some period of active usage and making calls our PBX stops sending ACK after our provider has sent 183 ringing and 200 OK with SDP. This causes provider SBC to resend the message again and again until the SBC gives up and the call fails. After that moment: - Asterisk stops releasing ports and occupies more and more until all (10000-20000) become occupied - our schedulers stop receiving hang up signal - lines remain blocked - if you make a test call the call is done but the messages are not played We have posted in the forums but there are no replies or similar problems that can help us. By: Asterisk Team (asteriskteam) 2015-08-05 09:12:20.173-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Rusty Newton (rnewton) 2015-08-05 11:35:27.445-0500 Okay, we'll probably need PCAPs of the problematic calls along with the debug, or a small scale scenario with configuration files to reproduce the issue. By: Vladimir Yordanov (vlado) 2015-08-06 01:46:31.024-0500 Please find attached scrrenshot from our provider and also pcap and log extraction which might help. By: Vladimir Yordanov (vlado) 2015-08-06 02:03:15.788-0500 I have attached the configuration files and would like to mention also that the rtp ports that have been set for use start being used by asterisk and are never released. Also 'sip show channels' command does not show anything and breaks the console window. By: Vladimir Yordanov (vlado) 2015-08-11 04:17:45.077-0500 Hello, Sorry to bother you but can I kindly ask you if there is any progress with the issue? By: Joshua C. Colp (jcolp) 2015-08-11 04:59:38.447-0500 Any updates will be posted to this issue. Asking for an update doesn't accomplish anything. By: Vladimir Yordanov (vlado) 2015-09-24 05:52:57.021-0500 Hello, We would like to add some additional information to our case. We are using Asterisk to make call campaigns for our clients and we are trying to run thousands of calls using 150 lines. The problem is that Asterisk goes into a kind of crashed mode very often and while in this mode calls are still initiated but no messages are played. We also tried several version of Asterisk and all were unstable. Curently we are using 13.4 as it has best call quality and AMD but is also very unstable and upredictble in terms of when and why it crashes. By: Vladimir Yordanov (vlado) 2015-09-25 01:45:55.006-0500 Asterisk in "crashed" mode - calls are triggered but no messages are played By: Vladimir Yordanov (vlado) 2015-10-01 08:14:08.817-0500 Can we ask with which version of Linux Asterisk is tested and is recomended as best (stable)? By: Vladimir Yordanov (vlado) 2015-10-02 02:32:40.841-0500 Hi, Just to confirm that we tested with latest version Asterisk 13.6.0-rc1 on CentOs 7 and the problem still exists. Asterisk cannot handle even 10000 calls for one hour using 150lines. It crashes and only initiates calls but do not play messages. Thanks. By: Rusty Newton (rnewton) 2015-11-12 09:16:11.125-0600 Thank you for the crash report. However, we need more information to investigate the crash. Please provide: 1. A backtrace generated from a core dump using the instructions provided on the Asterisk wiki [1]. 2. Specific steps taken that lead to the crash. 3. All configuration information necesary to reproduce the crash. Thanks! [1]: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Rusty Newton (rnewton) 2015-11-12 09:18:54.310-0600 Along with the backtrace (generated as described in the documentation) include a new debug log captured up until the time of the crash: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Vladimir Yordanov (vlado) 2015-11-12 09:30:52.950-0600 Hi, Ok, we'll provide such. Do you need any protocol level trace? Thanks! By: Łukasz Pelczar (luke) 2022-08-04 04:20:11.942-0500 Hello, is this problem still unresolved in asterisk 18?