DTMF Tone on IOS 13 issue

This is a difficult issue to fix

• long tones get interpreted as multiple presses on some IVRs if the phone connection keeps dropping as you get sometimes when connecting to an overseas call centre and there is not enough bandwidth which gives you odd short periods of silence. This silence makes the IVR think you have pressed the key twice
• short tones may not be picked up reliably by an older IVR

I do not like lots of settings but perhaps a long, medium and short option for DTMF tone length so you can adjust as required.

JeremyLeeDiaz wrote:

It’s not something ANYONE cared about being changed.

That’s a rather large assertion.

i would bet someone did, in fact, care as engineers don’t usually change something like that on a whim.

In fact, it was likely because, as mentioned earlier, long tones often get interpreted as multiple tones due to cellular dropouts and perhaps due to DTMF regeneration along the line.

Do you have access to Apple internal marketing documents? If not, your assertions that "no one wanted" something is on its face absurd.

"No one wanted to lose fingerprint ID?" FaceID is much faster in most cases.

No one asked for a redesign for iOS? I'm more than sure Apple has a lot of feedback indicating people want changes to all sorts of things.

The headphone jack, really? The iPhone could not be the thickness it is had it continued with a bulky headphone jack, nor would it have received IP68 certification.

Choose to believe what you want, and I get your frustration.

All I can tell you is to make sure you voice your frustration directly to Apple here:

Feedback - iPhone - Apple

For those curious about just some of the issues surrounding how this works, it's discussed in RFC 4733; the basic summary is that the tones you generate may not even be transmitted directly to the remote end; many carriers will decode the tones on your end and pass them along as data, and the remote end will regenerate the tones in question:

1. The gateway or end system can change to a higher-bandwidth codec

such as G.711 [19] when tone signals are to be conveyed. See new

ITU-T Recommendation V.152 [26] for a formal treatment of this

approach. Alternatively, for fax, text, or modem signals

respectively, a specialized transport such as T.38 [23], RFC 4103

[15], or V.150.1 modem relay [25] may be used. Finally, 64

kbit/s channels may be carried transparently using the RFC 4040

Clearmode payload type [14]. These methods are out of scope of

the present document, but may be used along with the payload

types defined here.

2. The sending gateway can simply measure the frequency components

of the voice-band signals and transmit this information to the

RTP receiver using the tone representation defined in this

document (Section 4). In this mode, the gateway makes no attempt

to discern the meaning of the tones, but simply distinguishes

tones from speech signals. An end system may use the same

approach using configured rather than measured frequencies.

All tone signals in use in the PSTN and meant for human

consumption are sequences of simple combinations of sine waves,

either added or modulated. (However, some modem signals such as

the ANSam tone [24] or systems dependent on phase shift keying

cannot be conveyed so simply.)

3. As a third option, a sending gateway can recognize tones such as

ringing or busy tone or DTMF digit '0', and transmit a code that

identifies them using the telephone-event payload defined in this

document (Section 2). The receiver then produces a tone signal

or other indication appropriate to the signal. Generally, since

the recognition of signals at the sender often depends on their

on/off pattern or the sequence of several tones, this recognition

can take several seconds. On the other hand, the gateway may

have access to the actual signalling information that generates

the tones and thus can generate the RTP packet immediately,

without the detour through acoustic signals.

RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals

I am also having the DTMF problem with IOS 14.2. Your response indicates that COMCAST, the nation's LARGEST internet provider, does not have properly designed IVR equipment. When Comcast calls me back to ask if the internet is working properly, they insist that I input a "1" or a "2" for yes or no. I cannot give an answer because apparently the DTMF tones are too short for Comcast to recognize. HEY APPLE! Get real. Add a few milliseconds to the DTMF tone length and make the iPhone act like a phone.

Where it involves iPhones, an Android device will work : and vice versa

A fraction could also be carrier related. So now the question is : Why does it seem to happen since iOS 13 ?

I my experience the last time this happened it involved one particular IVR and none of the iPhones worked when all tested Androids did the job. (2 of both)

To echo Jeremy, we are a 5 (multiple generation) iPhone household. All devices are ATT. The 3 devices that are generation 8 and below all work fine. The 2 newer ones all 10 and above have dtmf issues with IVRs, security gate access etc. I have dialed multiple voice platforms, IVRs, and/or answered multiple security gate calls with each. The 3 older models work every time. The newer models NEVER work.

That's what I noticed too and it seems that also some Android smartphones brands experience the same behavior. (2 simple keywords in search engines leads to similar situations.)

A customer has an iPhone 12 and the issue occurs with a brand tech support only and when I crosschecked with my own iPhone SE (1st generation SW 14.2) I obtained the same outcome while Android phones worked.

So I think there's 3 parts : device DTMF specs --> carrier translation --> IVR

What a mess... As often Apple takes the hits probably because all others brands tech support don't give a sh..

Not for standards-compliant tone recognition systems, it's not, that's the problem.

There are standards around tone length that some vendors ignored.

Since the current version of iOS is iOS 14, what iOS 12 did or didn't do is of no consequence.

This is very likely due to LTE and DTMF regeneration on the part of your carrier.

Read my post above.

This is not a very good solution to this issue.

Things work fine before iOS13. long tones worked during a call.

After the update to iOS13 they no longer work. To say that a system is not properly designed and that's the fix is passing the buck. The issue is with iOS13 period!

I agree that something must be done. For 12 years my alarm system worked perfectly using # for communicating with it. Now I have changed unto a iPhone 8 and iPhone SE both with IOS 13.1.2 the # key has no effect what so ever.

Turning the VoLTE off fixed the issue for you? For about 6-8 weeks now I haven’t been able to receive 3rd party calls that I need to press 0 to accept and I’m ready to pull my hair out. Was on the phone with technical support for 2.5 hours today and they couldn’t tell me anything!

Either way we should have the choice as users to select whether we can use long or short tones because there’s always going to be places out there that cannot register the short tones especially when for example while using tones in when you’re trying to listen to your bank account. That can’t be helped.

I have a post a made about this too. My test involved using bluetooth headsets vs. nonbluetooth, and disbabling wireless calling (T-Mobile) It worked on some headsets but not others with wireless calling enabled (I do not know how audio routing in the iphone works, or if a headset could have a positive effect on wireless calling)

Thank you

Because transmission of long continuous tones is definitely not cellular phones' area of expertise.

Not only are long tones likely to be split up by the packetization and dropouts, some networks even go so far as to recognize DTMF tones and regnerate them on the remote end.