Skip to content

fix: lingering DTMF suppression after fan-out end events - #2193

Open
vingarzan wants to merge 2 commits into
sipwise:masterfrom
vingarzan:fix/dtmf-fanout-suppression
Open

vingarzan wants to merge 2 commits into
sipwise:masterfrom
vingarzan:fix/dtmf-fanout-suppression

Conversation

@vingarzan

Copy link
Copy Markdown
Contributor

When one RTP source is transcoded to several listeners, the end of a telephone-event can leave speech suppressed on all but the first listener. A live AMR-WB phone-to-phone/browser trace showed continuous browser speech while the second phone had a 4.204-second output gap. Which listener is affected depends on destination processing order.

packet_dtmf_event() deduplicates completed events through the shared media's dtmf_ts, but speech suppression is stored in each destination's primary input handler as dtmf_start_ts. The first handler processes the END and clears its state. Subsequent handlers return through the duplicate-event path without clearing theirs. packet_decode() then suppresses speech until its 80,000-tick timestamp-discrepancy fallback expires, corresponding to five seconds at the source's 16 kHz clock.

Clear the matching input handler's suppression state in the duplicate-event path. Match the event timestamp so a retransmission of an older completed event cannot clear suppression for a newer active event. Keep completed-event reporting deduplicated.

Add a regression with AMR-WB input, AMR-WB and Opus listeners, a PCMU event sink, directional blocking, prompt playback, repeated DTMF END packets, and two talk bursts. Exercise both listener orders and assert timely, continuous speech RTP after END.

Clear the matching per-destination suppression state when a completed telephone-event is deduplicated at media scope. Otherwise later listeners suppress speech until the timestamp-discrepancy timeout expires.

Add repeated-burst coverage for AMR-WB and Opus listeners in both destination orders, with blocked DTMF, prompt playback, and an event sink.
…equires AMR-WB encoding unavailable in standard CI
@vingarzan
vingarzan force-pushed the fix/dtmf-fanout-suppression branch from 611bdad to 242de7c Compare October 9, 2026 14:09
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.

1 participant