Phone Systems

Sponsored by Atcom
Get a free phone!
Previous Thread
Next Thread
Print Thread
Rate Thread
Joined: Jan 2008
Posts: 76
Likes: 3
Member
OP Offline
Member
Joined: Jan 2008
Posts: 76
Likes: 3
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:

[Linked Image from seriss.com]

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.

Last edited by Greg Ercolano; 06/22/22 01:10 AM. Reason: Small clarifications
Atcom VoIP Demo
Get a VoIP Demo Today
Joined: Aug 2006
Posts: 1,745
Likes: 5
Moderator-Iwatsu
*****
Online Happy
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,745
Likes: 5
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.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Jan 2008
Posts: 76
Likes: 3
Member
OP Offline
Member
Joined: Jan 2008
Posts: 76
Likes: 3
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.

Last edited by Greg Ercolano; 06/23/22 12:24 AM. Reason: Clarifications
Joined: Jan 2008
Posts: 76
Likes: 3
Member
OP Offline
Member
Joined: Jan 2008
Posts: 76
Likes: 3
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.

Last edited by Greg Ercolano; 06/23/22 12:44 AM. Reason: Clarifications
Joined: Aug 2004
Posts: 1,397
Likes: 10
Admin
*****
Offline
Admin
*****
Joined: Aug 2004
Posts: 1,397
Likes: 10
Thanks for posting your findings!

Joined: Aug 2006
Posts: 1,745
Likes: 5
Moderator-Iwatsu
*****
Online Happy
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,745
Likes: 5
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.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Jan 2008
Posts: 76
Likes: 3
Member
OP Offline
Member
Joined: Jan 2008
Posts: 76
Likes: 3
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.


Link Copied to Clipboard
Forum Statistics
Forums84
Topics93,579
Posts635,607
Members49,577
Most Online5,661
May 23rd, 2018
Popular Topics(Views)
Today's Birthdays
Ashley, Bob Truitt, JALinker, Leeb
Newest Members
chyc, LostieWitness, djringjr, ScottRSA, Adam B
49,577 Registered Users
Top Posters(30 Days)
Toner 17
bobw 11
dexman 6
Who's Online Now
4 members (nameless, JBean3329, Coral Tech, jeffmoss26), 18 guests, and 11 robots.
Key: Admin, Global Mod, Mod
Contact Us | Sponsored by Atcom: Best VoIP Phones | Terms of Service

Sundance Communications is not affiliated with any of the above manufacturers.
©Copyright Sundance Communications 1998-2022
Powered by UBB.threads™ PHP Forum Software 7.7.5