[asterisk-bugs] [JIRA] (ASTERISK-26561) chan_unistim on 11, 13, 14, UDP (rtp) ports left unclosed indefinitely

[Jason (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233467#comment-233467 ] 

Jason commented on ASTERISK-26561:
----------------------------------

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. 

> chan_unistim on 11, 13, 14, UDP (rtp) ports left unclosed indefinitely
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-26561
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26561
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_unistim
>    Affects Versions: 11.24.1, 13.12.1, 14.1.1
>         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. 
>            Reporter: Jason
>            Assignee: Igor Goncharovsky
>         Attachments: ASTERISK-26561-v1.diff
>
>
> 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. 



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