Hi, I have a problem I will describe. I have PAP2 connected to the internet to an asterisk box with 2 TDM cards, one TE100P E1 with PRI and one TDM400P with 2 FXS an one FXO. When I call to the TDM400 cards from the PAP2 eveything is OK, sound quality is perfect. When I call to terminate the call in PSTN through E100P I hear clicks which aparently are RTP packet looses. This clicks are only heard in the PSTN side, not in the PAP2. If I connect PAP2 in LAN to the *, everything sounds is normal. So I evaluate the following: 1. Delay or something similar in internet could not be the problem because it works with TDM400P (same configuration) 2. The PAP2 could not be the problem because it works with TDM400 (and other ip phones) and in a LAN. 3. The TE100P could not be the problem because it works fine if the PAP2 is connected via lan and not via internet. 4. With other IP phones everything works fine. It seems that the combination of PAP2 <-> Internet <-> TE100P is the problem. Any suggestions? is there any jitter buffer adjust for the sip channel or zap in the * side only for the TE100P? I look that in zapata.conf there is a jitterbuffer parameters which defaults to 4, should I modify it? Thanks, Alejandro G.
On Wednesday 08 June 2005 11:19, Alejandro G wrote:> When I call to the TDM400 cards from the PAP2 eveything is OK, sound > quality is perfect. > When I call to terminate the call in PSTN through E100P I hear clicks which > aparently are RTP packet looses. This clicks are only heard in the PSTN > side, not in the PAP2.You just described a classic clock slip situation. Are you synchronizing to the PSTN? i.e. does your span line have '1' for clocking? You want to sync to them instead of free-run (clock of '0'). -A.
Thanks for your answer. Googling in the lists I found what you are telling that maybe there is a synchro problem with the E1, but I'm not so sure that this could be. I am configuring zaptel.conf like this: span=1,0,0,ccs,hdb3 bchan=1-15,17-31 dchan=16 But I also changed to test to: span=1,1,0,ccs,hdb3 The same thing happens. You may consider also that if I connect PAP2 to LAN everything works, also if I use other ip phone from internet works fine. I also check if I'm loosing interrupts and everything seems ok. Also I pull out the TDM400 from the box. At last I change jitterbuffer=16 and it works better, the clicks are reduced. Could this be possible? What is the function of this parameter in zapata.conf? I should tell you that the TE100P is connected to another E1 board (not a live E1) from Natural Microsystems which acts as a gateway to PSTN. This board works as a PRI master but I don't think that this could be the problem as long as using other phones or in LAN it works perfectly and the voice is clear with no clicks o sound looses. Thanks again, Alejandro
-----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Alejandro G Sent: Thursday, 9 June 2005 1:52 PM To: asterisk-users@lists.digium.com Subject: [Asterisk-Users] Clicks in audio with TE100P PRI Thanks for your answer. Googling in the lists I found what you are telling that maybe there is a synchro problem with the E1, but I'm not so sure that this could be. I am configuring zaptel.conf like this: span=1,0,0,ccs,hdb3 bchan=1-15,17-31 dchan=16 But I also changed to test to: span=1,1,0,ccs,hdb3 The same thing happens. You may consider also that if I connect PAP2 to LAN everything works, also if I use other ip phone from internet works fine. I also check if I'm loosing interrupts and everything seems ok. Also I pull out the TDM400 from the box. At last I change jitterbuffer=16 and it works better, the clicks are reduced. Could this be possible? What is the function of this parameter in zapata.conf? I should tell you that the TE100P is connected to another E1 board (not a live E1) from Natural Microsystems which acts as a gateway to PSTN. This board works as a PRI master but I don't think that this could be the problem as long as using other phones or in LAN it works perfectly and the voice is clear with no clicks o sound looses. Thanks again, Alejandro _______________________________________________ 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
It seems that configuring span=1,1,0,ccs,hdb3 and changing jitterbuffer=16 resolves or masks the issue. What I will do now is reduce again jitterbuffer to default to see what happens. To answer some of the questions I don't see hard disk activity when the clicks appear, also the hard disk has very low usage. The clicks I listened were continuous and periodic. If the other party stays in silence I also listen the click every half second. Also to check, I run zttest and gives me Best=100%, average=99.989%. Once tested again I'll write the results to see what happen. Thanks to all Alejandro
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com]On Behalf Of Alejandro G > Sent: Friday, June 10, 2005 8:12 AM > To: asterisk-users@lists.digium.com > Subject: [Asterisk-Users] Clicks in audio with TE100P PRI > > > > It seems that configuring span=1,1,0,ccs,hdb3 and changing > jitterbuffer=16 resolves or masks the issue. What I will do now is reduce > again jitterbuffer to default to see what happens. >Your issue is very likely the size of the zaptel jitterbuffers setting. If the zaptel driver is not immediately available to accept a frame of data it places it in an internal queue of pending writes. If that queue is full then the write is refused by the zaptel layer and then silently discarded by chan_zap causing a gap in the audio once it is played out of the zaptel card. If you crank up the debug level you will probably see 'Write returned -1...' (aka. EAGAIN) debugs that mostly correlate to the pops and clicks. Note that the zaptel driver legitimatly (if perhaps not appropriately) also refuses data when the channel is muted, such as during DTMF generation and at other times, so not _all_ EAGAIN debugs are a sign of problems. There is more background on my experience with the T100P pop&click issue in http://lists.digium.com/pipermail/asterisk-dev/2005-May/012432.html Hope that helps. Kris Boutilier Information Systems Coordinator Sunshine Coast Regional District
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. If I raise jitterbufer=16 the problem disappear (or becames impercetible). Anyway I am interested in understand what is happening.> Your issue is very likely the size of the zaptel jitterbuffers setting. Ifthe zaptel driver is not> immediately available to accept a frame of data it places it in aninternal queue of pending writes.> If that queue is full then the write is refused by the zaptel layer andthen silently discarded by> chan_zap causing a gap in the audio once it is played out of the zaptelcard. If you crank up the> debug level you will probably see 'Write returned -1...' (aka. EAGAIN)debugs that mostly correlate to> the pops and clicks. Note that the zaptel driver legitimatly (if perhapsnot appropriately) also> refuses data when the channel is muted, such as during DTMF generation andat other times, so not> _all_ EAGAIN debugs are a sign of problems.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. 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? 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. What is clear is that jitterbuffer=16 corrects the problem. One more thing: no matter what codec I use, G729 or G711 the sound clicks are almost the same. Is anyway I could debug at RTP level in asterisk to see what is happening and check if there is packet loose? Thanks Alejandro
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@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