[Asterisk-Users] Clicks in audio with TE100P PRI

[Kris Boutilier]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com]On Behalf Of 
> Alejandro G
> Sent: Friday, June 10, 2005 9:57 AM
> To: Asterisk
> Subject: [Asterisk-Users] Clicks in audio with TE100P PRI
> 
> I tested all again. No matter if span=1,1,0  or span=1,0,0 if 
> I configure jitterbufer=4 I have glitches that I'm almost sure that are "holes" in
> audio.

FYI, changing the sync source is a non-trivial thing. You need to be sure you're also changing the sync source on the opposite end. If the T100P is interfaced to a Telco then you really ought not to be changing this - it _will_ break things if set wrong.

{clip}
> This makes perfect sense but again some issues of the problem 
> do not match. I set debug at level 9 and  there is no message of errors. 

The now-canceled patch in http://bugs.digium.com/view.php?id=4107 shows where the data is being discarded - the reporting of this may have changed in the current code base and/or zaptel may be accepting the data and discarding it internally now. Asterisk is a fast moving target, take all behavioural comparisons with a grain of salt.

> Another thing I do not understand is why the same configuration:
> 
> PAP2 <-> LAN <-> Asterisk <-> TE100P  works perfect, and 
> instead of LAN using internet generates the problem. Shouldn't it be the 
> same for both configs?

Not neccessarially; if we assume that there is no congestion on the LAN then packets arrive off the wire, say, every 20ms, regular as clockwork +/- a few microseconds. On the Internet there _is_ congestion, hence buffering, hence packets might arrive in a 'squirt' as quickly as the nic can deliver them, followed by a 'large' gap, followed by another squirt etc. Asterisk doesn't re-marshal the packets as they pass through the core, thus the bunching up that occurs at chan_zap, which mandates evenly spaced, well marshaled blocks of data. 

> The only difference I see is that the rtp packets came from 
> another Ethernet card, but if I call to terminate calls with another carrier 
> using that eth works fine.

You mean a <network>-<asterisk>-<network> call path? Then, yes, that also implies an issue at the zap layer.

> One more thing: no matter what codec I use, G729 or G711 the 
> sound clicks are almost the same.

That implies that the issue isn't on the rtp side, rather in the core or on the zap side as the data is transcoded to ulaw/alaw by the time it hits chan_zap. If you were using chan_iax with the new iax jitterbuffer and enabled genericplc you'd find the pop&click didn't dissapear either.

You could also eliminate the rtp side as the source of the noise by dialing across the network into an echo() target on the Asterisk server and then running a stream of sound through - you might need to have a headset and play a stereo or something into the mic. If the drop is occuring on the network or in the core then the echo'ed audio will also contain the pop&click effect.

> Is anyway I could debug at RTP level in asterisk to see what 
> is happening and check if there is packet loose?

Depends on the channel type (sip, iax etc.) - each channel has it's own variety of commented out very low level debugging. Use the source... ;-)

Kris Boutilier
Information Systems Coordinator
Sunshine Coast Regional District