So what happens here is that at some point we receive packet #10508,
which triggers the big gap logic, placing that buffer inside the
gap_packets GList:
gst_rtp_jitter_buffer_chain: expected #10529, got #10508, gap of -21
handle_big_gap_buffer: buffer too old -21 < -20, first one - waiting

Then packet #10550 arrives:
gst_rtp_jitter_buffer_chain: expected #10530, got #10550, gap of 20

This causes too many timers to be pending, causing a reset:
gst_rtp_jitter_buffer_chain: 182 pending timers > 180 - resetting
gst_rtp_jitter_buffer_reset:< flush and reset jitterbuffer

Inside the reset() code, the next_seqnum is set to the first buffer
in gap_packets, #10508:
gst_rtp_jitter_buffer_reset: setting next_seqnum to #10508

And reset() calls chain() with all its gap_packets, pushing it out:
gst_rtp_jitter_buffer_chain: Received packet #10508 at time 123:45:05.364650711, discont 0, rtx 1

However, #10508 is actually an RTX packet, so it gets dropped:
gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> Unsolicited RTX packet #10508 detected, dropping

Next #10550 is pushed from reset():
gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> Received packet #10550 at time 123:45:05.516136868, discont 0, rtx 0

But because next_seqnum is set to #10508, we get this:
handle_next_buffer: Sequence number GAP detected: expected 10508 instead of 10550 (42 missing)

So now the jitterbuffer is completely stalled, all buffer arriving now will
just queue up until it sees the promised #10508, which will be ~65000
packets from now, and we will trigger the "full" logic before then,
causing a deadlock.