Ringback not working, Choppy voice, and Cannot hear callers

[datafanatics]

About 20 days ago our service provider had an issue with power and our server went down. When it came back up, everything came back up as expected, or so I thought.

Since then, when we make outbound calls, we get no ringback on the phone letting the dialer know the call is actually working. If the remote party answers, you get no audio. Also, the calls are often choppy when you can hear someone, to the point that the call is pointless. One of the oddest things that has been reported is crosstalk! I've checked the firewall ports and things look fine there. I've ran through the configs, comparing them to one of our other servers and things look to be in order. I'm stumped.

Can anyone please shed some light on what may be happening or where I could look? I'm dropping my iptables input chain in case it is helpful. I'm wondering if maybe the firewall is the issue here.

Chain INPUT (policy DROP 39 packets, 4973 bytes)
pkts bytes target prot opt in out source destination
1728K 2652M sip-auth-fail all -- * * 0.0.0.0/0 0.0.0.0/0
1728K 2652M sip-auth-ip all -- * * 0.0.0.0/0 0.0.0.0/0
1728K 2652M f2b-sshd all -- * * 0.0.0.0/0 0.0.0.0/0
42883 6637K f2b-sshd tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
847K 2270M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
675K 367M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
11 4807 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "friendly-scanner" ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "friendly-scanner" ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "sipcli/" ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "sipcli/" ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "VaxSIPUserAgent/" ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "VaxSIPUserAgent/" ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "pplsip" ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "pplsip" ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "system " ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "system " ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "exec." ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "exec." ALGO name bm TO 65535 ICASE
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091 STRING match "multipart/mixed;boundary" ALGO name bm TO 65535 ICASE
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091 STRING match "multipart/mixed;boundary" ALGO name bm TO 65535 ICASE
4489 661K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
4932 264K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
12734 768K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
85 4796 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7443
9002 540K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5060:5091
23 6520 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5060:5091
94982 5861K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:16384:32768
6455 512K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
7 298 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194

Chain IN_public_allow (1 references)
pkts bytes target prot opt in out source destination
183K 14M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW,UNTRACKED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW,UNTRACKED
645K 41M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ctstate NEW,UNTRACKED
273K 136M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 ctstate NEW,UNTRACKED
85450 4967K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 ctstate NEW,UNTRACKED
514 132K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5061 ctstate NEW,UNTRACKED
5742 284K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5061 ctstate NEW,UNTRACKED
454K 272M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5080 ctstate NEW,UNTRACKED
13321 696K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5080 ctstate NEW,UNTRACKED
21 9531 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5081 ctstate NEW,UNTRACKED
890 51260 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5081 ctstate NEW,UNTRACKED
4053K 732M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:16384:32768 ctstate NEW,UNTRACKED
1928K 116M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22222 ctstate NEW,UNTRACKED
11433 594K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 ctstate NEW,UNTRACKED
1733 92920 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10050 ctstate NEW,UNTRACKED
288K 19M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ctstate NEW,UNTRACKED
18984 1048K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7443 ctstate NEW,UNTRACKED

 

[NVGcom]

Hi,

It is always good to provide FusionPBX, FS, PHP versions.
In any case, the ringback can be resolved by clearing cache and rescanning SIP Profiles. This happens every time services restarted or server rebooted.
So, try with the service restart of nginx, php-fpm, postgres, freeswitch then clear cache, reload ACL, rescan SIP Profiles.
In some instances you will need to reboot the phones remotely if you can.
Verify you have all IP's from Provider in ACL - SIP, RTP, etc. Depending on the Provider.

The newer versions of FusionPBX have Event Guard that helps with security.

 

[datafanatics]

Turned out that even though the ACL was populated with the IPs of my provider.. they weren’t being pushed into iptables. So I manually inserted the iptable rules, flushed cache, and restarted the profiles and everything went back to normal.

Not quite sure how the ACLs in FusionPBX interface with iptables, but it doesn’t seem to be working right after the last reboot.

 

[NVGcom]

Hi,

Did you use fail2ban and ignore IP or you manually added to iptables?
You have different chains. ACL usually knocks on nginx-404 or fusionpbx-404.
I'd recommend not to play to much with iptables, but if you managed to make it work, alright.

I have several servers and never had that problem nor need to add anything into iptables.
In newer version 5.1 I believe, they added Event Guard which helps in sip-auth-failure and sip-auth-challenge.

If the server fails, the services I mentioned above might not end properly so on reboot you need to restart them in CLI.

restart php8.1-fpm && systemctl restart postgresql && systemctl restart nginx && systemctl restart freeswitch

Change the PHP version to whatever you have.

You can restart SIP Profiles, but use rescan instead via GUI - Status - SIP Profiles. You'll need to do this after every server restart or services restart.

 

[markjcrane]

@datafanatics The Advanced -> Access Controls in FusionPBX is used for FreeSWITCH and a whitelist for Event Guard. However, it has never been used directly for adding into addresses into IP Tables.

 

[datafanatics]

Hi,

Did you use fail2ban and ignore IP or you manually added to iptables?
You have different chains. ACL usually knocks on nginx-404 or fusionpbx-404.
I'd recommend not to play to much with iptables, but if you managed to make it work, alright.

I have several servers and never had that problem nor need to add anything into iptables.
In newer version 5.1 I believe, they added Event Guard which helps in sip-auth-failure and sip-auth-challenge.

If the server fails, the services I mentioned above might not end properly so on reboot you need to restart them in CLI.

restart php8.1-fpm && systemctl restart postgresql && systemctl restart nginx && systemctl restart freeswitch

Change the PHP version to whatever you have.

You can restart SIP Profiles, but use rescan instead via GUI - Status - SIP Profiles. You'll need to do this after every server restart or services restart.

I’m glad you asked about fail2ban, I’ll make a point to go in and add the ruleset in for the provider IP addresses.

 

[datafanatics]

@datafanatics The Advanced -> Access Controls in FusionPBX is used for FreeSWITCH and a whitelist for Event Guard. However, it has never been used directly for adding into addresses into IP Tables.

Ah ok, good to know! I guess it was just an assumption, unfounded of course.

My issue with outboard call ring back was resolved. However we have random issues with inbound calls having no audio. Any suggestions? I’m going to search the forums here as well. Upon logging in to research I saw your response to this thread.

Thanks!

 

[markjcrane]

Phones usually sit behind devices such as a router or firewall.
- These devices can ruin VoIP services often with a SIP ALG.
- Recommend disabling a SIP ALG on the device.
- What kind of route or firewall is being used make and model.
- Where is FreeSWITHCH in the same network?
- Is FreeSWITCH behind NAT on a different network?
- What kind of phones are you using make and model?

All of these questions I think are relevant to intermittent audio issues.

 

[datafanatics]

Phones usually sit behind devices such as a router or firewall.
- These devices can ruin VoIP services often with a SIP ALG.
- Recommend disabling a SIP ALG on the device.
- What kind of route or firewall is being used make and model.
- Where is FreeSWITHCH in the same network?
- Is FreeSWITCH behind NAT on a different network?
- What kind of phones are you using make and model?

All of these questions I think are relevant to intermittent audio issues.

The freeswitch server has a public IP, no NAT there. The client is using a nitehawk router. Phones are Grandstream GXP2160.

I'll check their nighthawk to see if it has anything SIP related in it.

 

[markjcrane]

What is your version of FreeSWITCH?

 

[Adrian Fretwell]

I apologise for butting in here, I noticed that in your original post you mention cross talk, it was common in the analogue telephony days, but now few people take reports of it seriously with VoIP, however there are ways it can happen. If nothing had changed in your Fusion/Freeswitch configuration when this issue appeared, then it may be worth looking at the network or asking your provider to look at the network.

If there are switches (or switch chips in routers) on the network, there is a possibility that one of these has ended up with a corrupt MAC forwarding table, this can be a result of a memory fault, the sort of damage that can be caused by an uncontrolled power outage. I have seen faulty network switches randomly send packets to the wrong MAC addresses, this can cause choppy speech and cross talk.

The same is true of any routers performing NAT, corrupted NAT forwarding tables have a very similar effect but cause the issue at Layer3 rather than Layer2. A NAT router running short of free memory can also randomly not open new NAT holes, this can be frustrating to find.

In situations like this I always advise getting some packet captures, if RTP packets are going missing you need to understand where they are going missing, then you can start to ask why.