Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

3cx External Ext. disconnect after 32 seconds.

Discussion in '3CX Phone System - General' started by gordontor, Aug 16, 2014.

Thread Status:
Not open for further replies.
  1. gordontor

    Joined:
    Jul 6, 2013
    Messages:
    14
    Likes Received:
    0
    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.
     
  2. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    11,105
    Likes Received:
    329
    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.
     
  3. gordontor

    Joined:
    Jul 6, 2013
    Messages:
    14
    Likes Received:
    0
    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.
     
  4. gordontor

    Joined:
    Jul 6, 2013
    Messages:
    14
    Likes Received:
    0
    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:110@11.22.33.44. The DMZ is on for my server IP, and the 5060 port is configured to my server IP.
     
  5. gordontor

    Joined:
    Jul 6, 2013
    Messages:
    14
    Likes Received:
    0
    I didn't change anything. 2 hours later, I ran the firewall checker again, the 5060 result was "success", and the problem also disappeared.
     
  6. maingate

    Joined:
    Jul 25, 2014
    Messages:
    9
    Likes Received:
    0
    we have the same problem but then with 3CX version 9
    is there a solution? of a idea where we can find it?
     
  7. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,379
    Likes Received:
    84
    What Router/Firewall have you got between the PBX and the WAN?
     
  8. gordontor

    Joined:
    Jul 6, 2013
    Messages:
    14
    Likes Received:
    0
    I tried some routers, 3 D-links, an SMC, and some TP-Links. Only TP-Links work well.
     
  9. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    11,105
    Likes Received:
    329
    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
     
  10. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,086
    Likes Received:
    64
    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.
     
  11. vpaulo

    Joined:
    Jun 24, 2009
    Messages:
    23
    Likes Received:
    0
    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.
     

    Attached Files:

    • 3cx.png
      3cx.png
      File size:
      16.8 KB
      Views:
      1,412
  12. easydone

    Joined:
    Nov 22, 2016
    Messages:
    8
    Likes Received:
    0
    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
     
  13. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    11,105
    Likes Received:
    329
    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
     
  14. easydone

    Joined:
    Nov 22, 2016
    Messages:
    8
    Likes Received:
    0
    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
     
Thread Status:
Not open for further replies.