OK, background/config. running * (show version reports 0.9.0) on Mandrake 9.2 (kernel: 2.4.22-32mdk) with a dual 800mhz PIII with 256M Ram 4port FXO digium card, no IRQ sharing I can find (cat /proc/pci & cat /proc/interrupts), vmstat reports a minimum of 80+% CPU idle when problem occurs. connect to a Grandstream 101 (GS) via vpn (no nat). Link has 100ms - 150ms ROUND TRIP latency (constant 'ping' during test). Codec is alaw or ulaw. TDM card is plugged to an NEC PBX (old NEAX 2000 IVS) via the analog station card in the PBX. PROBLEM: Establish a call from the GS to an NEC phone (Dterm III) connected to the PBX. The voice quality on the GS sounds good. The voice quality on the NEC gets very choppy (random). A call from the same GS to an internal GS here (same latency, same IP path) is much better (some chop). SOLUTIONS tried to date: Tried a local network test, sound excellent. Tried a 'low latency vpn' test bed to reduce latency (is latency the issue?). Latency down to ~70ms round trip, better but still noticeably choppy. Tried different codecs (ulaw, alaw, iLBC), no impact. Tried various echo cancel/train on/off values, cancel and train on seem best. Tried modifing Samples/TX packet changes, 2 and 64 tried as 'ends of spectrum' values. little noticable impact (2 seems marginally better, still clips, MAY be less often). Tried changing TXgain and RXgain under the assumption audio level clipping occurs between tdm and NEC, some improvement. Substituted an SJPhone on a PC instead of the GS, better, still choppy. Tried the 'demo speech' on an extension, called from Dterm, sound is excellent, tried GS over low latency vpn, choppy, tried SJ over low latency vpn, choppy. (hmmmm, does that eliminate the tdm to NEC link as an issue?) Tried internal GS over low latency vpn to SJ (out thru vpn to * back thru vpn to sj), choppy. Current state: I've improved from 'crappy cell call about to disconnect' to 'average to crappy cell call' quality. Not exactly ready for customer use. ASSUMPTIONS: Original assumption was latency, but latency was still below the '150MS one way' values I see quoted for good sound quality. In fact over the low latency vpn the values were less than a third the quoted value. Sometimes I get a high latency and get a drop out, OK expected. Sometimes I get chop at a lower latency than I was getting with 'good' sound. Second assumption was interface between NEC and TDM was clipping, after changes to tx/rx gain the 'demo' speech sounds fine on the Dterm. (Does this remove the interface from the possible bad guys list?) HELP Needed: So given that latency is in the 70 - 100 ms round trip. Given that I've diddled rx/tx gain. Given that I've tried basic echo on/off settings. What's next? Is the 'common' 150 ms one way (150+ms round trip) value a bunch of crap? Do I need some other magic latency goal? Would a 729 codec help? Is there a test I missed? Some other values to twiddle? Is this a 'known issue' I don't know about, fixed in some more recent version? (Yeah, I can just try the CVS-HEAD and hope to get lucky and I probably will as I'm out of options/ideas but KNOWING it is fixed is better than hoping it is fixed) I'm stuck and my forehead is getting flat from pounding it on the wall. Anyone handing out clues? -- Dana Nowell Cornerstone Software Inc. Voice: 603-595-7480 Fax: 603-882-7313 email: DanaNowell_at_CornerstoneSoftware.com
Nearly everyone of my clients is between 600 and 700 ms and there is no choppyness to the calls. They are on VSAT uplinks with SCPC return channels, but I would say that latency is certainly not your problem. -----Original Message----- From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users-admin@lists.digium.com] On Behalf Of Dana Nowell Sent: Friday, August 13, 2004 2:22 PM To: asterisk-users@lists.digium.com Subject: [Asterisk-Users] voice choppy OK, background/config. running * (show version reports 0.9.0) on Mandrake 9.2 (kernel: 2.4.22-32mdk) with a dual 800mhz PIII with 256M Ram 4port FXO digium card, no IRQ sharing I can find (cat /proc/pci & cat /proc/interrupts), vmstat reports a minimum of 80+% CPU idle when problem occurs. connect to a Grandstream 101 (GS) via vpn (no nat). Link has 100ms - 150ms ROUND TRIP latency (constant 'ping' during test). Codec is alaw or ulaw. TDM card is plugged to an NEC PBX (old NEAX 2000 IVS) via the analog station card in the PBX. PROBLEM: Establish a call from the GS to an NEC phone (Dterm III) connected to the PBX. The voice quality on the GS sounds good. The voice quality on the NEC gets very choppy (random). A call from the same GS to an internal GS here (same latency, same IP path) is much better (some chop). SOLUTIONS tried to date: Tried a local network test, sound excellent. Tried a 'low latency vpn' test bed to reduce latency (is latency the issue?). Latency down to ~70ms round trip, better but still noticeably choppy. Tried different codecs (ulaw, alaw, iLBC), no impact. Tried various echo cancel/train on/off values, cancel and train on seem best. Tried modifing Samples/TX packet changes, 2 and 64 tried as 'ends of spectrum' values. little noticable impact (2 seems marginally better, still clips, MAY be less often). Tried changing TXgain and RXgain under the assumption audio level clipping occurs between tdm and NEC, some improvement. Substituted an SJPhone on a PC instead of the GS, better, still choppy. Tried the 'demo speech' on an extension, called from Dterm, sound is excellent, tried GS over low latency vpn, choppy, tried SJ over low latency vpn, choppy. (hmmmm, does that eliminate the tdm to NEC link as an issue?) Tried internal GS over low latency vpn to SJ (out thru vpn to * back thru vpn to sj), choppy. Current state: I've improved from 'crappy cell call about to disconnect' to 'average to crappy cell call' quality. Not exactly ready for customer use. ASSUMPTIONS: Original assumption was latency, but latency was still below the '150MS one way' values I see quoted for good sound quality. In fact over the low latency vpn the values were less than a third the quoted value. Sometimes I get a high latency and get a drop out, OK expected. Sometimes I get chop at a lower latency than I was getting with 'good' sound. Second assumption was interface between NEC and TDM was clipping, after changes to tx/rx gain the 'demo' speech sounds fine on the Dterm. (Does this remove the interface from the possible bad guys list?) HELP Needed: So given that latency is in the 70 - 100 ms round trip. Given that I've diddled rx/tx gain. Given that I've tried basic echo on/off settings. What's next? Is the 'common' 150 ms one way (150+ms round trip) value a bunch of crap? Do I need some other magic latency goal? Would a 729 codec help? Is there a test I missed? Some other values to twiddle? Is this a 'known issue' I don't know about, fixed in some more recent version? (Yeah, I can just try the CVS-HEAD and hope to get lucky and I probably will as I'm out of options/ideas but KNOWING it is fixed is better than hoping it is fixed) I'm stuck and my forehead is getting flat from pounding it on the wall. Anyone handing out clues? -- Dana Nowell Cornerstone Software Inc. Voice: 603-595-7480 Fax: 603-882-7313 email: DanaNowell_at_CornerstoneSoftware.com _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
You need to narrow down the cause, seeing as you tried across a local network and it sounded "excellent", I would start looking at your remote network connection. Things to try: - Try not using the VPN, I've heard reports that some VPNs cause major issues with VOIP. I'm not 100% why, but its worth a try turning off the VPN to see if that helps. - I'm not sure if this applies in your case, but make sure silence suppression is DISABLED on your phones. - Grab the latest version of "mtr" (http://www.bitwizard.nl/mtr/) , and run traceroutes between all end points with it. While the traceroute is running, hit "j" so it shows you the jitter information. High latencies don't usually degrade _sound_ quality of a call, however it severely degrades _call_ quality. Anything over 300ms round trip really starts to hurt the call quality, but all that really happens is both parties start to talk over one another. You don't normally get "chop". Round trip latencies below 100ms I would consider excellent, and virtually unnoticeable during normal conversations. If the chop is related to the network quality, its usually due to packet loss, or jitter. "mtr" is a great tool for this type of network diagnostics. Hopefully this helps, good luck. On Fri, 2004-08-13 at 14:21 -0400, Dana Nowell wrote:> OK, background/config. > > running * (show version reports 0.9.0) on Mandrake 9.2 (kernel: > 2.4.22-32mdk) with a dual 800mhz PIII with 256M Ram 4port FXO digium card, > no IRQ sharing I can find (cat /proc/pci & cat /proc/interrupts), vmstat > reports a minimum of 80+% CPU idle when problem occurs. > > connect to a Grandstream 101 (GS) via vpn (no nat). Link has 100ms - 150ms > ROUND TRIP latency (constant 'ping' during test). Codec is alaw or ulaw. > TDM card is plugged to an NEC PBX (old NEAX 2000 IVS) via the analog > station card in the PBX. > > PROBLEM: > Establish a call from the GS to an NEC phone (Dterm III) connected to the > PBX. The voice quality on the GS sounds good. The voice quality on the > NEC gets very choppy (random). A call from the same GS to an internal GS > here (same latency, same IP path) is much better (some chop). > > SOLUTIONS tried to date: > Tried a local network test, sound excellent. > > Tried a 'low latency vpn' test bed to reduce latency (is latency the > issue?). Latency down to ~70ms round trip, better but still noticeably > choppy. > > Tried different codecs (ulaw, alaw, iLBC), no impact. > > Tried various echo cancel/train on/off values, cancel and train on seem best. > > Tried modifing Samples/TX packet changes, 2 and 64 tried as 'ends of > spectrum' values. little noticable impact (2 seems marginally better, > still clips, MAY be less often). > > Tried changing TXgain and RXgain under the assumption audio level clipping > occurs between tdm and NEC, some improvement. > > Substituted an SJPhone on a PC instead of the GS, better, still choppy. > > Tried the 'demo speech' on an extension, called from Dterm, sound is > excellent, tried GS over low latency vpn, choppy, tried SJ over low latency > vpn, choppy. (hmmmm, does that eliminate the tdm to NEC link as an issue?) > > Tried internal GS over low latency vpn to SJ (out thru vpn to * back thru > vpn to sj), choppy. > > Current state: > I've improved from 'crappy cell call about to disconnect' to 'average to > crappy cell call' quality. Not exactly ready for customer use. > > ASSUMPTIONS: > Original assumption was latency, but latency was still below the '150MS one > way' values I see quoted for good sound quality. In fact over the low > latency vpn the values were less than a third the quoted value. Sometimes > I get a high latency and get a drop out, OK expected. Sometimes I get chop > at a lower latency than I was getting with 'good' sound. > > Second assumption was interface between NEC and TDM was clipping, after > changes to tx/rx gain the 'demo' speech sounds fine on the Dterm. (Does > this remove the interface from the possible bad guys list?) > > HELP Needed: > So given that latency is in the 70 - 100 ms round trip. Given that I've > diddled rx/tx gain. Given that I've tried basic echo on/off settings. > What's next? > > Is the 'common' 150 ms one way (150+ms round trip) value a bunch of crap? > Do I need some other magic latency goal? > > Would a 729 codec help? > > Is there a test I missed? Some other values to twiddle? > > Is this a 'known issue' I don't know about, fixed in some more recent > version? (Yeah, I can just try the CVS-HEAD and hope to get lucky and I > probably will as I'm out of options/ideas but KNOWING it is fixed is better > than hoping it is fixed) > > I'm stuck and my forehead is getting flat from pounding it on the wall. > Anyone handing out clues? > > >-- Mike Benoit <ipso@snappymail.ca>
At 01:01 PM 8/13/2004 -0700, Mike Benoit wrote:>You need to narrow down the cause, seeing as you tried across a local >network and it sounded "excellent", I would start looking at your remote >network connection. > >Things to try: > >- Try not using the VPN, I've heard reports that some VPNs cause major >issues with VOIP. I'm not 100% why, but its worth a try turning off the >VPN to see if that helps. >OK, I can try that over the 'low latency' vpn. The other end of the production VPN is a couple thousand miles from here and my arm is a bit short to keep swapping cables around :-).>- I'm not sure if this applies in your case, but make sure silence >suppression is DISABLED on your phones.Yeah, it is disabled. I should have included that in the config info, sorry.> >- Grab the latest version of "mtr" (http://www.bitwizard.nl/mtr/) , and >run traceroutes between all end points with it. While the traceroute is >running, hit "j" so it shows you the jitter information. High latencies >don't usually degrade _sound_ quality of a call, however it severely >degrades _call_ quality. Anything over 300ms round trip really starts to >hurt the call quality, but all that really happens is both parties start >to talk over one another. You don't normally get "chop". Round trip >latencies below 100ms I would consider excellent, and virtually >unnoticeable during normal conversations.downloading now.> >If the chop is related to the network quality, its usually due to packet >loss, or jitter. "mtr" is a great tool for this type of network >diagnostics. >doesn't APPEAR to be loss (no 'ping' losses during the test period). OK, if not network latency/loss/quality issues, not shared IRQ issues, not cpu loading issues, and not audio level clipping between the PBX and TDM, have you got any other ideas where to look (I'll check jitter)?> >Hopefully this helps, good luck. >Yeah thanks, at least now I can look at jitter, it beats being stuck. If you think of anything else ...> > >On Fri, 2004-08-13 at 14:21 -0400, Dana Nowell wrote: >> OK, background/config. >> >> running * (show version reports 0.9.0) on Mandrake 9.2 (kernel: >> 2.4.22-32mdk) with a dual 800mhz PIII with 256M Ram 4port FXO digium card, >> no IRQ sharing I can find (cat /proc/pci & cat /proc/interrupts), vmstat >> reports a minimum of 80+% CPU idle when problem occurs. >> >> connect to a Grandstream 101 (GS) via vpn (no nat). Link has 100ms - 150ms >> ROUND TRIP latency (constant 'ping' during test). Codec is alaw or ulaw. >> TDM card is plugged to an NEC PBX (old NEAX 2000 IVS) via the analog >> station card in the PBX. >> >> PROBLEM: >> Establish a call from the GS to an NEC phone (Dterm III) connected to the >> PBX. The voice quality on the GS sounds good. The voice quality on the >> NEC gets very choppy (random). A call from the same GS to an internal GS >> here (same latency, same IP path) is much better (some chop). >> >> SOLUTIONS tried to date: >> Tried a local network test, sound excellent. >> >> Tried a 'low latency vpn' test bed to reduce latency (is latency the >> issue?). Latency down to ~70ms round trip, better but still noticeably >> choppy. >> >> Tried different codecs (ulaw, alaw, iLBC), no impact. >> >> Tried various echo cancel/train on/off values, cancel and train on seembest.>> >> Tried modifing Samples/TX packet changes, 2 and 64 tried as 'ends of >> spectrum' values. little noticable impact (2 seems marginally better, >> still clips, MAY be less often). >> >> Tried changing TXgain and RXgain under the assumption audio level clipping >> occurs between tdm and NEC, some improvement. >> >> Substituted an SJPhone on a PC instead of the GS, better, still choppy. >> >> Tried the 'demo speech' on an extension, called from Dterm, sound is >> excellent, tried GS over low latency vpn, choppy, tried SJ over low latency >> vpn, choppy. (hmmmm, does that eliminate the tdm to NEC link as an issue?) >> >> Tried internal GS over low latency vpn to SJ (out thru vpn to * back thru >> vpn to sj), choppy. >> >> Current state: >> I've improved from 'crappy cell call about to disconnect' to 'average to >> crappy cell call' quality. Not exactly ready for customer use. >> >> ASSUMPTIONS: >> Original assumption was latency, but latency was still below the '150MS one >> way' values I see quoted for good sound quality. In fact over the low >> latency vpn the values were less than a third the quoted value. Sometimes >> I get a high latency and get a drop out, OK expected. Sometimes I get chop >> at a lower latency than I was getting with 'good' sound. >> >> Second assumption was interface between NEC and TDM was clipping, after >> changes to tx/rx gain the 'demo' speech sounds fine on the Dterm. (Does >> this remove the interface from the possible bad guys list?) >> >> HELP Needed: >> So given that latency is in the 70 - 100 ms round trip. Given that I've >> diddled rx/tx gain. Given that I've tried basic echo on/off settings. >> What's next? >> >> Is the 'common' 150 ms one way (150+ms round trip) value a bunch of crap? >> Do I need some other magic latency goal? >> >> Would a 729 codec help? >> >> Is there a test I missed? Some other values to twiddle? >> >> Is this a 'known issue' I don't know about, fixed in some more recent >> version? (Yeah, I can just try the CVS-HEAD and hope to get lucky and I >> probably will as I'm out of options/ideas but KNOWING it is fixed is better >> than hoping it is fixed) >> >> I'm stuck and my forehead is getting flat from pounding it on the wall. >> Anyone handing out clues? >>-- Dana Nowell Cornerstone Software Inc. Voice: 603-595-7480 Fax: 603-882-7313 email: DanaNowell_at_CornerstoneSoftware.com