SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back
-
Okay, I am alive again..
Anyway @taurex your phones are not switching back because they are maintaining the NAT translation and thus the router is not forcing them back. If your WAN2 dropped momentarily, then the router would have no choice but to drop the existing NAT and thus the phones would reregister out the WAN1.
The problem here is your router doing the load balancing not forcing an existing connection to switch.
-
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Okay, I am alive again..
Anyway @taurex your phones are not switching back because they are maintaining the NAT translation and thus the router is not forcing them back. If your WAN2 dropped momentarily, then the router would have no choice but to drop the existing NAT and thus the phones would reregister out the WAN1.
The problem here is your router doing the load balancing not forcing an existing connection to switch.
Isn't this usually expected though? I know it's possible to force the connection to switch back (had this setup at the ISP level at my last gig) but it's costly and really had no benefit. IE we weren't on a metered connection, the performance was the same for both ISPs etc.
-
@dustinb3403 said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Okay, I am alive again..
Anyway @taurex your phones are not switching back because they are maintaining the NAT translation and thus the router is not forcing them back. If your WAN2 dropped momentarily, then the router would have no choice but to drop the existing NAT and thus the phones would reregister out the WAN1.
The problem here is your router doing the load balancing not forcing an existing connection to switch.
Isn't this usually expected though? I know it's possible to force the connection to switch back (had this setup at the ISP level at my last gig) but it's costly and really had no benefit. IE we weren't on a metered connection, the performance was the same for both ISPs etc.
The problem here is that the failover is a 4G connection. They latency there is never going to be good. It is ok for a failover, but not long term use.
-
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@dustinb3403 said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Okay, I am alive again..
Anyway @taurex your phones are not switching back because they are maintaining the NAT translation and thus the router is not forcing them back. If your WAN2 dropped momentarily, then the router would have no choice but to drop the existing NAT and thus the phones would reregister out the WAN1.
The problem here is your router doing the load balancing not forcing an existing connection to switch.
Isn't this usually expected though? I know it's possible to force the connection to switch back (had this setup at the ISP level at my last gig) but it's costly and really had no benefit. IE we weren't on a metered connection, the performance was the same for both ISPs etc.
The problem here is that the failover is a 4G connection. They latency there is never going to be good. It is ok for a failover, but not long term use.
Yeah, I was just responding to this is "normal" you'd have to force a fail-back when the other connection comes back up.
-
@dustinb3403 said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@dustinb3403 said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Okay, I am alive again..
Anyway @taurex your phones are not switching back because they are maintaining the NAT translation and thus the router is not forcing them back. If your WAN2 dropped momentarily, then the router would have no choice but to drop the existing NAT and thus the phones would reregister out the WAN1.
The problem here is your router doing the load balancing not forcing an existing connection to switch.
Isn't this usually expected though? I know it's possible to force the connection to switch back (had this setup at the ISP level at my last gig) but it's costly and really had no benefit. IE we weren't on a metered connection, the performance was the same for both ISPs etc.
The problem here is that the failover is a 4G connection. They latency there is never going to be good. It is ok for a failover, but not long term use.
Yeah, I was just responding to this is "normal" you'd have to force a fail-back when the other connection comes back up.
If you have SD WAN you might not need to do that but again given that is probably not available to the OP, it is something to keep in mind though. @Phil-CommQuotes usually has a good idea on the options.
-
Did you set it up where it only uses the second connection if the primary fails? Did you set up static routes with priority for the phones?
-
Here is a script you can use on the EdgeMax to handle this. but no clue on a USG.
https://community.ubnt.com/t5/EdgeMAX/WAN-failover-ERlite/m-p/2267413#M199728
-
@mike-davis said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Did you set it up where it only uses the second connection if the primary fails? Did you set up static routes with priority for the phones?
You are horribly over complicating this.
It is almost certainly the conntrack table not dropping a connection for no reason.
-
Thanks everyone for your advice and suggestions. It looks like, despite the Yealinks still register with WAN2's IP, all packets including SIP use the WAN1 to reach the hosted PBX. I'm not sure how the hosted PBX sends out the SIP traffic back to the phones, though, but the counters on WAN2 show a very little amount of sent and received packets, much less than a typical SIP traffic for a day there.
When I disable WAN2 the phones have no trouble re-registering with the main WAN. The problem is the soft fail-back when WAN2 doesn't get disabled, it just gets a higher metric on the USG routing table. Last time when the 4G data expired, all Internet traffic was unaffected except the phones.
I do like Unifi Controller in terms of remote management but the WAN fail-over feature seems to be too raw at the moment. -
@jaredbusch Thanks for this link. I'll give it a try. I hope UBNT did not trim the CLI down too much on the USG. I now better understand why Edge series is still the prefered choice for deployment among many
-
@taurex said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch Thanks for this link. I'll give it a try. I hope UBNT did not trim the CLI down too much on the USG. I now better understand why Edge series is still the prefered choice for deployment among many
Especially now that UNMS is available, that's pretty slick.
-
@taurex said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch Thanks for this link. I'll give it a try. I hope UBNT did not trim the CLI down too much on the USG. I now better understand why Edge series is still the prefered choice for deployment among many
Sadly, there is no way to force a single port offline via the UniFi controller that I am aware of.
You will have to log into the CLI.
The CLI is identical. The thing that is different is the configuration design. The /config folder might still exist, if so this will work for you.
-
@scottalanmiller said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@taurex said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch Thanks for this link. I'll give it a try. I hope UBNT did not trim the CLI down too much on the USG. I now better understand why Edge series is still the prefered choice for deployment among many
Especially now that UNMS is available, that's pretty slick.
UNMS 0.12.0 (currenlty in alpha) will add the CLI to the web interface.
-
@jaredbusch said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@scottalanmiller said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@taurex said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
@jaredbusch Thanks for this link. I'll give it a try. I hope UBNT did not trim the CLI down too much on the USG. I now better understand why Edge series is still the prefered choice for deployment among many
Especially now that UNMS is available, that's pretty slick.
UNMS 0.12.0 (currenlty in alpha) will add the CLI to the web interface.
That's very exciting. So much good stuff happening with UNMS.
