[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=233442#comment-233442 ] 

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

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. 

> 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)