by encryption a packet with sequence number 65535 followed
by a packet with sequence number 1. The second packet is encrypted
with a SRTP ROC of 1 as described in
https://datatracker.ietf.org/doc/html/rfc3711#section-3.3.1
The packets are (received and) decrypted in a different order,
the packet with sequence number 1 (and ROC=1) is decrypted first.
Since the ROC is maintained locally the decrypting session assumes
it to be 0.
Why is that a problem? The RFC recommends estimating the ROC with +-1 which, as demonstrated by the test, libSRTP does not.
But this is a rare problem that requires a random in a high range combined with packet loss/reordering which turns into no-a-problem if you choose carefully as done by packet_sequencer.cc which restricts the initial sequence number in the range 0..32767 which means you do not run into this issue in production.
See also Q6 in libsrtp's historical documentation at
https://srtp.sourceforge.net/historical/faq.html
BUG=webrtc:353565743
Change-Id: I9bd72b198c946937aeb25c229005a0c682447f53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358360
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42798}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
With this turned on, packets will be sequence number after the pacing
stage rather that during packetization.
This avoids a race where packets may be sent out of order, and paves
the way for the ability to cull packets from the pacer queue without
causing sequence number gaps.
For now, the feature is off by default. Follow-ups will enable it for
video and audio separately.
Bug: webrtc:11340, webrtc:12470
Change-Id: I6d411d8c85b9047e3e9b05ff4c2c3ed97c579aa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208584
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34661}
This prepares for deferred sequence numbering, and is (sort of)
extracted from
https://webrtc-review.googlesource.com/c/src/+/208584
Bug: webrtc:11340, webrtc:12470
Change-Id: I2f3695309e1591b9f7a1ee98556f4f0758de7f69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227352
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34643}
This CL is extracted from
https://webrtc-review.googlesource.com/c/src/+/208584
PacketSequencer now has its own unit tests. They are maybe somewhat
redundant with a few RtpSender unit tests, but will defer cleanup to
a later CL.
Bug: webrtc:11340, webrtc:12470
Change-Id: I1c31004b85ae075ddc696bdf1100d2a5044d4ef5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227343
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34638}
This CL refactors RtpSender and extracts handling of sequence number
assignment and timestamping of padding packets in a separate helper
class.
This is in preparation for allowing deferred sequencing to after the
pacing stage.
Bug: webrtc:11340
Change-Id: I5f8c67f3bb90780b3bdd24afa6ae28dbe9d839a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208401
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33316}
