Random choppy audio on calls

Built a phone system for both myself and a client and both locations are receiving choppy audio. both locations are using the same exact hardware, VOIP.MS for SIP, and same untangle router. Its intermittent but about 10-25% of calls are choppy.

How can I tell if the issue is related to hardware on the Asterisk system or with the router? We’re using a repurposed Astaro 520 for hardware, old hardware but has Xeon, RAID1, and redundant power. Both are connected to Cisco Catalyst 3750G and Untangle 13 using Astaro 320 hardware. We haven’t noticed any issues with anything else

frepbx shows for month,
CPU load max .48,
Memory max 60% buffer and 90% cached,
Disk 5-10%
Network 60MB (gigabit network)

Have you eliminated a poor internet connection at one end or the other? Run pingtest.net

You can watch the audio packets passing from the Asterisk CLI with

rtp set debug on

each packet will be displayed if there is not an almost perfect sequence of Sent/Got then you will get “choppy audio” if you get “choppy packets” that then you need to investigate every “route” between you and your VSP, generally it will be your ISP not your VSP.

2 Likes

No internet connection issues, both are business class Time Warner with no dropped packets or other network issues. one 50x5 and other 30x3 with basically nothing using it as they haven’t moved in yet.

I enabled RTP debugging, and it all looks like below (removed external IP) what should i be looking for, just want to make sure i monitor this properly?

[2016-07-22 22:27:08] VERBOSE[21118][C-0000011b] res_rtp_asterisk.c: Got RTP packet from 0.0.0.0:11648 (type 00, seq 043518, ts 134240, len 000160)
[2016-07-22 22:27:08] VERBOSE[21118][C-0000011b] res_rtp_asterisk.c: Sent RTP packet to 192.168.2.1:11792 (type 00, seq 034373, ts 134240, len 000160)
[2016-07-22 22:27:08] VERBOSE[21118][C-0000011b] res_rtp_asterisk.c: Got RTP packet from 192.168.2.1:11792 (type 00, seq 021423, ts 1687311766, len 000160)
[2016-07-22 22:27:08] VERBOSE[21118][C-0000011b] res_rtp_asterisk.c: Sent RTP packet to 0.0.0.0:11648 (type 00, seq 053494, ts 1687311760, len 000160)

Then in that 40 millisecond period of time, there would have been no choppyness :slight_smile:

My experience with TW has not been too good with them honoring their court imposed net-neutral enforced rtp policy, YMMV of course. Is there any other traffic on that service?

Interesting their business class is completely different quality than home, which is why its about 5x more.

Currently testing with cell phone next to something making white noise and have a few cut outs, should i be looking for logs like below that have 2 gots then 2 sent’s and not the normal sent,got,sent,got.

[2016-07-22 22:40:54] VERBOSE[22075][C-0000011d] res_rtp_asterisk.c: Got RTP packet from 192.168.2.1:11796 (type 00, seq 001435, ts 2815384352, len 000160)
[2016-07-22 22:40:54] VERBOSE[22099][C-0000011d] res_rtp_asterisk.c: Sent RTP packet to 208.100.39.55:18052 (type 00, seq 026391, ts 2815384352, len 000160)
[2016-07-22 22:40:54] VERBOSE[22075][C-0000011d] res_rtp_asterisk.c: Got RTP packet from 192.168.2.1:11796 (type 00, seq 001436, ts 2815384512, len 000160)
[2016-07-22 22:40:54] VERBOSE[22075][C-0000011d] res_rtp_asterisk.c: Got RTP packet from 192.168.2.1:11796 (type 00, seq 001437, ts 2815384672, len 000160)
[2016-07-22 22:40:54] VERBOSE[22099][C-0000011d] res_rtp_asterisk.c: Sent RTP packet to 208.100.39.55:18052 (type 00, seq 026392, ts 2815384512, len 000160)
[2016-07-22 22:40:54] VERBOSE[22099][C-0000011d] res_rtp_asterisk.c: Sent RTP packet to 208.100.39.55:18052 (type 00, seq 026393, ts 2815384672, len 000160)
[2016-07-22 22:40:54] VERBOSE[22099][C-0000011d] res_rtp_asterisk.c: Got RTP packet from 208.100.39.55:18052 (type 00, seq 016151, ts 2584160, len 000160)
[2016-07-22 22:40:54] VERBOSE[22099][C-0000011d] res_rtp_asterisk.c: Got RTP packet from 208.100.39.55:18052 (type 00, seq 016152, ts 2584320, len 000160)
[2016-07-22 22:40:54] VERBOSE[22075][C-0000011d] res_rtp_asterisk.c: Sent RTP packet to 192.168.2.1:11796 (type 00, seq 018914, ts 2584160, len 000160)
[2016-07-22 22:40:54] VERBOSE[22075][C-0000011d] res_rtp_asterisk.c: Sent RTP packet to 192.168.2.1:11796 (type 00, seq 018915, ts 2584320, len 000160)

yep two gets and then two sents shows packet delay on the network, when it hits about eight or more, your clients will start to get pissed off

Asterisk properly tags that traffic TOS/COS wise correctly , likely your cisco also, make sure your router honors such tags equally. Especially if you have other traffic on that route. You obviously have no control over whether TW further honors it. . . .

Try to allow only alaw&ulaw in your sip trunk settings.

While “ulaw and alaw” settings will almost certainly not be part of the solution, you might look into changing to a different codec - preferably one that is less bandwidth intensive.

Ulaw or alaw is the normal, default setting, depending on your country of implementation (ulaw is “mu-law” or " 'Murica-LAW"). See Asterisk G711 discussion. for more details on the g711 codec. There are other codecs that use less bandwidth if you can’t get the other network problems you are seeing sorted out.

1 Like

Below is our SIP settings with login removed. We’re also noticing echoing. I’m thinking its hardware related since its older hardware but not sure how to diagnose without rebuilding. We’re in US and everything else seems to check out.

canreinvite=nonat
nat=yes
contect=from-trunk
host=chicago4.voip.ms
secret=X
type=peer
username=X
disallow=all
allow=ulaw&g729
fromuser=X
trustrpid=yes
sendrpid=yes
insecure=invite
qualify=yes

I built a new untangle router and virtualized the phone system using all the same components. I’ve been monitoring my network connection and when the audio cuts out i get high ping times (2000 vs 35ms to 4.2.2.2). I haven’t seen it jump when not on a call but im looking for this now.

Issue was caused by our Modem being scripted improperly and causing random 2000ms pings from the network to the gateway. Our provider TWCBC rescripted our modem and everythings working fine so far.

1 Like