All DTMF events from FRITZ!Box ignored

[bits0rcerer]

I use diago to register as a client on a FRITZ!Box 7530 AX. When I now call that client and try to send DTMF events from a phone, diago ignores all events.

---

Audio and DTMF reader setup

dtmf := &diago.DTMFReader{}
dtmf.OnDTMF(onDTMF)

props := &diago.MediaProps{}
ar, err := dialog.AudioReader(diago.WithAudioReaderMediaProps(props), diago.WithAudioReaderDTMF(dtmf))

/* ... */

bytes, err := media.Copy(ar, w)

Now I press 5 on the phone but onDTMF never gets called.

---

Logs

2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:false Volume:0 Duration:0}"
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:false Volume:0 Duration:0}"
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:false Volume:0 Duration:0}"
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:false Volume:0 Duration:800}"
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:false Volume:0 Duration:800}"
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:true Volume:0 Duration:800}"
2026-03-07 21:47:08 DBG Received DTMF packet but short duration dur=0
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:true Volume:0 Duration:800}"
2026-03-07 21:47:08 DBG Received DTMF packet but short duration dur=0
2026-03-07 21:47:08 DBG Processing DTMF event ev="{Event:5 EndOfEvent:true Volume:0 Duration:800}"
2026-03-07 21:47:08 DBG Received DTMF packet but short duration dur=0

It seems that all events are incorrectly filtered out by the duration filter.

---

#116 applied (and cleaned up) on release 0.27.0 seems to fix the issue. v0.27.0/fix/fritzbox-dtmf

[emiago]

I have looked on that PR, and it failed some tests. Unfortunately no feedback after.
THere is some probably issue with current approach or there are more corner cases to fetch.

thanks for logs
Is this some special phone or something I could use it? I wonder why duration/volume is represented like that.

[bits0rcerer]

A FRITZ!Box is an all-in-one home internet gateway made by AVM GmbH that typically combines a modem (DSL/cable/fiber), router, Wi-Fi access point, Ethernet switch, and a small VoIP/DECT phone system in a single device commonly used by German ISPs.

In Germany, people often use “Fritzbox” almost generically to mean “the home router”, even if technically it’s just one brand.

---

Given, the volume and duration fields are kinda odd and telephone services aren't the main focus. But it is very common so arguably not anything exotic and worth to support imo.

---

The phone is just some off the shelf panasonic dect phone.

[emiago]

Hi @bits0rcerer . I added now better handling of DTMF. Remove dur check (can not recall why this I had but probably some code arround PSTN tones).

Still based on logs, I can not really say this are valid or invalid events. Normally duration is incremented.
Here is per RFC some example how this events should be sent.

https://datatracker.ietf.org/doc/html/rfc4733#section-5

Maybe best would be that I get some PCAP.

[bits0rcerer]

Sorry for the late response.

I tried main branch but it unfortunately did not solve the issue.

I recorded the network packets for two dtmf events where i pressed 1.

Interestingly it tries first to send it via SIP INFO request but diago responds with 406 Not Acceptable then it tries RTP events.

dtmf.pcap.gz

---

It consistently sends:

• 3 packets with event duration=0, end_of_event not set, mbit set
• 2 packets with event duration=800, end_of_event not set, mbit not set
• 3 packets with event duration=800, end_of_event set, mbit not set

[emiago]

Yeah. I did not say it fixes your case. It seems like we need to handle events with zero duration as well, but right now at least some this duration filtering is removed. I think I will have some solution even for this.

[bits0rcerer]

Based on the rfc i implement the dtmf parsing with the following assumptions in mind:

• all dtmf events are mutually exclusive
  • they cannot have the same rtp timestamp
  • a new dtmf event ends an ongoing dtmf event
• filtering dtmf events based on rtp timestamp -> it has to increase monotonically
• filtering based on duration -> it has to increase monotonically

I added some new tests and made sure the current tests still pass

---

The changes are available here: bits0rcerer@a43ac80. If you like I can open a PR.