Jitter buffer: are these NULL ssrc_in/ssrc_out dereferences reachable, or safe by design?

Ivan Hristov

unread,

Jul 7, 2026, 5:07:40 AMJul 7

to Sipwise rtpengine

Hey

We hit repeated jitter-buffer crashes in production on NULL mp->ssrc_in / mp->ssrc_out — reported earlier as GitHub issues #2112 and #2124. The #2124 fix added a NULL guard to codec_calc_lost(), which tells us these pointers can legitimately be NULL at handler time.

Reading the code around that fix (at mr14.1.1.15), we noticed a few nearby dereferences of the same pointers that don't seem to have a similar guard, and we're unsure whether they're actually reachable with NULL or safe by an invariant we're missing. The two we're most unsure about:

- handler_func_passthrough_ssrc — dereferences ssrc_in/ssrc_out a few lines after the codec_calc_lost guard in the same function.
- __delay_frame_process — on the delay/jitter timer path; we're wondering if a frame buffered while its SSRC is still unresolved could carry a NULL through to the timer thread.

Are these protected by something we can't see, or worth guarding? We were never able to reproduce this in testing — it only ever showed up under production traffic, which is why we're asking here rather than sending a repro.

Best Regards,

Ivan Hristov

Richard Fuchs

unread,

Jul 7, 2026, 11:09:28 AMJul 7

to rtpe...@googlegroups.com

As far as I can tell, both of these functions are relevant only in a transcoding scenario, and as such can only be reached if the packet has a valid RTP header and if the payload type is set for transcoding, which implies that a SSRC must be present.

At least I don't see any immediately obvious way to hit these functions without a valid SSRC.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/37d4cac5-c836-430b-ba9b-b4442aa1f111n%40googlegroups.com.