Skip to content

fix: prevent RTCP from corrupting RTP address latching#24

Merged
shenjinti merged 1 commit intorestsend:mainfrom
yeoleobun:fix/rtcp-mux-latching
Mar 30, 2026
Merged

fix: prevent RTCP from corrupting RTP address latching#24
shenjinti merged 1 commit intorestsend:mainfrom
yeoleobun:fix/rtcp-mux-latching

Conversation

@yeoleobun
Copy link
Copy Markdown
Collaborator

@yeoleobun yeoleobun commented Mar 27, 2026

Summary

Same bug with #23, but that is caller side, this is the callee side:

RustRTC have rtcp-mux enabled as default, but the answer of microsip is not, so the problems is:

  • we didn't update the rtcp address from the answer
  • microsip will send stun from rtcp port to our muxed rtp port then the rtp will stun to micro sip rtcp port (rarely , but still possible when the rtcp comes before rtp)

When the remote peer does not support rtcp-mux, RTCP arrives from a
separate port. The latching code treated RTP and RTCP identically,
allowing an RTCP source address to override the RTP remote address,
causing audio to be sent to the wrong port.

- Skip latching on RTCP packets (PT 200-211) when remote_rtcp_addr is
  set (non-mux mode)
- Auto-update rtcp-mux from answer in set_remote_description, fixing
  the race where the ICE pair callback fires before the answer is stored
- Add public update_rtcp_mux_from_remote() for manual override

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@yeoleobun yeoleobun force-pushed the fix/rtcp-mux-latching branch from 59bf4c9 to 629efcb Compare March 27, 2026 08:03
@shenjinti shenjinti merged commit aae0848 into restsend:main Mar 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants