[asterisk-bugs] [JIRA] Commented: (ASTERISK-20415) Strict RTP protection learning mode processes non-RTP packets too

[Kinsey Moore (JIRA)]

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

Kinsey Moore commented on ASTERISK-20415:
-----------------------------------------

Hi Michele,
It looks like the fix for this particular problem has already been applied to Asterisk trunk, but was never committed to 1.8 and 10.  This change should be going in shortly.

> Strict RTP protection learning mode processes non-RTP packets too
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-20415
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20415
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 1.8.15.1
>            Reporter: Michele Cicciotti (PrivateWave SpA)
>            Assignee: Kinsey Moore
>            Severity: Minor
>
> Most of ast_rtp_read does a good job of filtering out non-RTP packets that are transmitted on RTP channels (e.g. STUN or ZRTP), but the strict RTP protection doesn't. It passes the sequence number part of the header to rtp_learning_rtp_seq_update unconditionally, but for non-RTP packets the field has a different meaning (e.g. a distinct sequence number for ZRTP messages, or the message length for STUN packets), which "poisons" learning mode and can lead strict RTP protection to drop all packets on a certain channel
> There needs to be a check for at least the version field before passing the sequence number to rtp_learning_rtp_seq_update: if it is 0, the packet can't be RTP (which is exactly what is done later to recognize STUN packets)
> This is a regression from 1.8.9.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira