IVR prompt - not working on iphone

Status
Not open for further replies.

MaxBravo

Member
May 21, 2022
36
0
6
51
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

Member
May 21, 2022
36
0
6
51
switch_core_media.c:9089 sofia/external/********************** Set 2833 dtmf send payload to 101

this is what I'm seeing in the logs.
 

MaxBravo

Member
May 21, 2022
36
0
6
51
Can someone please help me here? I can't believe that our instance is the only one facing this issue.
 

markjcrane

Active Member
Staff member
Jul 22, 2018
447
162
43
49
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

Member
May 21, 2022
36
0
6
51
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

Active Member
Staff member
Jul 22, 2018
447
162
43
49
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

Member
May 21, 2022
36
0
6
51
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

Active Member
Jan 28, 2019
674
80
28
34
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

Member
May 21, 2022
36
0
6
51
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

Member
May 21, 2022
36
0
6
51
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

Member
May 21, 2022
36
0
6
51
It may be a SIP trunk issue, we use Twilio, as per their documentation,

Code:
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

Member
May 21, 2022
36
0
6
51
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

Member
May 21, 2022
36
0
6
51
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):
 

MaxBravo

Member
May 21, 2022
36
0
6
51
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

Active Member
Jan 28, 2019
674
80
28
34
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

Member
May 21, 2022
36
0
6
51
I think what you suggested checks out,

Old IVR before pulling the update

Code:
<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

Code:
<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

Member
May 21, 2022
36
0
6
51
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.
 
Last edited:

MaxBravo

Member
May 21, 2022
36
0
6
51
Here's something I see,

Working IVR, Call-direction is above 30

1679961429766.png

1679961615915.png

Not working IVR, Call-direction is 35

1679961740025.png

1679961827376.png

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

Member
May 21, 2022
36
0
6
51
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)
 
Status
Not open for further replies.