Open
Description
Currently sequence numbers for outbound RTP packets are created internally inside the track(in the case of TrackLocalStaticSample
) and by the user in case of TrackLocalStaticRTP
. There are several problems with this:
- If a track is bound to two different
RTCRtpSender
s the sequence numbers used by each RTP stream will be the same. This weakens SRTP and makes known-plaintext attacks easier. - It breaks
RTCRtpSender::replace_track
which should allow replacing the current track with a different track with a matching envelope. Since the other track will have its own random starting sequence number this will not work in many instances(the sequence numbers between the two tacks should be consecutive). - When pausing one of several
RTCRtpSender
that a track is attached to the resulting gap in sequence numbers can cause SRTP validation to fail at the remote side(if the sender is paused for long enough). An attempt to address this is made in Pause in TrackBinding when direction is not send #316
Suggestion
Move sequence number generation out of the track layer and into transport.
For TrackLocalStaticRTP
this might mean that the underlying transport layer overwrites the sequence number of packets passed to write_rtp
or perhaps we have a way to signal in TrackLocalStaticRTP
whether sequence numbers should be respected or not