IVR prompt - not working on iphone

[MaxBravo]

I just setup a new domain, I have a number of IVR menus in a call tree. Which work fine from an external dial-in on a desk VoIP phone (on a completely different system, it happens to be a ringcentral phone), but when I dial-in from my cell phone (iphone 13) or most other iphones as I tested with a number of others, the IVR menu prompt options do not work.

Immediately this suggests to me a DTMF issue, the SIP profile is set to DTMF_type rfc2833, I even added a "start_dtmf" option to the inbound route, which I read somewhere was perhaps necessary. Still no luck. I cannot explain it. I'm at a loss I've tried a few things already. Perhaps someone here has a good idea?

 

[MaxBravo]

switch_core_media.c:9089 sofia/external/********************** Set 2833 dtmf send payload to 101

this is what I'm seeing in the logs.

 

[MaxBravo]

Can someone please help me here? I can't believe that our instance is the only one facing this issue.

 

[markjcrane]

You have to find out what type of DTMF your VoIP provider is supporting. FreeSWITCH uses rfc2833 by default. Instead of guess look at documentation from your VoIP provider or put in a ticket and ask them what type they are using. Most VoIP providers use rfc2833 so its not a problem in most cases.

 

[MaxBravo]

Thanks for the reply. So here is the strange behavior, most phones which dial in to this IVR seem to work just fine. However, the phones which I've used to here to test are iphones and for some reason when they dial in they the tones are audible but the IVR does not respond. But on other domains which were created some time ago on the same PBX instance the IVRs work. I'm wondering if there were any changes to the way the IVRs recognize dtmf recently? It is very strange and only have seen it in a handful of iPhones, interestingly enough other iPhones have worked. I'm really at a loss... I really hate problems like this because there are no clear indications of where the issue is.

 

[markjcrane]

An iphone is going to call through the mobile network through the PSTN unless you are using a soft phone. So which way are you doing it saying iphone is not specific enough.

 

[MaxBravo]

I am using an iPhone via the PSTN, the reason I'm highlighting the iPhone is because this is where the issue occurs. On a VoIP desk phone when I press 1 for example the IVR responds. Not the case on multiple iPhones with calls placed to the PSTN. Incidentally, a softphone App on an iPhone works just fine.

So to be very clear, the issue is that a call to the PSTN from the iPhone's native call app over the mobile carrier network to the IVR that I setup recently and any new IVR I setup after that point do not respond to dtmf tones. Option 1 for example does not go anywhere.

 

[hfoster]

Probably a question for your SIP trunk provider, I have seen a similar fault where an inbound carrier had the DTMF clipped as some sort of VAD/compression, was only for specific routes into the network though.

 

[MaxBravo]

Can I DM you a test IVR for you to try, it looks like all new IVRs that I create have this issue with newer iPhones, however works fine with an older iPhone also works fine on a VoIP phone calling the PSTN. This is an annoying issue yet seems exceedingly difficult to troubleshoot in a meaningful way without understanding the inner workings of how the IVR accepts DTMF input, understanding which sadly I do not have.

 

[MaxBravo]

Still going back and forth on this, for a minute I had a feeling that this might be carrier related. But I am not convinced anymore, I still can't pin it down but here is another salient data point. On the same fusionPBX instance, which has been operating since 2021 there are older IVRs which were created years ago on a different domain which work with iphones as in they respond to the DTMF commands. But any new IVRs created since some update I am not sure which one do not work with iphones. Which leads me to believe there has been some change in the way FusionPBX IVRs handle dtmf tones coming from certain carriers?

 

[MaxBravo]

It may be a SIP trunk issue, we use Twilio, as per their documentation,

What DTMF types do you support?
Out of band RFC-2833 is supported. Out of band SIP INFO is not currently supported. In-band DTMF tones within the G.711 audio stream are passed-through in the audio stream untouched.

If this is the case, why does it work with the older IVRs and not the new ones built on the same fusionPBX instance?

 

[MaxBravo]

The PBX is getting the DTMF tone, you can see it here

rtp_local_sdp_str​

v=0 o=FreeSWITCH 1679514607 1679514608 IN IP4 23.184.64.62 s=FreeSWITCH c=IN IP4 23.184.64.62 t=0 0 m=audio 22658 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp: off - - - - a=ptime:20 a=sendrecv​

101 telephone-event/8000

but the IVR is doing nothing with it.

Cannot explain why...

 

[MaxBravo]

This is the feedback from Twilio on this,

Upon checking the example Call SID, I can see that the SIP dialogue was not properly established. When we are sending the INVITE to your PBX, your PBX is responding with 100 Trying and 183 Session Progress (which is designed for ringback) however your server never sends 200 OK in response to the INVITE. The reason the caller can hear the prompt is because your PBX is playing the prompt via the 183 Session Progress. Since the dialogue is not established, DTMF cannot pass through.

Please check the PBX and ensure it is sending a 200OK in response to our INVITE. Please let me know if you have any other questions or concerns and I will be happy to assist.

For the working call, I can see that your PBX is returning a 200OK in response to the INVITE:

However, for the non-working call, your PBX is not sending us a 200OK which causes Twilio to send a SIP CANCEL (which your PBX then responds with a 200OK in response to the CANCEL):

 

[hfoster]

Possibly the behaviour change is this commit?

Add answer to IVR Menu dialplan. · fusionpbx/fusionpbx@9212305

Whether to add application answer to the IVR Menu dialplan.

github.com

 

[MaxBravo]

Thank you for your reply, would this commit have affected all IVRs in existence on the particular FusionPBX instance on any domain or only new ones that were created after this change?

 

[hfoster]

Only when you create one, after you pulled that update. If you did at all, you can always compare a working one in the dialplan with a broken one. The IVR is in XML format, so make sure to click the button in the top right for XML

 

[MaxBravo]

I think what you suggested checks out,

Old IVR before pulling the update

<extension name="Daytime Main Greeting" continue="false" uuid="5b5eba02-a1cc-43d2-a3f3-c319dd121cfb">
    <condition field="destination_number" expression="^600$">
        <action application="ring_ready" data=""/>
        <action application="answer" data=""/>
        <action application="sleep" data="1000"/>
        <action application="set" data="hangup_after_bridge=true"/>
        <action application="set" data="ringback=local_stream://default"/>
        <action application="set" data="presence_id=600@multimek.**********"/>
        <action application="set" data="default_language=en" inline="true"/>
        <action application="set" data="default_dialect=us" inline="true"/>
        <action application="set" data="default_voice=callie" inline="true"/>
        <action application="set" data="transfer_ringback=local_stream://default"/>
        <action application="set" data="ivr_menu_uuid=a86943f7-889f-4bf7-9e2e-5a2dc3860b1b"/>
        <action application="ivr" data="a86943f7-889f-4bf7-9e2e-5a2dc3860b1b"/>
        <action application="transfer" data="600 XML multimek.***********"/>
    </condition>
</extension>

New IVR after pulling the update

<extension name="Main Demo IVR" continue="false" uuid="c12561de-5361-4865-94e4-46736a8ab9b5">
    <condition field="destination_number" expression="^1000$">
        <action application="ring_ready" data=""/>
        <action application="sleep" data="1000"/>
        <action application="set" data="hangup_after_bridge=true"/>
        <action application="set" data="ringback=local_stream://default"/>
        <action application="set" data="default_language=en" inline="true"/>
        <action application="set" data="default_dialect=us" inline="true"/>
        <action application="set" data="default_voice=callie" inline="true"/>
        <action application="set" data="transfer_ringback=local_stream://default"/>
        <action application="set" data="ivr_menu_uuid=0157e39e-6222-43e0-afdf-52bc2300ee60"/>
        <action application="ivr" data="0157e39e-6222-43e0-afdf-52bc2300ee60"/>
        <action application="transfer" data="1000 XML demo.***********"/>
    </condition>
</extension>

 

[MaxBravo]

This line looks like it is missing in the new one, <action application="set" data="presence_id=600@multimek.**********"/>

Adding this line with the correct parameters into the new one does not seem to make a difference however.

 

[MaxBravo]

Here's something I see,

Working IVR, Call-direction is above 30





Not working IVR, Call-direction is 35





Turns out to have no effect on the DTMF issue.... I don't know I am at a loss.


Where in the dial plan is the 200OK sent?

 

[MaxBravo]

I think I just realized something.... The Twilio comment about the 200OK being received from the working call is only because the call went through to a ring group. Because of course the working calls are able to engage the IVR options and get through to the end of the menu. The ones that do not are stuck in the 183 Session Progress State. So, in reality presumably after some code change in the FusionPBX, it is no longer sending a 200OK (INVITE) regardless of the call working or not. I believe that is why the DTMF does not work now with some carriers, they are waiting for the 200OK (INVITE) to send DTMF which they never receive.

So, there are two possibilities that I can think of, one that this is still a SIP trunk provider issue, or there was some change in the FusionPBX code to not setup a call when the IVR is rung.

Old IVR, (always works)

INVITE => 100 Trying => 180 Ringing => 200 OK (INVITE) (even within IVR)

New IVR, (does not always work, depends on carrier)

INVITE => 100 Trying => 183 Session Progress => Cancel => 200 OK (CANCEL)