3cx External Ext. disconnect after 32 seconds.

[gordontor]

I'm using 3CX phone system for windows v12. Recently, all the external extentions out calls disconnect automatically after 32 seconds. It worked well before. This happened a few days ago, and after restarting all the 3cx services, it worked again. But this time, I restart the services, reboot the computer, the problem still exists.

 

[leejor]

Check the 3CX logs for error messages. That time (32 seconds) is about the time 3XC gives up if no RTP packets are received. There may have been a change to your firewall/Router/Anti-virus settings. Run the 3CX Firewall checker and see what results you get.

If this is happening from a single, remote destination, then there could be an issue there. If it is happening from multiple destinations, then the issue is most likely at the PBX end.

 

[gordontor]

Thanks for reply. I ran the firewall checker, and found 5060 failed. I set up DMZ to my server 192.168.0.100 previously, and nothing changed before the problem occured. Now I add a port forward for 5060 to 192.168.0.100. The problem disappeared. I will come back to report if this problem will happen again.

 

[gordontor]

The same problem occured again. Running firewall checker, the port 5060: “Failed – Firewall check failed. Some errors were detected. Please check your firewall configuration and try the test again.” The log says: [CM503021]: Call(C:5): ACK is not received from sip:[email protected]. The DMZ is on for my server IP, and the 5060 port is configured to my server IP.

 

[gordontor]

I didn't change anything. 2 hours later, I ran the firewall checker again, the 5060 result was "success", and the problem also disappeared.

 

[maingate]

we have the same problem but then with 3CX version 9
is there a solution? of a idea where we can find it?

 

[NickD_3CX]

What Router/Firewall have you got between the PBX and the WAN?

 

[gordontor]

What Router/Firewall have you got between the PBX and the WAN?

I tried some routers, 3 D-links, an SMC, and some TP-Links. Only TP-Links work well.

 

[leejor]

I tried some routers, 3 D-links, an SMC, and some TP-Links. Only TP-Links work well.

Some routers, even from the same company, can have issues, while others don't. I generally find that the more complicated the router, the more chance that there is an option that causes issues. You could provide specific models to see if anyone has had experience with them.

Along with the router, there could be something to do with a firewall/security/network programme running on the server

 

[lneblett]

In conjunction with Leejor, be careful about TP-LINK. While you did not state the model, I have been working with their engineering group for the past 3 months on their routers and SIP/RTP handling.

When I first ran across their product, I thought I had found the ideal router for most of the SMB installs. It allows port mirroring -even on the WAN port, bandwidth management - to include reservations - and other features normally associated to routers costing much more. I bought one and tried it out an it worked like a charm. The throughput was excellent and the UI was easy to navigate.

However, a little while later some calls would only get one-way audio. I traced it down to calls coming in from Sprint cell phone users and another carrier. The issue was that TP-Link does port translation. They refer to it as a security feature. What would happen is that the system would negotiate the RTP and it would indeed send it out from the server on the correct port (Say 9000), but the router would change the port to something else. Originally, when it was successful, the router worked fine, so I can only assume that the media server was running a lax RTP and would accept the inbound even if on a different port. However, it appears that they changed and at some point implemented strict RTP and now discard the packets resulting in one way audio. We could hear the caller, but they could not hear us.

So, they have provided me with two beta sets of firmware; neither of which has been successful. They have elected not to change the port translation strategy in general, but are trying to correct by implementing SIP ALG. They are trying to modify the SDP headers so that they can keep the port translation in place, but direct it back to the 3CX server correctly. Before, the headers were being altered as well. I have provided them with an account so that they can do their own testing as I was really getting overburdened with doing the leg work.

I must say that I have been impressed with their support as being only one person who has approached them on the issue, they have truly tried to respond to my concerns. I am hopeful that they will come up with a solution, but as time goes by, I wonder. The issue affects the 470+, 6020 and 407W, but am told by TP that they use the same strategy in the others. I only throw this out there should you start to see similar issues.

 

[vpaulo]

the solution is:
TURN OFF STUN server and request for stun server. (every 30 second system request external ip address). So it`s a fake. After unsuccessful request system simply turn off rtp communications.
see att file. It`s in Russian, but I think you`ll understand all.

Settings - Network - stun server.

Turn off stun request and use external ip address manually and network interface routed to this external ip address.

So try.

 

[easydone]

In my case outgoing calls also stopped after 32 seconds

I had changed the sip-port to 5059, without restarting services.
The clients were still registered to port 5060 after restarting the computer and registering the clients to port 5059 everything went well.

chris

 

[leejor]

You are responding to a post from two years ago.

Calls dropping after approximately 30 seconds is almost always the result of ACK not being received, for some reason, of which there can be a number, as you have discovered. That message will show in the 3CX activity log. A run of the Firewall Checker, (or in your case, a re-boot), will usually help pin-point the problem

 

[easydone]

Hi Leejor,

I have the habbit responding to old posts if my answer is different than the others.
Like I did yesterday, lots of people stumble on old posts and it's always handy to see all kind of differebt answers.

Cheers, Chris