[Asterisk-Users] Distortion/crackling/skipping problems on outgoing calls -- please help!!!

Robert Geller robert at worksofmagic.com
Sat Sep 3 21:50:53 MST 2005


Robert Geller wrote:

> Robert Geller wrote:
>
>> Rich Adamson wrote:
>>
>>>>>
>>>>>
>>>>>     
>>>>
>>>>
>>>> Thank you very much for your response. I do acknowledge that my 
>>>> previous posts did not contain much technical information to speak 
>>>> of, but it was mainly because I wasn't/am not familiar with the 
>>>> Asterisk CLI and troubleshooting Asterisk problems, so I apologize 
>>>> for that.
>>>>
>>>> I did get the idea early this morning to try to analyze packets 
>>>> with ethereal, and I captured packets when I was made an internal 
>>>> IAX call to the Asterisk system (voicemail). I don't really know 
>>>> what to look for, but I will learn (again, I'm not very familiar 
>>>> with ethereal). Do you hapeople say ve any suggestions for filters 
>>>> to use, to evaluate possible packet loss or resending of data?
>>>>   
>>>
>>>
>>>
>>> An important item to look at in each packet is the timestamp. In sip
>>> packets, the timestamp should be increasing by 160 for each conseq pkt.
>>> In iax packets, the timestamp should be increasing by 20 for each pkt.
>>>
>>> So if you see a timestamp of 3290 in one pkt and 3310 in the next (a 
>>> diff
>>> of 20), that's good. Notice the increasing timestamp value and the 
>>> diff.
>>> If pkt 3310 arrives before 3290, then something in the network is 
>>> delaying
>>> the delivery of packets so as to cause them to not arrive in the proper
>>> order.
>>>
>>> If there are missing packets, then you'll see timestamps jumping by 40,
>>> 60, 80 or some other value (diff) for iax packets, or, similar for sip
>>> packets.
>>>
>>>  
>>>
>>>> Regarding the command that you suggested in the CLI, iax2 show 
>>>> netstats, it doesn't recognize that command or anything similar, 
>>>> and 'help' doesn't return anything similar that I can see (I'm 
>>>> using 1.0.7 if that helps).
>>>>   
>>>
>>>
>>>
>>> Since 1.0.7 is rather old (in the scheme of things), I'd suggest you
>>> install something newer to play with. There has been a ton of stuff
>>> that has changed since 1.0.7, but I don't recall if those changes would
>>> have anything to do with your problem. (I use nothing but cvs head, but
>>> I kind of keep an eye on how many changes are happening (and for what
>>> reason), and upgrade when the number of problems seem to be at a low.
>>> The 'iax2 show netstats' would have been added in a later version.
>>>
>>>  
>>>
>>>> At this point, I'm thinking that it could be a matter of bad 
>>>> cabling or something. The Cat5 cable that's running the 8 or so 
>>>> feet from my PC to my router is homemade by me, and many people do 
>>>> report problems with homemade cables. I may not have made it 
>>>> exactly right, or the untwisted segment may be longer than 1/2", 
>>>> which supposedly causes distortion and interference. Perhaps I 
>>>> ought to run out and buy a couple factory-made cables to test the 
>>>> difference, if any, between them.
>>>>   
>>>
>>>
>>>
>>> Replacing the cable would probably be a good start since they are
>>> relatively cheap. Go buy a new one so there's no question about its
>>> quality. Also, keep the cable at least a little distance away from
>>> transformers, ballasts, and other things that tend to generate tons
>>> of electical noise. (Some desk lamps even have extremely noisy 
>>> transformers
>>> or ballasts in them.)
>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation sponsored by Easynews.com --
>>>
>>> Asterisk-Users mailing list
>>> Asterisk-Users at 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
>>>
>>>
>>>
>>>  
>>>
>> Your advice was *extremely* helpful. It seems that I learn something 
>> new each time I read you all's posts. To me, it looked like each 
>> packet was correctly sent at the right interval each time, but I 
>> didn't evaluate each one. However, the general trend is that there 
>> seems to be no packet loss or resending.
>>
>> I could buy another cable as well, just to be safe, but it seems to 
>> me the potential IRQ conflict is more the more likely problem--of 
>> course, even when I "ifconfig eth2 down"ed the interface, it still 
>> showed up in /proc/interrupts -- does bringing the interface down not 
>> completely bring it down? Should I permanently disable it and reboot?
>>
>> Again, thank you very much for your ongoing help; I feel like I'm 
>> paying (or ought to) for professional support here. :-)
>>
>> Regards,
>> Robert Geller
>> _______________________________________________
>> --Bandwidth and Colocation sponsored by Easynews.com --
>>
>> Asterisk-Users mailing list
>> Asterisk-Users at 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
>>
>>
>>
> I modprobe -r'ed prism54, the wireless kernel modules for my card, and 
> here's what /proc/interrupts looks like:
>
> robert at linux:~/torrents$ cat /proc/interrupts
>           CPU0
>  0:   81981003    IO-APIC-edge  timer
>  1:      49755    IO-APIC-edge  i8042
>  7:          2    IO-APIC-edge  parport0
>  8:          1    IO-APIC-edge  rtc
>  9:          0   IO-APIC-level  acpi
> 12:     499429    IO-APIC-edge  i8042
> 14:     224679    IO-APIC-edge  ide0
> 15:     900392    IO-APIC-edge  ide1
> 169:          0   IO-APIC-level  uhci_hcd
> 177:      67917   IO-APIC-level  Intel 82801BA-ICH2
> 185:          0   IO-APIC-level  uhci_hcd
> 193:          2   IO-APIC-level  ohci1394
> 201:    2020679   IO-APIC-level  eth0
> NMI:          0
> LOC:   81991943
> ERR:          0
> MIS:          0
>
>
> Well, eth2 isn't even on there, let alone being shared with that Intel 
> device. Still, however, the softphone sounds just as bad. Who would 
> have thought it was a coincidence that there was IRQ sharing/conflicts 
> going on, yet that isn't the soure of my problem?
>
> I'm stumped. I even tried moving the power/surge strip farther away 
> from the computer, but it can't be too far away, about 18 inches-2 
> feet now.
>
> So, 1) there doesn't *seem* to be any packet loss or incorrect packet 
> sending, 2) there are no more IRQ conflicts, and 3) I even tried 
> moving my power strip away from the PC. What gives?
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com --
>
> Asterisk-Users mailing list
> Asterisk-Users at 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
>
>
>
Sorry to write so many consecutive messages in such a short period of 
time, but this problem is really bugging me as it has been going on for 
days.

When I look in Ethereal, there are actually "two calls" going on -- in 
this particular call, Source call #4 and Source call #10318, #4 coming 
from the asterisk server and the other one coming from my computer to 
the Asterisk server. I don't know why there are two separate "calls," 
but perhaps one of you do. Anyhow, source call #10318 seems fine, 
sending a new packet every 20 ms pretty much perfectly and all (although 
I do see now that one packet has a timestamp of 33080 and the next has 
one of 35060 -- is this something to be concerned about? it doesn't seem 
widespread). However, call #4 seems to send every 20 ms, but then there 
will be a pause or something in sending, in between which there will be 
more packets from source call #10318 which are sent pretty much OK. 
Then, the next packet for source call #4 will have a timestamp of 
something like 33540, exactly 200 ms after the previous packet from 
source call #10318. However, the next packet for SC (source call) #10318 
increments 20 ms like it should. Every single packet then on (in this 
capture, I recorded about 1500 packets) sends perfectly. iax2.rrdropped, 
iax2.rrjitter, and iax2.iax.rrloss returned only 2 packets--the same 
two, in the middle of the 1500 packets. So, out of 1500, these are the 
only two that seem to have problems.

I don't know what else this could be at this point, but again, thank you 
for your help!



More information about the asterisk-users mailing list