fix(rtcp): re-latch RxStats on a mid-call SSRC change

[tinpotnick]

Re-latch RTCP receiver accounting when the peer's SSRC changes mid-call

RxStats latched the first remote SSRC and never updated it. If the peer's synchronization source changed during a call, every subsequent packet was folded into the previous source's RFC 3550 A.1/A.3/A.8 accounting — silently corrupting loss / jitter / MOS / RTT for the rest of the call.

This bites hardest on PSTN, where the media SSRC changes with no signalling as the call routes across endpoints — e.g. early media, then onto voicemail — sometimes with no re-INVITE at all.

Change

• Detect an SSRC change and reset the per-source accounting so the new SSRC is treated as a fresh stream (loss/jitter/RTT are never computed across the discontinuity).
• Two-sighting guard: a new SSRC must repeat on consecutive packets before the switch commits, so a single stray / reordered / spoofed packet can't wipe the accounting. The first sighting is not counted.
• Detection is RTP-driven (packet SSRC), independent of SIP signalling — so the no-re-INVITE PSTN case is handled.

Scope

• Fixes stats accounting only. The media/jitter path doesn't filter on SSRC, so audio continues across the transition regardless (unchanged).
• The re-latch is silent — no JS event is emitted. Emitting a source-change event (useful for PSTN call-progress logic) is noted as a possible follow-up.
• Same-SSRC source switches (sequence restart under an unchanged SSRC) remain handled by the existing RFC A.1 large-jump/bad_seq path.

Tests

• single_stray_ssrc_packet_does_not_relatch — a lone different-SSRC packet is ignored and the source stays latched.
• repeated_new_ssrc_relatches_and_resets_accounting — a repeated new SSRC relatches and discards the old source's loss/SR state.
• cargo test --lib 117 passing; clippy --all-targets + rustfmt clean.

🤖 Generated with Claude Code