SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back
-
Hi All,
I'm having a rather interesting issue here. There is a Unifi network I recently set up with dual WANs. One is the main one - PPPoE WAN1 (FTTP) and another is WAN2 in a failover mode using a Dovado Tiny AC router in bridge mode with a Huawei E3372 4G USB modem. There is also a couple of SIP phones - Yealink T46S and T48S, all on a single LAN registered with a Cloud Asterisk-based PBX. When WAN1 failovers to WAN2, the Yealink SIP phones easily re-register with a 4G public IP but when Unifi fails back to WAN1 the phones still keep WAN2 IP registration even though every 120 seconds they re-register with the cloud PBX. After a fail-back, traceroute from the USG to the cloud PBX shows that the traffic is, indeed, exiting via WAN 1 but on the Unifi controller dashboard, it still shows the WAN2 public IP as the gateway address.
Has anyone experienced any such behaviour with a similar setup? Is this usual for SIP registered phones to specifically route VoIP traffic out of WAN2, even though all other traffic has failed back to WAN1? Or is SIP registration process separate from the actual route the SIP traffic uses to reach the hosted PBX? Why the default gateway on Unifi controller dashboard still shows WAN2 public IP after it's failed back to WAN1, is this a Unifi bug? Thanks.
-
So it is only on the dashboard that it is showing the second WAN still in use?
-
Was D&D night and I am drunk.. I will read this again tomorrow....
-
@scottalanmiller It also shows on the hosted PBX (Maxotel) side as well. I only have access to their customer GUI but in the extensions tab, it shows as both are registered with the WAN2 public IP address. I called the cloud PBX's support lately and they confirmed this but didn't provide any solution apart from suggesting to mirror one of the desk phone's port on the switch and do a packet capture with Wireshark but I did not get to that yet as this is a new remote site.
-
So I assume that WAN 2 is still active. What is forcing the fail-over mechanism in this case?
-
@taurex said in SIP Desk Phones Not Re-Registering with Main WAN's IP After WAN Fail-back:
Hi All,
I'm having a rather interesting issue here. There is a Unifi network I recently set up with dual WANs. One is the main one - PPPoE WAN1 (FTTP) and another is WAN2 in a failover mode using a Dovado Tiny AC router in bridge mode with a Huawei E3372 4G USB modem. There is also a couple of SIP phones - Yealink T46S and T48S, all on a single LAN registered with a Cloud Asterisk-based PBX. When WAN1 failovers to WAN2, the Yealink SIP phones easily re-register with a 4G public IP but when Unifi fails back to WAN1 the phones still keep WAN2 IP registration even though every 120 seconds they re-register with the cloud PBX. After a fail-back, traceroute from the USG to the cloud PBX shows that the traffic is, indeed, exiting via WAN 1 but on the Unifi controller dashboard, it still shows the WAN2 public IP as the gateway address.
Has anyone experienced any such behaviour with a similar setup? Is this usual for SIP registered phones to specifically route VoIP traffic out of WAN2, even though all other traffic has failed back to WAN1? Or is SIP registration process separate from the actual route the SIP traffic uses to reach the hosted PBX? Why the default gateway on Unifi controller dashboard still shows WAN2 public IP after it's failed back to WAN1, is this a Unifi bug? Thanks.
It is usual to keep the WAN2 Public IP for registration until the register again, that's what SIP registrations do.
-
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.
