[asterisk-bugs] [JIRA] (ASTERISK-28827) res_rtp_asterisk: Loop when receive buffer is flushed by a received packet that is also in receive buffer with NACK

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp commented on ASTERISK-28827:
-------------------------------------------

As well, like I said I strongly urge you to test out release candidates. The code in question was in testing by us daily for over a week, it went through code review, and went through release candidates. Any help in those before a release occurs helps to catch stuff like this.

> res_rtp_asterisk: Loop when receive buffer is flushed by a received packet that is also in receive buffer with NACK
> -------------------------------------------------------------------------------------------------------------------
>
>                 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
>            Assignee: 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)