Giacomo Garoffoli

Fixing PhreakNet DTMF on the TIM SmartModem (Technicolor TG789vac v2)

— by Giacomo Garoffoli

A small configuration error inside MMPBX prevents the TIM SmartModem (VANT-6) from sending RFC2833 DTMF events to PhreakNet.

Introduction

I've joined the PhreakNet network recently, it's a SIP-based VoIP network that emulates the classic Bell System telephone network. I didn't have any ATAs or VOIP phones (at the time), so I decided to try connecting with my TIM SmartModem using the built-in SIP client.

After resetting and configuring the SIP credentials, the modem registered successfully to PhreakNet. Outgoing calls connected, and I could hear the Bell second dial tone. Unfortunately, every time I pressed a key on the telephone, nothing happened. After about ten seconds the modem terminated the call with an Outgoing Failed message.

It turned out not to be a PhreakNet issue at all, but a hidden MMPBX configuration inside the firmware.

The symptoms

The problem is very specific:

  • SIP registration succeeds.
  • The modem reports the profile as Registered.
  • The call connects normally.
  • You hear PhreakNet's Bell second dial tone.
  • DTMF digits are completely ignored.
  • After a short timeout, the call ends with Outgoing Failed.

If this sounds familiar, you're probably hitting the exact same configuration error.

Verifying SIP registration

The first step was making sure the modem was actually registered to the SIP server. 

ubus call mmpbx.profile get '{"profile":"sip_profile_0"}'

The important part of the output looked like this:

{
  "sip_profile_0": {
    "sipRegisterState": "Registered",
    "enable": "true"
  }
}

Since registration was successful, authentication wasn't the problem.

Inspecting the SIP traffic

Next, I captured the SIP negotiation directly on the modem using tcpdump. 

tcpdump -A -i any port 17777

The SDP generated by the modem looked like this:

m=audio 47008 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Only PCMU (G.711 μ-law) was advertised. There was no telephone-event payload anywhere in the SDP.

A working RFC2833 negotiation should instead include something similar to: 

m=audio 47008 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

This immediately explained why PhreakNet never received DTMF digits after the second dial tone.

The hidden MMPBX configuration

MMPBX already contains support for telephone-event, but it's disabled by default in the codec filters.

Check the configuration with:

grep -A8 "config codec_filter" /etc/config/mmpbx

On my modem, I found this section:

config codec_filter
    option name 'telephone-event'
    option allow '0'
    option priority '99'
    option sample_rate '8000'

That single allow '0' line disables RFC2833 completely, even though the codec exists inside MMPBX.

The fix

Enabling the codec only requires changing two options through UCI. 

uci set mmpbx.@codec_filter[9].allow='1'
uci set mmpbx.@codec_filter[9].priority='2'
uci commit mmpbx
/etc/init.d/mmpbxd restart

After restarting mmpbxd, the modem starts advertising RFC2833 DTMF events correctly.

Verify the configuration

Run the same grep command again:

grep -A8 "config codec_filter" /etc/config/mmpbx

The configuration should now read:

config codec_filter
    option name 'telephone-event'
    option allow '1'
    option priority '2'
    option sample_rate '8000'

Testing the result

Capture another SIP INVITE with tcpdump.

Before the fix:

m=audio RTP/AVP 0

After the fix:

m=audio RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Once telephone-event appears in the SDP, PhreakNet immediately starts accepting DTMF digits after the second dial tone.

Why this happens

The TIM SmartModem uses Technicolor's MMPBX voice stack. While RFC2833 support is included in the firmware, the default codec filter disables telephone-event. Many VoIP providers never expose this issue because they either use SIP INFO or don't require DTMF after call establishment.

PhreakNet behaves much more like a traditional North American telephone network: it expects RFC2833 DTMF during an active call after presenting a second dial tone. Without telephone-event, the modem never sends those events and eventually cancels the call.

Final thoughts

This was one of those bugs that looks like a server-side problem until you inspect the SIP negotiation. The fix ended up being a single configuration flag buried inside MMPBX.

← Back to all articles