docs: say that RtpWrite's seq_no is extended and drives the SRTP ROC

[AlexanderSerbul]

Docs only — no behaviour change.

RtpWrite::new documents seq_no as "Sequence number to use for this packet". In direct RTP mode that number is also what str0m hands to protect_rtp as the SRTP index, so its upper bits become the rollover counter (roc = srtp_index >> 16).

The ROC is never transmitted, and a receiver seeing a stream for the first time starts at ROC 0 (RFC 3711 §3.3.1). So a stream whose first packet is at or above 65_536 gets encrypted with a key the receiver will not derive. The failure is silent and looks nothing like a crypto problem: the packets arrive, candidate-pair/transport byte counters climb, packetsDiscarded stays 0, and inbound-rtp is simply empty.

This is easy to hit in an SFU, where passing an incoming stream's extended sequence number straight through looks like the neutral choice. It isn't: a subscriber joining a publisher that has been sending for more than 65_536 packets starts past the first rollover and gets nothing, while everyone who joined earlier keeps working — so it reads as a routing or NAT bug for a good while. Rebasing the outgoing numbering by a whole number of rollovers fixes it and leaves the wire sequence number untouched.

When str0m generates sequence numbers itself (media API) it starts from SeqNo::default(), so the contract is met automatically; it is only the direct RTP path where the caller owns it. This patch just writes that down.

🤖 Generated with Claude Code

[algesten]

Hi! Thanks for bringing this up.

This might be problem rather than just a documentation error. I'm a bit unsure.

You could easily see SFU situations where you have an incoming, long running source stream forked out to many clients that come and go. The source goes into ROC, and then clients join.

The actual wire RTP will course not start at a high ROC, but, do we expect str0m to internally be consistent with the high ROC start or not?

@pthatcher what would your gut feeling be?