[asterisk-bugs] [JIRA] (ASTERISK-27406) Infinite loop when out of ports and rtpstart value is odd

[Thomas Guebels (JIRA)]

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

Thomas Guebels edited comment on ASTERISK-27406 at 11/8/17 10:40 AM:
---------------------------------------------------------------------

Proposed patch: Rounding up the starting position to even, instead of rounding down

This remove the discrepancy between the rounding made before the loop and inside the loop, ensuring the break condition will always match.

It has the added benefit of not starting outside of the range (1 before rtpstart) in case we choose to round down in both places.


was (Author: tguescaux):
Rounding up the starting position to even, instead of rounding down

> Infinite loop when out of ports and rtpstart value is odd
> ---------------------------------------------------------
>
>                 Key: ASTERISK-27406
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27406
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.18.0
>            Reporter: Thomas Guebels
>         Attachments: round_up_to_even.diff
>
>
> When the rtpstart value configured in rtp.conf parity is odd and all RTP ports are already used, the next call will start an infinite loop.
> ast_rtp_new walks through the RTP port range configured until it finds a free one. It starts at a random position, wraps around at the end of the range and return an error if it comes back to the starting position. 
> Unfortunately, this code assumes an even value was set in rtpstart since we never go back to the starting position otherwise.
> Either a correct value for rtpstart should be enforced when parsing the configuration or the port lookup should not assume anything and never fail to break the loop.



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