GCC (NoOpPacer and other pacers) drop NACK RTX because of SSRC

[arjunshajitech]

Your environment.

• Version: v0.1.44
• Browser: Chrome

What did you do?

Set up a WebRTC pipeline in the following topology :

Client A (browser sender) → pion server → Client B (browser receiver)

• Client A sends video to Client B via a pion server.
• Client B sends a NACK for a missing packet.
• The NACK Responder Interceptor correctly processes the NACK and attempts to retransmit (RTX) the buffered packet.
• The sender-side interceptor chain also has the GCC (Google Congestion Control) interceptor enabled, configured with NoOpPacer.

What did you expect?

The RTX packet should be delivered to Client B.

What happened?

The RTX packet is silently dropped by the NoOpPacer (and other pacers) because the packet's SSRC does not match the tracked SSRC in the pacer state.

The following warning is logged by the NACK responder:

nack WARNING: 2026/03/03 14:58:20 failed resending nacked packet: unknown ssrc: 1913968682

The NACK Responder correctly processes the NACK and attempts retransmission, but the CC layer blocks the write. The receiver never gets the retransmitted packet.

Root Cause

The check at [noop_pacer.go#L50](https://github.com/pion/interceptor/blob/7cc50665cc3f8ab3457393229ec75e8b899e6909/pkg/gcc/noop_pacer.go#L50)

rejects any RTP packet whose SSRC was not originally registered with the pacer. RTX retransmissions use a separate SSRC (the RTX SSRC, negotiated via apt in SDP), which is never registered with the GCC pacer, causing every retransmitted packet to be rejected.

The same root cause likely affects all other pacer implementations in pkg/gcc/.

[arjunshajitech]

@JoTurk

Hi,

Could you please confirm if removing the SSRC-based map and using a single writer is the correct approach, since the underlying transport is the same?

Would appreciate your suggestion on whether this is the right way to handle it.

If needed, I can share the test code and reproduction steps for more context.

[mengelbart]

I'm not sure removing the map is the right solution, but you could implement your own pacer without a map, using the same writer for all writes.

However, please also see #401 and the ongoing work in pion/bwe. I would like to remove congestion control from interceptors. Pacing can be done separately now, and congestion control will be implemented in pion/bwe, without interceptors. The only reason we need interceptors is to keep track of outgoing packets and incoming feedback, but that is independent of bandwidth estimation.

[arjunshajitech]

I'm not sure removing the map is the right solution, but you could implement your own pacer without a map, using the same writer for all writes.

Yes, I’ve implemented it that way using a single writer.

Another possible approach I’m considering is registering the NACK SSRC as well via AddStream.

However, please also see #401 and the ongoing work in pion/bwe. I would like to remove congestion control from interceptors. Pacing can be done separately now, and congestion control will be implemented in pion/bwe, without interceptors. The only reason we need interceptors is to keep track of outgoing packets and incoming feedback, but that is independent of bandwidth estimation.

that makes sense.

[Krage56]

Another possible approach I’m considering is registering the NACK SSRC as well via AddStream.

It also may be solved by creating custom pacer with special API to make a deal with RTX and FEC streams. From my point of view it is more complicated but gets u some tools to manage the streams more accurately