Problem passing DTMF after upgrading to 16.4

Hi,

We have an app passing digits once connected to the PBX. We are simply dialing (***) ***-xxxx, yyy. After upgrading to Rls 16.4 PBX is no longer correctly decoding "yyy" digits represented by DTMF. If we press digits manually it works correctly, which leads us to conclude, Rls 16.4 sends to short DTMF. Upgrade to 16.4.1 didn't fix that bug.

Peter

which leads us to conclude, Rls 16.4 sends to short DTMF.

It sounds like you’re trying to file a bug report, in which case see tip 1 in Quinn’s Top Ten DevForums Tips.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you.

Did you file a bug report? We are experiencing the exact same issue.

We reported the same thing to APPLE earlier in the week. Add the number below to your phone dialer and call it. Turn on the speaker and listen to the numbers its trying to dial.

631-791-8378,,,#,2,3121#

It's attempting to dial 31121

We reported the same thing to Apple earlier in the week.

What was the bug number?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am also noticing the issue is specifically with DTMF tone duration. The PBX thinks the device is sending multiple DTMF tones instead of a single tone. So taking your example of 3121 we are seeing 33311222111. DTMF tones have specifications for duration and space (silence) in milliseconds so something must have been introduced that caused these tones to be generated with incorrect durations or the generation is being interrupted just long enough to introduce some silence for it to appear as multiple tones to the receiving device.

If you enter a comma in between every single tone, like 3,1,2,1 it works correctly but this significantly increase the dial time.

This could affect all "Tap to join" meeting invitations from Zoom, Google Meet, etc., that provide a single phone number and access code to join a meeting.

Are you trying to send DTMF codes via an encoded URL (e.g. 'tel:+123456%3B789%23'), if so can you try removing the encoding for the comma and pound so it looks like 'tel:+123456,789#' - that may fix this.

I'm NOT sure if this recent release of 16.4.1 (a) is a fix for this issue, BUT i've downloaded the VSR on two iPhones and it won't install. It reads "Unable to Verify Security Response. IOS Securith Response 16.4.1 (a) failed verification because you are no longer connected to the internet."

Any update from Apple on the following???

Any update from Apple on the following???

DevForums is not an official Apple support channel. For this and other tidbits about DevForums, see Quinn’s Top Ten DevForums Tips.

If you want to get this on to Apple’s Radar officially, you need to file a bug report about it. Please post your bug number here, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Filed bug as advised Developer Technical Support @ Apple. Here is the bug link - https://feedbackassistant.apple.com/feedback/12164493

I just started receiving reports of users of my app having this problem (phone extension not working) but I could not replicate it when I was on 16.1.1. I upgraded to 16.4.1 and now it seems like the recipient is never receiving the digits after the comma even though I can hear them being dialed. If I dial the extension manually it works fine, speed and timing of dialing the digits doesn't seem to be a factor either.

I am on 16.4.1(a), on xfinity with an iphone se 2. I have a coworker who is also on 16.4.1(a), with an iphone 14 pro on tmobile who is not experiencing this problem.

I did file a bug for this

Never got a response on my bug ticket, but it appears this issue is fixed in 16.5. After installing it I no longer have this problem, and I have two coworkers who were affected who report the same.

IOS 16.7.7 the issue is still here.

Problem passing DTMF after upgrading to 16.4
 
 
Q