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.

Issues with Registration after STUN Change

Discussion in '3CX Phone System - General' started by dominicbatty, Feb 4, 2009.

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

    Joined:
    Jan 2, 2008
    Messages:
    29
    Likes Received:
    0
    I am having some problems with re-registration following an ISP failover scenario.

    Our example is as follows .... a 3CX Windows 2003 server with local IP 192.168.1.1 and a Draytek router with local IP 192.168.1.2 (default gateway for the 3cx server). The Draytek has two WAN interfaces, one on 111.111.111.111 and the other on 222.222.222.222. By default the Draytek routes all traffic via 111.111.111.111 but if this fails switches over and routes it via 222.222.222.222, a very nice failover mechanism to keep our VOIP system running.

    STUN queries from our 3CX server either return 111.111.111.111 or 222.222.222.222 depending on the Draytek's failover position. The Draytek is NATing the outbound traffic to the internet and everything works a treat until we fail over to the other ISP.

    Take this example ....

    3CX starts and queries the STUN server and gets back 111.111.111.111 (primary interface is working) so uses this in it's call setup, registration and call processing. It also registers with our VOIP provider who now knows to send incoming calls to us on 111.111.111.111:<port n> and everything works well.

    Now the 111.111.111.111 ISP fails so the Draytek switches over to the 222.222.222.222 circuit and this is picked up by the next STUN request (currently set to 5 minutes but can be increased to give quicker failover) which now responds with 222.222.222.222 and the 3CX system knows this external STUN IP has changed as it makes this comment in the log file.

    Resolved SIP external IP:port has changed to (222.222.222.222:42961) on Transport 192.168.1.2:5060

    However, our VOIP provider is still trying to send incoming calls to 111.111.111.111:<port n> but this circuit is now inaccessible from the outside world so incoming calls just appear dead to the caller. There are two ways round this, 1) we have to force a re-registration of the VOIP provider so they then know to send incoming calls to the newly resolved STUN IP on 222.222.222.222:42961 or b) wait for the re-registration timeout on the VOIP provider to occur and let this handle it but ours is currently set to 600 seconds (as recommended by our VOIP provider) and waiting for 10 minutes for failover is a little too long.

    If in the "VOIP provider > Advanced > Which IP to use in Contact Field" the value is set to "External (STUN Resolved)" then 3CX knows the moment a STUN amendment is made (which it is already aware of as per the log file) all registrations set to be externally stun resolved become invalid and should be re-registered - it does not appear to be doing this. You might suggest simply decreasing the re-registration timeout but our VOIP provider has advised against doing this.

    I was initially going to log this as an enhancement request but I actually think it is a bug so have raised it here.

    Regards, Dominic Batty.
     
Thread Status:
Not open for further replies.