Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

G.711 sampling rate & jitter with the 6608 blade

We are continuing to have echo issues at a customer site and have gone through the steps Cisco recommends for troubleshooting echo. Our padding/ERL levels on the 6608 gateway look good. The echo is not reproducible and happens sporadically - but to enough users that it continues to be an issue. We have yet to put an external echo canceler on (@ 128ms) - that is the next step. We have 64ms currently configured.

We changed the G.711 sampling rate (at the recommendations of our local Cisco SE) from 20ms to 10ms. In phone calls made after this change, we had max jitter rates of 60ms on some calls - and had people comment on how "bad" I sounded during parts of the call. This hadn't happened with a sampling rate of 20ms. Before the sampling rate change, it seemed that the max jitter value hadn't really been above 22-23ms, but it isn't something we were actively monitoring.

This seems to only apply to calls going through the gateway, not internal IP phone to IP phone calls.

We have put the sampling rate value back to 20ms. Max jitter values on the phones have still spiked to 40 to 50. No one has complained about bad quality calls on the phone I was using since then.

We are planning to change the max jitter buffer on the 6608 blade to 200ms from 150ms and then change back the value of the sampling rate to 10ms.

Is there any documented (or possible) correlation of increased jitter and call quality issues with a change in sampling rate? Is there a way to trace with the 6608 blade (port span of some sort) or some other feature that can pinpoint if the 6608 blade is causing a problem?

3 REPLIES
Gold

Re: G.711 sampling rate & jitter with the 6608 blade

I'm assuming you're adjusting the preferred G.711 packet size global system parameter. It's difficult to say what would be causing your increased jitter, not knowing more about your network. You don't mention if the call crosses a WAN, what sort of QoS is set up, etc. The only thing about a smaller packet size that would inherently have an effect on max jitter is the fact that you're doubling the number and rate of packets, and this increases the probability you will get the occasional "wild" sample. I would expect average jitter to be about the same, and average jitter along with packet loss would be a better set of measurements to be looking at anyway.

If you want to pursue that angle and adjust the 6608's playout buffer, you should adjust the minimum playout buffer size as well as the maximum. A setting around 60ms is often helpful in resolving jitter-induced audio quality issues.

As for the actual problem: packet size should have no effect on echo. It doesn't change the way voice is sampled from gateways or phones, nor does it change the way it is played back: it only changes the packaging on the IP network. There's almost no reason to change this parameter except for the occasional compatibility issue with other voice over IP systems.

You mention that you have a 6608 blade and you also mention you have the max tail length set at 64ms. This implies you have CallManager 3.3(3)sr2 or better with the G.168 echo canceller code it brings to the 6608 device loads (earlier code only went to 32ms). This code usually does a reasonable job of killing echo.

There are a few reasons why the G.168 (or other) ECAN might not work. Most commonly the echo is too long or too loud. A long echo means the echo returns after the max tail length the ECAN can memorize. Assuming mostly local or domestic LD calls, 'long' echo is rarely an issue. If this happens mostly on international calls or you have other reason to suspect long tail lengths, an external echo canceller such as those from Ditech (http://www.ditechcom.com) can cancel up to 192ms tails. Loud echoes, those above the 6dB attenuation level the ECAN expects to see by default, are sometimes an issue. You can now adjust this on the 6608 all the way up to 0dB. This might be worth trying.

Usually echoes are the result of electrical issues. There is such a thing as 'acoustic echo', which is mainly an issue with cheap headsets and the like where the earphone/speaker feeds back into the microphone. This is sometimes hard to eliminate but the Ditech external ECANs are supposed to have code that can do it. I'm not sure how well the 6608 alone does in this situation. If this were the case in your situation, I would expect it to be more replicable and happen to the same set of destinations all the time.

Here's one I learned from hard personal experience. Look for clock slips or other incorrect circuit timing configuration on the T1/PRI circuits feeding your 6608. I had a customer with a misprovisioned T3 mux dropping PRIs to their 6608 and they had no end of echo issues. The symptom was that they would hear bursts of echo every 20-60 seconds but it would only last a second or two. We couldn't kill it, even with external Ditech ECANs set to their most aggressive mode. We found slipping to be occuring inside the mux that we didn't see on the T1 circuit itself from the 6608. The mux was either inserting or dropping bits from the T1 to make up for the slippage, which subtly changed the apparent PSTN tail length now and then, and the ECANs had to reconverge on the echo every time this happened. It was quite difficult to replicate, and it took quite some time to track down.

There is a document here:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801115ed.shtml

which recommends attenuating the audio signal, which may render the echo inaudible. This may or may not help. The document also shows how to see the ACOM and ERL levels for a given call, which may help you in your troubleshooting.

There is a tool called 'Dick Tracy' used for tracing and debugging on the 6608 blade. It's usable both as a Windows-based GUI application and from the GUI on CatOS. Its use is not intuitive and is not documented anywhere on CCO. The only publicly available documentation that I know of is in the book 'Troubleshooting Cisco IP Telephony' from Cisco Press, ISBN 1-58705-075-7. The GUI application is not publicly available, but there are instructions for obtaining it in the book and you can do most everything from the CatOS CLI. However, neither the GUI nor the CLI version is going to do much to help you isolate an echo issue. The book does have some other good resources on echo troubleshooting, though.

If you haven't contacted TAC already, you should, as they may be able to guide you to other resources that can help. Hope this helps!

New Member

Re: G.711 sampling rate & jitter with the 6608 blade

I was referring to the global parameter. The playout buffer was already configured to 60ms. Found out that the 6608 blade cannot do 200ms max jitter buffer - only 150ms.

We are running CM 3.3(2) and will be upgrading shortly to 3.3(3). We have two Ditech ecans (we have two T1s) and they are configured for 128ms (currently cannot do 192ms) and at worst-case ERL @ 6db. I am configuring 0db tomorrow evening. For the most part, ERL levels on the blade are from 120 to 450. I am going to be playing with Dick Tracy tomorrow night. We have been told that it is okay to have both the Ditech and the 6608 cancelling .... 128ms for Ditech and 64ms for 6608 ..... any comments?

We had the T1s checked before Christmas and they are perfect - no slippage and the waveform was well within spec. They are also not padding the signal.

We still have complaints of echo (intermittent, not reproducable) as well as overall low call and voicemail volume. We have been adjusting padding levels and now have input gain at +4db and output attenuation at -5db. We have performed the testing with the tone generated by the phone (actually outputed around -21db, not -15) and our ERL and Unity recording were good. We have also used the URL referenced above.

Are you aware of any "recommendations" on what the power signal level "into the ip network" should be? I haven't been able to find any. Unity traces indicate lots of voicemails being recorded at -45 to -55 db ..... which would indicate to me levels are overall low.

Any help would be appreciated. We have run the gamut (sp?) with the TAC engineers and local SEs.

New Member

Re: G.711 sampling rate & jitter with the 6608 blade

I have been having a similar problem and my investigations so far have pointed at problem with MGCP controlled gateways. In the setup of a call between CCM and the gateway there is an information element that allows the CCM to vary the gain of a call automatically. RFC2705 details this. I haven't as yet put this to the test yet. Hope it helps.

184
Views
10
Helpful
3
Replies
CreatePlease login to create content