| Summary: | ASTERISK-20415: Strict RTP protection learning mode processes non-RTP packets too | ||
| Reporter: | Michele Cicciotti (PrivateWave SpA) (michele cicciotti privatewave) | Labels: | |
| Date Opened: | 2012-09-12 14:00:54 | Date Closed: | 2012-09-25 14:37:49 |
| Priority: | Minor | Regression? | Yes |
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk |
| Versions: | 1.8.15.1 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | 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 | ||
| Comments: | By: Kinsey Moore (kmoore) 2012-09-25 14:28:07.260-0500 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. By: Kinsey Moore (kmoore) 2012-09-25 14:37:49.676-0500 The fix has been committed to 1.8 and 10. | ||