Summary:	ASTERISK-26561: chan_unistim on 11, 13, 14, UDP (rtp) ports left unclosed indefinitely
Reporter:	Ruse (jf-uk)	Labels:
Date Opened:	2016-11-06 13:36:11.000-0600	Date Closed:	2016-11-14 06:47:47.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_unistim
Versions:	11.24.1 13.12.1 14.1.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux ARM (raspberry, banana, orange pi), Linux Intel X86. Debian Linux, gcc/g++ as from standard Debian repos. Standard configure options (minus xml-doc). No customisation, standard configure, make install, test. No compile error work-arounds.	Attachments:	( 0) ASTERISK-26561-v1.diff
Description:	A Nortel UNISTIM protocol sets, when finished with any audio related operation, will leave its UDP (rtp) ports hung on the server. A subsequent call/use of an inbuilt Asterisk function requiring rtp ports be opened creates two more ports for the rtp streams. Ending the call by any means leaves another two UDP ports, one always with a measurable number of bytes in the Recv Queue. All versions exhibit the exact same issue. This quickly results in udp port exhaustion, and the entire Asterisk system is without udp autio paths. This is on all of the above platforms mentioned. I'm amazed nobody has come across this. Being we use a low (100) number of udp ports to work with other systems, as opening 65534 is not an option, and avoiding the issue, this is noticed easily. The issue can be repeated easily, with a unistim set, and asterisk, and a single prompt even, or a call to any channel. From the shell, issuing "netstat -l" shows listening ports as defined in rtp.conf sitting there, stacking up (on unistim calls, not any other protocol) and never released until an asterisk kill.
Comments:	By: Asterisk Team (asteriskteam) 2016-11-06 13:36:12.569-0600 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: Igor Goncharovsky (igorg) 2016-11-07 03:01:24.205-0600 Jason, Please test simple patch attached (it is also include some changes from my testlab). Only required change - adding ast_rtp_instance_stop before rtp instance destroy. By: Ruse (jf-uk) 2016-11-07 06:34:06.762-0600 Hi Igor, I applied the patch to the 14.1.1 current version on intel x86, removed the shared/object files and did a make again. Fixed! I also notice the mute button works properly too now. I am testing with two purple i2002's and a Cisco SPA SIP phone for inter-channel compatibility. To confirm: All udp ports are now released as expected. (I assume this is not platform dependant, as it's an ast_ call involved.) However, I am guessing this patch won't apply to the 11 and 13 current strains. 13 and 14 dropped support of the more robust h323 (NuFone) for the not as robust ooh323. So although this is fixed, the upgrade to 14 makes h323 inter- trunking go silent in the night. Thank you for your time on this. Is there any chance some of these fixes could be applied to the 11 and 13 strains? as they are still available, and preferred for various reasons. By: Igor Goncharovsky (igorg) 2016-11-07 07:54:37.364-0600 Hi, You can manually make such change in chan_unistim.c 11 and 13 and it should work. This fix should be released in future asterisk 13 and 14 version, but not in 11 branch (it is in Security fixes only state). + ast_rtp_instance_stop(sub->rtp); ast_rtp_instance_destroy(sub->rtp); By: Ruse (jf-uk) 2016-11-07 08:41:55.328-0600 Ahh. The patch did work on the chan_unistim.c in 11.20, applying the above as you mention. But oddly, the first pair of ports opened are stuck, but consecutive pairs close down properly, so one pair of UDP ports are stuck indefinitely. Truly odd. In 14 it's fixed. I'll try the 11.24.1 kit. By: Ruse (jf-uk) 2016-11-08 04:09:59.306-0600 On the 14.1.1 downloadable from asterisk.org on 7 Nov, 2016, the patch as supplied does correct the stuck UDP ports. This was tested with Nortel set-to-set and other channel to Nortel set, and vice versa. It looks simply to be a matter of Asterisk and the channel missing a little end handshake, as opposed to a general software, as indicated by the addition of a call in the patch. On a note, this patch also works as far back as 11.21.2, but not in 11.20 for the record. I state this as chan_h323 is phased out as of high-11's and chan_ooh323, its replacement, does not work with many Nortel and other large systems. There is a tipping point in compatibility over features after about the 11.22 point. Should I close this? Or is this up to a reviewer elsewhere? I hope it makes it into the next iteration, and am surprised nobody else ever noticed this. chan_unistim is a great addition to the asterisk kit, to provide even a migration path for those with significant Nortel IP set investment - which would naturally see companies that spend lots, moving to perhaps Digium's attractive SIP sets in an iterative upgrade. Thank you again Igor for the speedy find of this. By: Ruse (jf-uk) 2016-11-11 07:23:16.886-0600 I'm sorry I missed that 11 and 13 have been dumped, so for future looking purposes, this patch does correct the ports left laying around. Restarting the channel (unistim restart) from the console though, leaves the udp ports, as they don't get a ast_rtp_instance_stop(sub->rtp);, but this may be expected. Just a mention. I'll close this? It is pretty clear it fixed the issue as mentioned. By: Ruse (jf-uk) 2016-11-11 07:24:20.872-0600 Applied to the 41.1.1 strain, this prevents udp ports being left around. This was also applied to 11 manually, and 13, and solved it there too. By: Joshua C. Colp (jcolp) 2016-11-11 07:29:52.639-0600 Asterisk 11 is in security fix only. 13 remains supported and is receiving bug fixes. By: Joshua C. Colp (jcolp) 2016-11-11 07:30:43.565-0600 I've also reopened this issue, as the change is up for code review and once merged will close this issue. By: Ruse (jf-uk) 2016-11-11 13:05:08.480-0600 Sorry I didn't follow protocol in closing that.. I'm new (you can see) to this process.