Call waiting problems - extra noises

Ok, I've resisted for long enough. Gonna throw this out there for some group-think:

Ever since I signed on with VoIPo, I've had a very annoying problem with call waiting. When I'm on a call, and another caller dials-in (primary or virtual line), I get a 3-tone "squeal" followed by an audio drop, followed by the call waiting tone. This squeal tone(s) is injected at the very beginning of the call.

This problem is extant on both the HT502 and PAP2T. It does manifest in a slightly different way between the two ATAs. On the Grandstream, both I and the person calling me can hear the audio squeal. On the Linksys, only I can hear it. The other difference is that on the PAP2T, the order is: call waiting tone, 3-tone squeal, audio drop.

This happens on every phone I've tried, to varying degrees. Meaning, some phones manifest only one "squeal tone" (an old ATT slimline phone), or two (an older Panasonic KT-TC1868B).

My primary phone is a Uniden CLX485 with a couple of extra handsets.

All manner of network configurations have been tested: in front of router, behind router, in DMZ. No difference. All combinations of phones have been tried on the ATAs, no difference.

Been working on this with TierII support for a while, and we're stumped. The next thing I'm going to try is to take my ATA to another location, using a different ISP. In the meantime: has anyone had a similar problem? Any ideas on what might be causing this?

Extensive googling has revealed a couple of clues. Some folks have mentioned that this type of problem is noise being injected by caller id data. We have tried disabling incoming caller ID, that didn't make a difference.

I attached a file so you can listen to the squeal tones. Change the extension from .zip to .mp3 to listen to it. Any ideas are welcome at this point.

I heard it and it sounds strange.
I wonder if the ATA could even cause a problem like this.
It almost sounds as if there is another layer of something connecting after it passes some sort of call filter.

Have you checked that it's setup to use North American CWCID signaling (Bellcore GR-30-CORE)? I listened to the recording, and it didn't sound like the right sequence at all. I don't have something to play it slowly handy, but it sounds like the CW signaling is being interspersed with the audible ringback as your call is being connected. Does it sound the same during a normal conversation?
There's a great document that used to be floating around (http://www.testmark.com/develop/tml_callerid_cnt.html), but has gone dark. This document explains the whole process, including the ACK that the phone will send back if it has successfully muted the handset prior to the actual FSK (which may be the difference between your slimline and Panasonic sets).

Here's an excerpt:

Quote:

---

The sequence of events that displays the information about the caller begins when the central office temporarily removes the far end party of the current call and sends a Subscriber Alerting Signal (SAS) to the near end party. The SAS is a single frequency of 440 Hz that is applied for approximately 300 ms. This is the tone that is heard when a call is in progress and call waiting beeps to indicate a second call. The SAS tone is mainly for the user and is not required for the CPE to receive the CID information. The SAS tone is followed by a CAS to alert the CPE that it has CID information to send. The CAS is a dual tone signal combination of 2130 Hz and 2750 Hz that is 80 ms in length. Once the CPE hears the CAS it mutes the handset of the telephone and returns an ACK signal to the central office. This ACK signal has a nominal tone duration of 60 ms and is either a Dual-Tone Multifrequency (DTMF) "A" or a DTMF "D". The DTMF "D" is the most common ACK signal and it consists of the frequencies 941 Hz and 1633 Hz. A DTMF "A" consists of the frequencies 697 Hz and 1633 Hz. Once the central office receives the ACK signal it in turn sends the CID information[7][8][10]. The CPE un-mutes the handset as soon as it finishes receiving the FSK signal.

---

:D http://web.archive.org/web/200402140...lerid_cnt.html

chpalmer: Thanks for the link.

bwarden: I double-checked the settings in the PAP2T, and CID Method is set to Bellcore (N American). Caller ID FSK Standard is set to bell202.

Any other thoughts or ideas? I'm inclined to believe that the CID info is injecting voltage that's being passed from the ATA to the phones. How to filter it? That's the question...

Update: I've been playing with settings, and have determined that the extra tones ARE being caused by the CWCID. One of the PAP2T's settings allows you to turn off the call waiting caller id. Doing so makes the extra tones go away. The downside is obvious: no caller id for call waiting. :/

So...there's gotta be something that can be done server-side to fix this, right?...right??? :)

Quote:

---

Originally Posted by bretski

Update: I've been playing with settings, and have determined that the extra tones ARE being caused by the CWCID. One of the PAP2T's settings allows you to turn off the call waiting caller id. Doing so makes the extra tones go away. The downside is obvious: no caller id for call waiting. :/

So...there's gotta be something that can be done server-side to fix this, right?...right??? :)

---

Not sure if that's a correct assumption. Say your car is running ruff because you put cheap gas in it. All of a sudden it stops running bad when you put good gas in it, obviously not the cars fault. Just because you turn off the CWCID and it stops, doesn't necessarily mean it's the TA. It just passes the info that's sent to it.

But hey, I could be waaaaaay off ;)

Quote:

---

Originally Posted by Montano

Not sure if that's a correct assumption. Say your car is running ruff because you put cheap gas in it. All of a sudden it stops running bad when you put good gas in it, obviously not the cars fault. Just because you turn off the CWCID and it stops, doesn't necessarily mean it's the TA. It just passes the info that's sent to it.

But hey, I could be waaaaaay off ;)

---

I agree, it's not necessarily the ATA's fault. My point was: the extra tones are the CAS, SAS, ACK associated with CWCID.

...and, I never had this problem with POTS using these exact same phones. VoIP is the x-factor, and the ATA is a logical suspect (but not the only suspect, obviously).

Something I just found in a firmware release notes document for another Linksys device (resolved issues):

"CIDCW Ac digit (A or D) is sent out-of-band if the DTMF Tx Method is INFO. The symptom is that the other party may hear the ACK digit if the peer device plays out-of-band DTMF digits via a SIP INFO message"