Open k0nserv opened 1 year ago
One problem with this suggestion is that TrackLocalStaticSample
has a way to propagate dropped packets via sequence number gaps which would break https://github.com/webrtc-rs/webrtc/blob/5612d59869e1a4b8d991ab129ab27103c2975f5b/webrtc/src/track/track_local/track_local_static_sample.rs#L55-L60
Another part to this is when we implement RTX resend properly. Each RTX channel have separate SSRC and sequence number counter to the one it's repairing. It would seem logical that all sequence number generation is an internal concern and only done just before pushing the packet to the wire.
Currently sequence numbers for outbound RTP packets are created internally inside the track(in the case of
TrackLocalStaticSample
) and by the user in case ofTrackLocalStaticRTP
. There are several problems with this:RTCRtpSender
s the sequence numbers used by each RTP stream will be the same. This weakens SRTP and makes known-plaintext attacks easier.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).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 https://github.com/webrtc-rs/webrtc/pull/316Suggestion
For
TrackLocalStaticRTP
this might mean that the underlying transport layer overwrites the sequence number of packets passed towrite_rtp
or perhaps we have a way to signal inTrackLocalStaticRTP
whether sequence numbers should be respected or not