audio quality suddenly degrades
Submitted by fredo on Mon, 08/04/2008 - 6:23pm.
I've seen this on a 480i and a 9133i now where the incoming audio suddenly degrades. It becomes hollow and electronic sounding. One of my users calls it robot voice. She's found that putting the call on hold momentarily and then picking it back up fixes it temporarily.
Has anyone else experienced this? I can't find anything in the forums that seems to relate.
I suspect the audio codec switching mid-call, but haven't had a chance to test that yet.
Same issue
Tue, 08/26/2008 - 8:32pm
I have the same issue with the same phones and frustratingly, no solution. Basic hardware is: Dell SC440 server w/ software RAID, 1 480i and 8 9133i phones, and 1 GXW4108. I'll have to post back with specifics, but I think the phones and the GXW4108 have the latest firmware (as of 1.4.2.3000 and 1.0.1.2? respectively (just before the site went to 'pending' on 1.0.1.8)). To get acceptable volume levels from PSTN, on the Grandstream "Tx to PSTN audio gain" is set to -1dB and "Rx from PSTN audio gain" to 3dB. -- I think this is related to 'robot voice' because we had issues previously when "Tx to PSTN" was amped to 2dB, and it created echo for the internal caller, usually when they spoke loudly -- And G711u is the specified codec for the GXW4108 and asterisk, but I'm not sure exactly how the Aastras pick it (should be default).
Also, occasionally callers hear a 'DTMF beep' in the middle of a conversation without anyone pressing a key on the phone. The Grandstream, all extensions, and the phones should be using RFC2833 to transmit DTMF.
Are these issues related? I'm wondering if its volume or codec related, or both. Having to have the volume cranked 3dB for incoming doesn't seem correct - especially because I have another installation with the same 4108 that has to be to the same level to get similar performance. But I don't know of any other way of increasing it (other than playing with handset volume levels), as internal calls are loud and clear. It would also be nice to know if Grandstream's new firmware addresses any audio quality/volume issues.
Anyone with info please?
I have 2 installs seeing
Wed, 08/27/2008 - 9:38pm
I have 2 installs seeing this issue. All units are updated to the latest firmware.
My configs are:
Location 1:
Dell Poweredge 2850, 1gig ram, scsi raid
TE110 T1 PCI card
TDM400 PCI card with 4 FXS modules
1 480i
30 GXP-2000
Location 2:
Asus RS120-E4 with Intel E4600 cpu, 2gig ram, sata raid
TDM400 PCI card with 4 fxo modules
10 9133i
BTW, the GXP200s on location 1 and at 4 other locations do not suffer from this problem. It's just the Aastra phones.
Interesting, at least I know
Tue, 09/02/2008 - 11:36am
Interesting, at least I know it's not the Grandstream FXO. Maybe downgrading the firmware on the phones? But I'm using the XML scripts package, and I don't know how far back that's supported.
That other installation of mine also has only GXP-2000s, and also does NOT have this issue.
Any word on the random DTMF tones? I'd like to know if they're related. Frequency-wise, both of these issues appear to happen maybe a couple times per week. (3 phone lines, between 5 and 20 calls per day, with about 8 users). Aastra's site does call the 1.4.2.3000 firmware a 'maintenance' release, so I wonder if going back to 1.4.2 would do anything. I'll try that next.
Does this only happen on
Tue, 09/02/2008 - 4:33pm
Does this only happen on calls through the PSTN or does it also happen on IP Phone to IP Phone calls? Trixbox by default will drop out of the audio patch for IP to IP calls, so this helps isolate where the problem is being introduced.
I'd suggest doing a packet capture on the trixbox server, capturing both the SIP messaging and RTP stream. With this capture you can use Wireshark to analyze what's going on, you can even get it to play back the call, if you are using uLaw or aLaw as your codec. The playback can tell you where the degradation is happening, ie if the RTP being sent to the phone is fine or is already degraded. Deeper analysis can show if there is a problem with the RTP stream, such as packet loss, jitter, etc.
It sounds like you guys are describing the same problem I had
Wed, 09/10/2008 - 3:35pm
What I found is that at times Asterisk was detecting something in the person's voice as DTMF (due to being just the right pitch, I guess) and then it was passing that through to my Aastra phones that were setup to use RFC2833, and for whatever reason they would then play the DTMF six times very quickly and then the call quality would instantly degrade. This happened only on my Aastra phones. After some trial-and-error testing, I managed to resolve this issue by changing the DTMF settings on all of my Aastra 480i phones. Here's what I did.
In FreePBX, for each of the extensions, set "dtmfmode" to "info".
In your aastra.cfg file, make sure you have the following two lines:
sip dtmf method: 1
sip out-of-band dtmf: 1
The "dtmf method: 1" sets the phones to use SIP info.
I've tested this on internal and external calls and DTMF sending and reception is working great. Hope this helps.
EDIT: I should add that I was able to reproduce this problem by making a call from my cell phone and answering it on an Aastra phone, then pressing a DTMF key on my cell phone. I would hear the DTMF on the Aastra six times, then "Mr. Roboto" voice as someone else called it. After making the changes above, I did the same test and had no problems. Heard the DTMF once as I should and no change in quality.
JayBoy,
Detecting "speech"
Wed, 09/10/2008 - 4:26pm
JayBoy,
Detecting "speech" as DTMF is surprising a common problem with poorly tuned devices. There should be some recommended detection algorithm settings to minimize this, but it varies from device to device. If you're interested do a search on "DTMF talk-off", and you'll come across an actual set of recordings that are normally used to test DTMF detectors.
Anyway, as for the second half of the problem - I'm not sure what's going on here; was there something in the RFC2833 messages being sent by the server that could be causing the problem? If you can get a capture of this happening, could you send it to me and I'll try and find some time to have a quick look? Or you can raise a ticket with support on this.
Yeah, the detection of
Wed, 09/10/2008 - 4:35pm
Yeah, the detection of speech as DTMF wasn't really surprising to me as it has always happened from time to time since I started using Asterisk. But the issue with DTMF causing the voice quality issue was something new that popped up a couple of months ago for me. When I was having this problem (with DTMF using RFC2833 instead of SIP Info), here's what was int he log:
[Aug 22 11:53:19] DTMF[3372]: channel.c:2191 __ast_read: DTMF begin '5' received on SIP/vitel-outbound-08edfb30
[Aug 22 11:53:19] DTMF[3372]: channel.c:2201 __ast_read: DTMF begin passthrough '5' on SIP/vitel-outbound-08edfb30
[Aug 22 11:53:19] DTMF[3372]: channel.c:2116 __ast_read: DTMF end '5' received on SIP/vitel-outbound-08edfb30, duration 100 ms
[Aug 22 11:53:19] DTMF[3372]: channel.c:2163 __ast_read: DTMF end accepted with begin '5' on SIP/vitel-outbound-08edfb30
[Aug 22 11:53:19] DTMF[3372]: channel.c:2179 __ast_read: DTMF end passthrough '5' on SIP/vitel-outbound-08edfb30
This was from a test I did using my cell phone. But it also happened on internal calls, and only on my Aastra 480i phones (it should be noted that the only Aastra phones I have are 480i's).
Same problem here with Robot voice on Aastra 480i CT
Wed, 09/17/2008 - 12:14pm
Until recently I had been running multiple Aastra 480i CT phones with not problems whatsoever. A change required by my voip provider (Voicepulse), resulted in the DTMF mode going to rfc2833 for both incoming and outgoing calls. Once this change had been made, the Aastra phones started the same Robotic behavior as described above. The call quality degraded to the point that the incoming audio could not be understood by the person at the Aastra end of the line. With that said, the problem does seem to be related to the DTMF.
After reading fredo's post, which mentioned putting the call on hold momentarily to restore quality audio, I tested this on my system, and it worked! At least I have a temporary workaround until this problem is fixed.
Gareth-has anyone gotten back to you regarding the wireshark capture? If not, then let me know exactly what you want, and I will get that done for you.
Brent
----Also, occasionally
Wed, 09/17/2008 - 1:03pm
----Also, occasionally callers hear a 'DTMF beep' in the middle of a conversation without anyone pressing a key on the phone. The Grandstream, all extensions, and the phones should be using RFC2833 to transmit DTMF.
This is one I'm currently chasing as well. It caught my eye because of the grandstream being mentioned however that seems to be ruled out. I'm using 55i phones and the users that complain about the occasional 'beeps' also happen to have their incoming DID via the grandstream FXO but they haven't confirmed if this happens on incoming (FXO) or outbound (IAX/SIP).
I too have an odd gain setting on the FXO. What works here seems to be +1 and +6.
So DTMF... very interesting.
hermansonb wrote:
Gareth-has
Wed, 09/17/2008 - 6:22pm
hermansonb wrote:
Gareth-has anyone gotten back to you regarding the wireshark capture?
No. What I need is an capture of the SIP and RTP traffic for the call that experiences the "robotic voice". This will enable me to try and figure out why you're hearing multiple DTMF beeps for a single DTMF press and also might give some clues to the cause of the robotic voice. PM me once you have the trace and I'll give you the details of where to email it.
Some additional questions for everyone:
- what codec(s) are you using?
- which end of the call experiences the "robotic voice"? The Aastra phone, the far-end or both?
- who has raised a ticket with Aastra support on this? Can those people PM me the case number - I'll check out system and try and correlate all the cases together.
Chiming in: I switched my
Wed, 09/17/2008 - 6:35pm
Chiming in: I switched my user to sip-info for DTMF and, so far, all the problems have cleared up.
As for the above questions, I can answer that only the aastra user hears the robotic voice. The other parties on the PSTN connection do not hear it.
I'm not sure what codec is being used as that is not an explicit definition in the phone. The Trixbox is using whatever is default. The phone only shows that the "Use basic codecs" is not checked.
The only change I have made is the switch from rfc2833 to sip-info for dtmf so, if you'd like screenshots of the phone's config pages, I can provide them (480i CT).
Sorry I wasn't able to provide a trace...
Wed, 09/17/2008 - 7:50pm
I had already changed my system over to using SIP INFO long before posting here and really don't want to make any more changes if I don't have to since it's now working for me. It sounds like someone who is still having issues will be able to do so, but if not, please let me know and I'll see what I can do.
When I was having problems, with DTMF set to RFC2833, the issue was as Fredo stated--only the Aastra user heard the "robotic voice." On my system I am using uLaw for the codec. I did not open a ticket with Aastra as I honestly thought that this probably had more to do with being some type of Asterisk issue as RFC2833 had always worked fine up until a system upgrade (which one, I'm not exactly sure as it took me a while to notice this problem). We also had a thread going about this on the PBX in a Flash forum about this issue, so it sounds like it's definitely not something trixbox-specific.
I had this problem as well
Thu, 10/30/2008 - 1:27pm
I had this problem as well and tried everything including posts but was not getting to far with it. I did find a solution that worked for me. What i did was change the "dtmfmode" located in the users extension and changed it to "inband". It has not broken anything else on the server yet and it has been about 3 months and no more "robot voice". Hope this helps.
Lenny C.
BTW. I could force the "robotic voice" simply by pressing any number on the keypad while talking on the phone. Also it is my understanding that certain high pitches would cause this to happen as well.
Member Since:
2006-06-08