| Summary: | ASTERISK-26207: [patch] sRTP: Count a roll-over of the sequence number even on lost packets. | ||
| Reporter: | Alexander Traud (traud) | Labels: | |
| Date Opened: | 2016-07-18 05:19:47 | Date Closed: | 2016-07-22 11:30:56 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk |
| Versions: | 11.22.0 13.9.1 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) roc_0x7fff.patch | |
| Description: | See the sRTP FAQ, [Question 6…|http://srtp.sourceforge.net/faq.html#Q6]
With RTP media, each packet gets its own sequence number to detect lost and late packets. That sequence number is limited to a value of {{0xffff}}. To avoid any replay-attacks, sRTP introduced a counter which is incremented whenever the sequence number rolls over (ROC). The ROC is not transmitted. Therefore, both sender and receiver must note each roll over of the sequence number. The initial sequence number is created randomly. However, when - that random value is near the maximum value *and* - the first RTP packets get lost (or arrive late), the receiver might not notice the roll-over of the sequence number. The receiver might think, the RTP sequence started at 0,1,2,3…. Consequently, the ROC is of the receiver is 0. The ROC of the sender is 1. Both parties lost ROC synchronization. Therefore, the receiver is not able to decrypt the sRTP packets anymore. No media is the result. The mentioned webpage therefore suggests: The SRTP sender should randomly select an initial sequence number that is between {{0x0000}} and {{0x7fff}}. The attached patch does this. | ||
| Comments: | By: Stephan Eisvogel (eisvogel) 2016-07-22 06:39:05.140-0500 Hey Alexander, any chance this fix is causing huge false lost packet counts in sip show channelstats? Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter 217.0.23.100 p65562t1469 00:01:20 0000003774 0000000000 ( 0.00%) 0.0000 0000003775 0000001998 (52.93%) 0.0001 dropping after a while to this 217.0.23.100 p65562t1469 00:06:38 0000019663 0000000000 ( 0.00%) 0.0000 0000019663 0000001998 (10.16%) 0.0001 Should be zero because that is a Telekom upstream on unloaded VDSL. Regards, Stephan By: Alexander Traud (traud) 2016-07-22 11:30:26.263-0500 Not related because that change here just limits the random range. The counter might have started at the same position, even before that change. Consequently, you have to continue to search the cause of these RTCP statistics. | ||