jitter: shorten the restart run when it starts beyond the reorder window

[ahsang]

Summary

Rebased on #93 / #95 as suggested. This is now a small change to sequenceRestart.

• A sender that re-anchors its sequence far behind prevSN still had to wait out the full sequenceRestartRun (20). On a captured PBX transfer (same SSRC, 21294 → 12676) that is ~380 ms of dropped audio for packets that cannot be late: they are 8618 behind, well outside the 3000-packet reorder window.
• When the first expired packet of a run is outside withinRange(sn, prevSN), the run only needs farSequenceRestartRun (2). The resync still goes through restartStream(), so SequenceRestarts, the flush and the drop counters are unchanged.
• It still takes 2 packets, not 1, so a single stale packet from far behind cannot rewind the stream. A run that starts inside the window keeps the 20-packet rule, so TestSequenceRestart / TestSequenceRestartFalsePositive are unaffected.

Tests

• TestSequenceRestartFar: the captured jump. It resyncs after 1 dropped packet. On main it drops 19.
• TestSequenceRestartFarStray: a lone far-behind packet is dropped and the live stream carries on with no restart.
• go test -race ./jitter/ passes. (TestResample in the root package fails under -race on main too. It is unrelated.)

Related

• Give each incoming SSRC its own jitter buffer so a transferred stream is not muted sip#828 (per-SSRC jitter buffers) is largely superseded by TEL-1046: reset prevSN on SSRC change #93.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[hechen-eng]

within the window is probably not gonna fix everything. We do see traffic that restarts sn but still within range. #95

[hechen-eng]

@ahsang we took a different approach, see #93 and #95. Can you rebase and make the change in sequenceRestart, e.g. shorten the required run when the first expired packet lands outside withinRange? this way we can keep the counters/flush, etc 👍