> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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
_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
