Choppy Audio Question

[mparella]

I have just ONE user who is experiencing intermittent choppy audio while on both active calls and with their voicemails left with unity. From what this user reports, it only occurs with calls outside (from the gateway) the organization. Only occurs a couple times a week. Any ideas?

Will rate posts. Thanks.

[Tim Smith]

Is it just one user? Or just one user reporting it?

Have you checked the basics?

Open a web browser to the phone's IP address and check its switchport for errors etc

Login to the switch and check the same

Maybe the gateway part is just coincidence..

Although you say when both calls are active.. is there any rate limiting set on the switchport?

Maybe post the switch port config.

Cheers,

Tim

[mparella]

Thanks, Tim. Yes, I have gone through some of thjose basics. The part that led me away from the actual phone/switchport was the voicemial quality on unity. The user forwarded me a vmail and it was very choppy. So at this point I was thinking the issue was between carrier-GW-local switch (since the user experienced it on a call and it was same way in unity.) I have asked other users and no one reports the same issue. Strange it is locallized to just one.

[Tim Smith]

So was the issue just choppy audio on the voicemails? or on phone calls as well?

I'm not sure how much first hand you have seen but I sometimes find user reports are misleading..

Have you also checked "show controller e1" on your gateway to look for clock slips and other errors?

Cheers,

Tim

[mparella]

Apparently it is choppy on voicemails and active calls. Only from the outside, though. I noticed two things on the gateway. I have two PRI out to the PSTN. The Serial 0/0/0:23 and Serial 0/0/1:23 which I believe is the signaling channel for both of the lines have a high number of CRC input errors.

The other thing I also noticed is there is no "no vad" on any of my dial-peers.

Any thoughts on either being a problem?

Thanks!

[Tim Smith]

No VAD is a good thing :)

Dont worry bout that one.

VAD is voice activity detection.. and it usually freaks out the users... so I would always make sure this is disabled everywhere.

Normally you would have a signalling channel i.e. the 0:23 timeslot for each PRI - unless you are using NFAS? Is it H323 or MGCP?

Are the errors on both :23 interfaces?

What about clock slips under "show controller e1" - run this for both PRI's.

It's a good idea to do a "clear counters"

Then watch your E1 controllers for a while, see if the errors rack up quickly.

It can be usual to have a few errors here and there.. but typically they shouldnt increase rapidly.

You can try swapping your cable between the NTU and the router also.

They usually indicate some sort of problem. It may be worth asking your provider to test the line.

Cheers,

Tim

[mparella]

Thanks, Tim! It's H323 configured. So would you suggest I enter the "No VAD" for my dial-peers. I looked at my other GWs and they have it, but not this one.

As for my show controllers t1, I get no clock slips , no violations and no errors.

When I do a sh int s0/0/0:23 I get a number of CRC input errors.

[Tim Smith]

Hi,

I would disable VAD. Like I said, most users hate it, it sounds wierd.

Technically you might use it if you were really trying to save bandwidth... it doesnt send any packets during silence in a call. But you should be provisioning enough bandwidth for each call these days anyway.

That said... VAD should not be causing you any quality issues.

So S0/0/0:23 has CRC errors but the other circuit does not?

Did you try the clear counters? And see if they increase rapidly?

You need to try and isolate the problem here.

Have you tried a new cable?

Then do the same.. clear counters and see if they increase rapidly again.

I'm not sure on your config, but you may even be able to swap the circuits between the 2 interfaces and see if the errors transfer..

Could also be a faulty interface card.. test above should help isolate that.

I would try the cables first.

If that doesnt help.. get the telco to check out the circuits. They should be able to do a loop and test to isolate the cause.

Cheers,

Tim