Solved Calls go silent after about 10 minutes

[RS-IT]

Hi All,

I am posting this here because I can't seem to figure this out. We are having an issue where someone will be on a call with someone external, and after around 10 minutes, the call goes silent on both ends. It remains connected, but neither side can hear each other. Reports of this happening have come from multiple different people here, including myself, so I don't think it's the phones. This issue seems to have started around the time we switched from our local SIP to Voxtelesys. This would lead me to believe it's something to do with that connection, but I'm not sure what it would be.

We are using the image 3cx publishes, and it is running v20.

Has anyone else had this issue, and if so, how did you fix it?

 

[paulodagraca]

Hello RS-IT,

That does sound like you could have some firewall problem.
I would guess that you are running the 3CX server local on the LAN behind a Firewall on the internet, is that correct?
And if yes, did you ever entered some 'rules' in the firewall for the SIP trunk provider, and have you checked this recent if any change is needed?
You could also check the 'Keep Alive Timer' in the 3CX server to check if it is the firewall closing the connection.

Paulo

 

[BrunoI_3CX]

Based on the description, this behavior is seems related to RTP media being interrupted, rather than the call itself dropping, which is why the call remains connected but audio becomes silent on both sides.

Please confirm that the firewall test under Admin > Dashboard > Troubleshooting > Firewall shows all checks in green.

Please also confirm that the default Voxtelesys provider template is in use and has not been customized.

As a next step, you can start a packet capture and then place a test call lasting more than 10 minutes. If the issue occurs, you can review the SIP dialogue by opening the capture file in Wireshark and navigating to Telephony > VoIP Calls, to check whether RTP packets stop flowing in one or both directions at the time of the issue.

Additionally, it may also be worth contacting your SIP provider to confirm that they do not observe any issues on their side when the call is established.

 

[RS-IT]

Yes, I am running 3cx behind a firewall.

I created a test rule that allows just the 3cx server to have open access to the internet. That hasn't fixed the issue.

The Keep Alive timer is set to the default of 30 seconds. Should that be higher? If so, what is a good number for that?

 

[paulodagraca]

Hello RS-IT,

Try to set the timer lower, like 15 sec., this wil create faster updates.
Again this is not the full resollution, but could indicate if there is some time-out happening with the router.

Please also check remarks from: BrunoI_3CX

Paulo

 

[RS-IT]

The firewall checker was not green, so I ran the test. Here's what came back. I know we don't allow external connections in, so at least some of that is probably related.

resolving 'stun-us.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX PhoneSystem 01 SIP Server... failed (How to resolve?)
stopping service... done
detecting SIP ALG... failed (How to resolve?)
testing port 5060... Mapping does not match 5060. Mapping is 63770. (How to resolve?)
starting service... done
testing 3CX PhoneSystem Media Server... failed (How to resolve?)
stopping service... done
testing port 5090... Mapping does not match 5090. Mapping is 43974. (How to resolve?)
testing ports [9000..9398]... failed (How to resolve?)
testing port 9000... Mapping does not match 9000. Mapping is 48720. (How to resolve?)
testing port 9002... Mapping does not match 9002. Mapping is 27184. (How to resolve?)
testing port 9004... Mapping does not match 9004. Mapping is 34048. (How to resolve?)
testing port 9006... Mapping does not match 9006. Mapping is 47677. (How to resolve?)
testing port 9008... Mapping does not match 9008. Mapping is 7434. (How to resolve?)
testing port 9010... Mapping does not match 9010. Mapping is 53763. (How to resolve?)
testing port 9012... Mapping does not match 9012. Mapping is 15176. (How to resolve?)
testing port 9014... Mapping does not match 9014. Mapping is 16046. (How to resolve?)
testing port 9016... Mapping does not match 9016. Mapping is 1708. (How to resolve?)
testing port 9018... Mapping does not match 9018. Mapping is 39326. (How to resolve?)
testing port 9020... Mapping does not match 9020. Mapping is 39292. (How to resolve?)
testing port 9022... Mapping does not match 9022. Mapping is 59330. (How to resolve?)
testing port 9024... Mapping does not match 9024. Mapping is 7238. (How to resolve?)
testing port 9026... Mapping does not match 9026. Mapping is 60037. (How to resolve?)
testing port 9028... Mapping does not match 9028. Mapping is 59577. (How to resolve?)
testing port 9030... Mapping does not match 9030. Mapping is 34457. (How to resolve?)
testing port 9032... Mapping does not match 9032. Mapping is 62327. (How to resolve?)
testing port 9034... Mapping does not match 9034. Mapping is 50790. (How to resolve?)
testing port 9036... Mapping does not match 9036. Mapping is 36877. (How to resolve?)
testing port 9038... Mapping does not match 9038. Mapping is 15765. (How to resolve?)
testing port 9040... Mapping does not match 9040. Mapping is 49941. (How to resolve?)
testing port 9042... Mapping does not match 9042. Mapping is 6102. (How to resolve?)
testing port 9044... Mapping does not match 9044. Mapping is 7696. (How to resolve?)
testing port 9046... Mapping does not match 9046. Mapping is 64036. (How to resolve?)
testing port 9048... Mapping does not match 9048. Mapping is 23095. (How to resolve?)
testing port 9050... Mapping does not match 9050. Mapping is 57255. (How to resolve?)
testing port 9052... Mapping does not match 9052. Mapping is 31124. (How to resolve?)
testing port 9054... Mapping does not match 9054. Mapping is 20869. (How to resolve?)
testing port 9056... Mapping does not match 9056. Mapping is 35668. (How to resolve?)
testing port 9058... Mapping does not match 9058. Mapping is 49653. (How to resolve?)
testing port 9060... Mapping does not match 9060. Mapping is 43614. (How to resolve?)
testing port 9062... Mapping does not match 9062. Mapping is 54885. (How to resolve?)
testing port 9064... Mapping does not match 9064. Mapping is 44034. (How to resolve?)
testing port 9066... Mapping does not match 9066. Mapping is 26058. (How to resolve?)
testing port 9068... Mapping does not match 9068. Mapping is 41117. (How to resolve?)
testing port 9070... Mapping does not match 9070. Mapping is 14778. (How to resolve?)
testing port 9072... Mapping does not match 9072. Mapping is 58420. (How to resolve?)
testing port 9074... Mapping does not match 9074. Mapping is 50166. (How to resolve?)
testing port 9076... Mapping does not match 9076. Mapping is 1829. (How to resolve?)
testing port 9078... Mapping does not match 9078. Mapping is 35638. (How to resolve?)
testing port 9080... Mapping does not match 9080. Mapping is 58251. (How to resolve?)
testing port 9082... Mapping does not match 9082. Mapping is 21606. (How to resolve?)
testing port 9084... Mapping does not match 9084. Mapping is 53368. (How to resolve?)
testing port 9086... Mapping does not match 9086. Mapping is 9119. (How to resolve?)
testing port 9088... Mapping does not match 9088. Mapping is 51836. (How to resolve?)



etc for all ports tested. Shortening because I don't have enough characters.
starting service... done

 

[paulodagraca]

Hello RS-IT,

So the problem you have seem to be, the port-translation.
Mapping does not match 9000. Mapping is 48720.

This should be port 9000 -> port 9000, but the firewall does some translation: port 48720
Please click the (How to resolve?) and work with the information found there.

Paulo

 

[RS-IT]

I'm really not sure where the port translation problem is coming from though. I'm not doing any port translation on the firewall. It's just a NAT rule that translates the IP address of the server to our public IP.

 

[fxbastler]

I'm really not sure where the port translation problem is coming from though.

In most scenarios: it's your firewall. Which one are you using?

 

[RS-IT]

In most scenarios: it's your firewall. Which one are you using?

We are using a Palo Alto firewall.

 

[fxbastler]

https://www.3cx.com/docs/manual/firewall-router-configuration/
We are using a Palo Alto firewall.

verflixt, I can’t think of the appropriate menu item right now because we haven’t had any in use for quite some time.
I vaguely remember something about App ID detection (objects need to be created to exclude this) but that might not be correct. Unfortunately, there’s no official documentation that clearly describes how to set up a Palo Alto in front of a 3CX.

Maybe someone else here on the forum has the right solution right away regarding outbound source port NAT (your problem) for a Palo Alto.

 

[SteveITS]

@RS-IT SIP ALG also needs to be disabled. If you follow the "how to" links it should help guide you. Usually that's an on/off setting in routers. And/or https://www.3cx.com/docs/firewall-checker/ may help.

You can limit SIP to Voxtelesys IPs, but I suggest passing the firewall test, then limiting connections.

 

[Kevin@voxtelesys]

Like @SteveITS make sure SIP ALG is disabled. Its likely this is a port translation and after 10 minutes there is a reinvite and in the invite the RTP ports are not translated. If you have a ticket open with us (voxtelesys) we can open a capture, once you have an example you can share it.

 

[RS-IT]

I thought I already had SIP ALG disabled, but apparently I didn't. I'm disabling it now, and we will see if that fixes the issue.

 

[paulodagraca]

Hello RS-IT,

Re-run the Firewall test (when there are no calls), and see if this work good now.

Paulo

 

[RS-IT]

Disabling SIP ALG causes all inbound calls to terminate after 30 seconds. The 3cx logs for those calls show Call ended by Voxtelesys.

 

[fxbastler]

Maybe someone else here on the forum has the right solution right away regarding outbound source port NAT (your problem) for a Palo Alto.

 

[Kevin@voxtelesys]

Disabling SIP ALG causes all inbound calls to terminate after 30 seconds. The 3cx logs for those calls show Call ended by Voxtelesys.

Do you have a ticket open with Voxtelesys? If so DM me the ticket number.

Disconnect at 30 seconds is likely the IP in the network settings being set incorrectly. What happens is the PBX will answer or send the call and tell us (voxtelesys) to talk to another IP to setup and tear down the call, when we do that the PBX doesn't get our response and then terminates the call. Dropped calls are almost always SIP ALG, Incorrect IP set in the 3CX Network settings, or firewall issue.

 

[RS-IT]

I do not have one opened with Voxtelesys since the 30 second dropped calls only started after turning off SIP ALG. I turned it back on for now so people can work, but I am still trying to see if there is something I have turned on in the firewall that is doing it.

 

[Kevin@voxtelesys]

DM me the account number and we will open a capture.