DTMF fails only after attended transfer (Asterisk bridging / new INVITE, not REFER) – RFC2833 seen leaving PBX

FreePBX Providers
1

Hi all,

We’ve got a DTMF issue that only occurs after an attended transfer to an external PSTN number.

Scenario

  • Inbound PSTN call arrives via SIP trunk (Bandwidth/Voxbone).

  • Agent speaks to caller normally.

  • DTMF works fine during the initial call (IVR navigation etc).

  • Agent performs an attended transfer to another external PSTN number.

  • After the transfer completes, DTMF stops working on the transferred-out call.

What we’re seeing in Wireshark

  • DTMF mode is RFC2833 / telephone-event.

  • Codec is G.711 A-law.

  • At transfer time, Asterisk appears to create a new outbound call leg using a fresh INVITE and then bridges the call (i.e., B2BUA bridging). We do not see a SIP REFER in the trace.

  • We can see RTP telephone-event packets leaving the PBX towards Bandwidth’s media relay IP after transfer (digits like 3011* etc appear as RFC2833 events in the capture), but the far end IVR does not react after the transfer.

Bandwidth are calling this a “timing issue” and won’t change their platform, so we’re looking for any Asterisk/FreePBX-side workarounds.

Questions

  1. Has anyone seen DTMF break only after attended transfer / new-INVITE bridging?

  2. Any known Asterisk settings that affect post-transfer DTMF reliability? (e.g. relaxdtmf, directmedia, RTP handling, etc.)

  3. Any common SBC/media-relay quirks that require PBX-side mitigation?

Happy to share sanitized SIP/RTP snippets if helpful.

2

How? (Feature code, or SIP INVITE followed by REFER/Replaces?

Sounds like it is Bandwidth’s problem, as they must have offered RFC2833, but are then ignoring its use. Can you confirm that end digit messages are being sent, and not just start ones? Does DTMF work for a normal outbound call? If so what is the difference in what is sent to Bandwidth.

That’s how Asterisk handles transfers. If the request is done with SIP signalling, Asterisk doesn’t even know there is a transfer in progress until it gets the REFER/Replaces, from the transferror’s phone. It can’t do attended transfers up steam and you need to use the dialplan Transfer application for blind transfers. Transfer has to be explicitly called from your dialplan logic.

3

Have you tried chan_pjsip which uses RFC4733?

4

It’s unlikely that there will be any detectable differences in what goes over the wire.

5

Well I use Bandwidth with RFC4733 and we don’t have these issues at all. We do a lot of hotels that transfer calls to corporate systems that have their own IVRs and DTMF is working just fine. So I know this isn’t a Bandwidth/Voxbone issue.

6

Have you confirmed that audio from the caller to the transferred-to party is working correctly?

Have you tried sending DTMF inband?

Have you confirmed that the transferor can send DTMF before completing the transfer?

7

Guys, my suggestion for RFC4733 was to get the user off a dead SIP driver and on to one that is actually supported and using modern options. To use RFC2833 in Asterisk you have to be using chan_sip. So perhaps instead of trying to make the dead driver work, we should encourage the move to chan_pjsip to see if that helps and troubleshoot from there if needed.

I 100% know that using Bandwidth network with chan_pjsip and RFC4733 works for this scenario.

8

Thank you everyone, I can confirm we are using the older chansip at the moment.

DTMF works normally on the initial call, audio works normally after the call is transferred and DTMF is relayed out but Bandwidth said it was the call timing differences that was causing them to not relay the DTMF we sent, out to the far side.

I will look at switching us over to a new setup using the latest version and upgrade to pj_sip to see if this helps and ill report back, this will likely be towards the end of the week.

Thanks again

9

chan_sip simply passes requests to send telephone events to the RTP module:

which is shared with chan_pjsip

so there should be no difference in what is sent over the wire for the digit. I think the SDP code is also shared, so I assume no difference in the SDP. The only real difference is that chan_pjsip updated its terminology to give the latest RFC number for telephone events. (Nothing is done with the DTMF frame information, in either case, other than looking at the frame type, in the earlier part of the method in both drivers.)

However, it is my belief that Asterisk cuts corners on RTP time stamps, and that does sometimes cause problems. There should only be a discontinuity when the SSRC value changes, but Asterisk doesn’t properly track media sources, and just sets the marker bit, whose real meaning is that this is a good place to clear the jitter buffer, rather than this is where there is a timestamp discontinuity.

To analyse this further, you’d probably have to analyze the RTP stream with wireshark, and see if there is a discontinuity in the timestamps, and, if so, how it between the enquiry phase and the post transfer phase. Discontinuities in the normal media, at the transition, without an SSRC change may be significant, as well as discontinuities between normal media and telephone events, within a phase.