[asterisk-bugs] [JIRA] (ASTERISK-28827) Endless loop in res_rtp_asterisk.c

[nappsoft (JIRA)]

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

nappsoft commented on ASTERISK-28827:
-------------------------------------

ast_data_buffer_get is executed on line 7690 under the following condition: } else if (rtp->expectedrxseqno == -1 || seqno == rtp->expectedrxseqno) {

however the mentioned code for which the patch is is in the next else if clause: else if ((((seqno - rtp->expectedrxseqno) > 100) && timestamp > rtp->lastividtimestamp) ||
                ast_data_buffer_count(rtp->recv_buffer) == ast_data_buffer_max(rtp->recv_buffer)) {

> Endless loop in res_rtp_asterisk.c
> ----------------------------------
>
>                 Key: ASTERISK-28827
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28827
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.9.0
>            Reporter: nappsoft
>              Labels: patch, webrtc
>         Attachments: patch2.diff
>
>
> 100% CPU usage could be observed during a WebRTC call with clients with a bad internet connection. When this happened, asterisk was no longer sending any rtp packets out and it stayed in this state until the system got in an out of memory situation (what happened after a few minuts). However asterisk was still processing incoming packets (even after no more rtp packets were arriving on network level) as in the console the following message could repeatedly be seen:   
> == SRTP unprotect failed on SSRC 508868665 because of authentication failure 160 
> After looking into the code, I suspect that this happens because of the following fact:
> When a packet arrives while a packet with the same sequence number is already in the data_buffer (what can happen when the client retransmits a packet or when there is an error in the sequence number...) asterisk will end up in an endless loop as the packet with the same sequence number like the one that is currently being processed will never be removed from the data_buffer what means that the while condition will be true forever.
> I've attached a patch that should fix this issue. (If I've identified the right issue...)
> In the end this means, that one single changeset introduced 3 severe bugs what one really wouldn't expect from a LTS release... (https://github.com/asterisk/asterisk/commit/f295af447db656d14218f7b61c4bd7bd78d0b194)



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