Is it possible for talk-off to be triggered by a smart phone alert? If yes, is it possible that DTMF can accidentally mute a call?

[andys03]

My company sells/supports Allworx SIP PBXs. We have a weird edge case with one of our customers who uses PRI for dial-tone.  On outbound calls, if our user happens to receive an SMS on their iPhone, and the iPhone is set to play the default "note" tone, and the tone is loud enough to be heard over the handset or speakerphone, outbound voice is muted.  This is reproducible 100% of the time.  It only happens on outbound calls through the PRI, and only on the specific note alert tone.  If I route calls out their backup SIP trunks, it does not happen.

The PBX connects to the local Adtran using PRI.  The Adtran converts it to SIP and communicates with the 908 on the far side.

After a ton of research and arguing with the carrier (they believe it is a physical problem with the PRI card), I think the most likely answer is an iPhone alert causing talk-off triggering DTMF tones which triggers some sort of * code that mutes the call.  The PRI goes to a carrier-provided TA 900 (I forget which model) series which is talking to a 908. 

So, my questions are:

1.  I've experienced DTMF talk-off myself when talking to my wife on our cell phones, but is it possible for a specific smartphone alert to trigger talk-off?

2.  If yes, could one of the Adtrans (or anything upstream) have a feature enabled that lets DTMF mute the call?

[jayh]

It's possible. If so and it's reproducible you should see an NTE event in debug or with Wireshark if you're using RFC2833. This doesn't sound like talk-off however. If that were the case the audio would be replaced with a pure DTMF pair. I suppose that if the note tone were close enough to be interpreted as DTMF it could trigger an RFC2833 NTE event resulting in a pure DTMF digit being sent toward the receiving side. This then might cause the receiving device to take some action based on the digit. Typically with false RFC2833 one just hears a burst of DTMF as part of the speech and conversation continues.

Does the audio stay muted for the duration of the call or does it come back after a fraction of a second?

Can you configure the trunk between the two Adtrans to use G.711 with DTMF inband? This will rule out the possibility of the sending Adtran converting the note sound to a DTMF digit and passing it on as such to the receiving end.

The tone being interpreted as a SPRE command is unlikely as these are typically used as part of a call setup dial string and not in the middle of the call.

[andys03]

Thanks for the reply!

Unfortunately, I don't have access to the Adtrans as they are the carriers. 

I have finally convinced them that there is an issue and it isn't being caused by the PBX, but further testing is postponed due to the whole pandemic thing.

[jayh]

Does the audio stay muted for the duration of the call once the alert note sounds?

Does the PBX on the other side continuously listen for DTMF during a call? In other words, if you're talking and deliberately send *#1234567890 in the middle of a call does the other party just hear the digits in their ear or does something happen to the call? Most well-designed systems don't listen during a call other than during IVR sessions once the call is established in order to avoid talk-off.

I'd ask the carrier to option the trunks for G.711 with DTMF inband. This should allow DTMF to pass transparently with good fidelity and not be manipulated by the Adtran devices. Note that you need the G.711 codec for inband to work, otherwise the tones will be too distorted for regular dialing.

[andys03]

We have not found a way to un-mute the audio.

Regarding the other side's PBX, are you referring to the carrier or person being called?  If it is the latter, it happens universally, whether we are calling a cell phone, landline, SIP, etc.

I haven't tested the DTMF tones as unfortunately I"m quarantined and can't get back to my office where I have a test phone setup for at least another week.

[Anonymous]

I think another possibility for the behavior you're experiencing is that the carrier's device or their PSTN gateways upstream of the call of the CPE interpret the "in-band" SMS tone to be a T30 fax communication tone. If that were the case, the call is likely to get re-negotiated to another codec, such as G711 or T38. That could result in loss of upstream audio, if the inbound stream continues to be sent using the codec that was previously agreed upon -  G729, for example. This condition should be fairly easy to reproduce and troubleshoot, and something that the carrier should be able to see in the SIP debug logs of the CPE as well as using their packet inspection tools.

Hard setting the CPE to G711, as Jay mentioned, should fix the issue.