A customer with a 1A2 system with analog lines is looking to transition some of the analog lines to a cellphone using an Xlink bluetooth gateway.

The old analog lines use Viking AR-1 autoattendants, so I did a test inserting the Xlink cell gateway in front of the Viking unit and have it appear as one of the KSU lines, e.g:



Seems like remote callers (either cell or analog in origin) reach the Viking's autoattendant OK via the Xlink, but can't dial through the voice menu.. it's like the Viking unit isn't able to parse the touch tones coming through the Xlink properly.

I inserted a phone between the Xlink and the Viking just to hear the transaction, and I do hear the touch tones from the remote. So not sure if the Viking just isn't trying hard enough, or if the Xlink isn't reproducing the touch tones accurately enough.

Anyone ever run into this, or how to best debug?

I can just imagine opening a support issue with either Viking or Xlink; they'd probably blame each other, Xlink complaining about the Viking not being forgiving enough to parse the DTMF frequencies, and Viking complaining about the Xlink sound quality.

My guess is it's the Xlink not converting the remote touch tones to analog frequencies correctly, since I can dial the Viking unit over analog lines from a cell phone and navigate the voice menu just fine.

But not sure how exactly to prove the quality of the Xlink's cell-to-analog conversion is the real issue. I guess I could pull out my scope and try to monitor the DTMF frequencies.

Any advice would be helpful.

Insert a digit grabber between the gateway and the Viking unit to see what, if any digits are coming through. I would also check loop current as well. Too high and stuff burns up. Too low and things don't behave as we hope they should.

OK, I did some tests and I was wrong: the touch tones I heard were from the cell to the remote, but the remote phone could not dial DTMF tones and have them heard by the cell phone.. at all.

I was able to take the Xlink and the Viking units out of the equation completely, and found that just between the cell phone and a land line, the cellphone's touch tones /could/ be heard by the land line, but the land line generated tones were being removed from the voice call, presumably by the carrier.

So for instance if you have a cell phone and a land line, try calling the cell from your land line, and try generating touch tones from the land line and see if you hear the tones on your cell. In my tests the tones were magically deleted and could not be heard..! But vice versa worked fine.

My experiments seem to show the tones don't make it through; it's a one way problem, where the remote phone can't send touch tones to the cell.

I tried that test with two different cell phones each on different carriers -- same problem. My cell (on AT&T's cell network) talking to an analog line, and using my friend's cell (on Verizon's cell network) with the same behavior: Touch tones generated by the remote analog phone simply would not pass through to the cell phones.

I investigated this a bit, and I think it might get into the details of analog-to-digital encoding, where DTMF sequences are /parsed/ during analog-to-digital, sent as separate digital data representations of the tones, and those are RE-generated at the other end where digital is converted back to analog. This way the tones won't be mangled by audio compression, and transmit clearly over otherwise noisy or imperfect networks (such as wireless or VOIP/internet), by having the tones transmitted as more reliably as digital representations of the tones, and regenerated at the D->A end.

It seems like this is an "issue" with the carrier, or possibly the cell phones (not sure which). Either the carrier is "eating" the DTMF tones transmitting the digital representations but the cell is not converting those digital messages back into DTMF, or the carrier is eating the DTMF and NOT transmitting the digital representations, possibly parsing the tones for their own purposes. Either way, the tones are being removed from the voice circuit completely.

Anyway, my tests removed the Viking and Xlink equipment from the equation, making it clear it wasn't related at all to that equipment; the problem is the tones aren't making it through the phone connection.

I did a little sniffing around, and apparently to carry DTMF over digital networks (e.g. cell and VOIP), there's a protocol called RTP (Real Time Protocol, e.g. RFC-4733) that traffics voice data, and within that protocol, there's a special handling for "DTMF events", which to ensure DTMF survives intact over networks where the voice compression might be too high, it is instead *parsed* by the analog-to-digital equipment, converted into a separate digital representation of the DTMF digit, transmitted as a small digital data packet, and the audio frequencies are clipped out of the A-to-D conversion, and are converted back to audio at the D-to-A end of the connection, in this case presumably at the cell phone end of things.

So it seems clear that an analog line's DTMF tones are passed as audio over the analog circuit, but at the telco, when the sounds are converted to digital (for transmission over the cellular/wireless network), the tones are first recognized, converted to a digital representation of the DTMF digit, passed as a special RTP packet representation of that digit, and the tone "sound" is /not/ transmitted as a sound frequencies (i.e. clipped out of the analog conversion).

Then presumably at the other end, when the digital data is converted back to analog so as to be "heard" by the analog equipment (e.g. the speaker in your cell phone), the RTP digital version of the DTMF code is supposed to be "regenerated" and inserted back into the voice circuit, so as to be heard as very clear tones.

So the fact the tones aren't making it through from the remote phone to the cell phone, I'm not sure if the cell phone is simply not regenerating the RTP encoded digital version of the DTMF events, or if the cell service (e.g. AT&T) is simply capturing the DTMF events for itself (such as for remote access voice mail features, or to prevent the remote caller from accidentally accessing DTMF oriented features as a security measure).

Either way, this seems to be eclipsing the DTMF sounds from being "heard" by the Xlink, and Viking AutoAttendant.

So I'm not sure, but this actually sounds like it might be an issue for AT&T to weigh in on, or possibly the cellphone (Apple iphone).

Anyway, "ugh", I guess I should take this question now to a cell phone/VOIP oriented forum or take it to AT&T itself, it's not really a phone equipment problem.

Thanks for posting your findings!

Welcome to the wonderful world of CODEC (Code/Decode) data packets. RTP packets get used in lots of ways, especially with SIP circuits.It could be you're encountering a mismatch between the type of packet you're sending with the type of packet the cell provider will accept. Cell providers have probably reasoned that there would not really be a need for someone to remotely route a call through a cell phone, so accepting/reading DTMF tones was not considered useful.

What's interesting is it's a 2500 sending the tones over an analog AT&T line over to a cell phone on AT&T mobile. So I imagine the conversion to a DTMF RTP packet is done by AT&T when it hits the first A-D converter, and travels through the network as that.

What's not clear is if AT&T is picking the DTMF packet off for itself so that the phone never sees it, or if the phone is getting the packet but not converting it back into a tone.

I've opened a thread with AT&T support here:
https://forums.att.com/conversation...637a8?commentId=62b4c0224333500318b7f991

..waiting to see if that yields a solution.