Excellent feature. Definitely should be added.
+1 excellent feature…
1 Like
Any update on this request?
We’ve had some interest from our members (~6,400 9-1-1 centers in the U.S. and Canada) in multi-WAN solutions for VoIP deployments. Haven’t seen any industry support yet, however.
Thanks!
Am I allowed to upvote this again?
+1 for any updates?
Trey,
Is this still an issue? I’m using a Balance 20 dual wired WAN with 5 Cisco SPA504G IP phones registered directly to the provider. I’ve tested WAN failures and my voip sessions continue with a brief interruption depending on health check settings.
Am I the only one with SIP phones that WAN failover currently works (doesn’t disconnect the calls) for? It’s nice to be special.
Cyclops, can you share any details about your setup? What provider are you using, and do you have any special configuration? I’m sure other members of the community would love to know.
1 Like
Sure. I actually switched from another dual WAN router to Peplink for this very reason. SIP failover between WANs simply didn’t work properly with my previous device.
-WAN1 60/4 cable HSI set to active. Static IP. Always on.
-WAN2 6/512k DSL set to active. DHCP. Always on.
-Five in office Cisco SPA504g IP Phones connected directly to provider (auto attendant, voicemail all hosted remotely)
-Anveo SIP trunking
-QoS highest priority for VOIP
That’s it. I tested it fairly crudely initially by pulling WAN cords with an active call on speaker and using a solid key tone. Initial set up where I had WAN2 set to backup caused a near 10 second delay before continuing the call. When I set WAN2 to active as well, the delay in continuing the call was 3-6 seconds.
Cyclops/Tim:
Calls-in-progress tend not to be the real issue, as SIP is pretty resilient to endpoint IP changes during a media session. The bigger issue is usually inbound calling after a change in external IP: The proxy or server at your provider’s end doesn’t have a way to detect the change in IP address, and so it tries sending INVITE requests to the non-working WAN IP until the phone re-registers either due to a reboot, or the expiration of its previous registration. Since the registration and call handling functions tend to be separate for many Broadworks-based providers (the dominant VoIP switching platform), even if a call-in-progress adjusts to the change and stays up, the proxy/server won’t necessarily follow suit.
If your provider has a set a very low interval between REGISTER requests, that might account for your not having any problems (assuming you don’t…it isn’t mentioned). However, most providers try to keep that interval as long as possible to reduce network overhead.
Having a proxy on the edge device solves all of these problems and can, in some circumstances, maintain internal communications during an all-WAN outage. It can also reduce your total bandwidth utilization, as is beneficial for metered or capped connections, by handling internal calls internally, without the involvement of your cloud-hosted IP-PBX provider.
Trey,
Thanks for the explanation. I’m afraid I still am confused about how this isn’t a proxy issue. I understand how the proxy is a benefit for reducing overhead internally and providing a several trunking options should provider 1 have temporary issues, but it seems that this then introduces this failure when external IP changes (WAN failure). Unless the proxy fails, the phones don’t automatically reboot. Shouldn’t the proxy act as the B2BUA device?
What about another way to handle this issue? Setting up DNS SRV SIP records that would handle inbound calls gracefully should link 1 fail? Or does would that not apply in this situation?
I have the phones I manage set with 180 second registrations. I believe when a WAN failure happens, the phones automatically re-register at the next interval, so there is a 3 minute period where inbound calls may fail.
Cyclops:
It sounds like you’re using an internal IP-PBX/Softswitch, so you wouldn’t experience the problems this feature request is intended to deal with, anyway. For most of us who don’t have the in-house IT mojo to support that kind of configuration (e.g., an Asterix box with SIP trunking), things work rather differently. We use a cloud-hosted softswitch provider (SimpleSignal). They handle all the provisioning, MACD, PSTN intercon, etc. and serve our handsets directly. Same goes for other providers like Nextiva, 8x8, etc. In that configuration, with an off-site switch, you really need the B2BUA or proxy on the edge device, since there’s a lot more signaling (and relatively less media transfer) going on.
T
Trey,
As I mentioned in an earlier post, we don’t use an internal Asterix box with SIP trunking. We use independent IP phone handsets connected directly to the trunking provider.
I must not understand the difference between our scenarios.
Any news on this voip issue?
We also suffer from long delays before the sip phones reauthenticate and we need to power them off and on after a disconnect
+1 - this would be a big help.
has anything been added to this topic? any feature set to Peplink that helps solve this issue with registration?
I personally don’t have this problem even with multiple WANs, apparently because we operate an Asterisk server on our LAN. For those of you who operate SIP handsets connected to an in-the-cloud server, this sounds like an ideal application for a remote Fusion Hub. You could go Fusion VPN to Fusion Hub provider, and then go from there on a reliable single IP to the SIP provider. That would likely add a bit to latency which is not a good thing for VoIP but would be worth a try if your local WANs go down frequently.
The ultimate configuration would be a SIP provider who maintains Fusion Hub at its data center. Are there any? SIP providers are an extremely competitive business. I bet if Peplink’s sales department made the case and some customers raised their hand, you would get a few providers to implement it. In particular I expect that Vitelity could be talked into it.
1 Like
That’s exactly what we are doing right now in our office. We have a Balance 305 with 2 WAN connections, then in our ISP data centre on vSphere we have FusionHub with our 3CX PBX. The latency from us to FusionHub is 1-2ms on the fibre and about 8-12 on average on the cable. I didn’t want to have our PBX in the cloud as I don’t like adding an extra hop, but since traffic routes through SpeedFusion for hot failover anyway I figure it adds nothing really by having the phone system in the DC with FusionHub. It works great, as then if a WAN link fails there’s no interruption on the calls at all. I’m also able to authenticate via Static IP even though our office has only dynamic IP addresses, since all voice traffic comes through FusionHub’s public IP.
Our SIP provider isn’t the same as our ISP but their equipment is in the same datacentre, so pinging our SIP provider from FusionHub is around 2-3ms.
3 Likes
+1 This would be a huge help for us!
We operate Fusion Hub in all 3 of our geo-redundant data centers for VoIP run off of FreeSwitch and it runs flawlessly. Just got done testing a few months back. Really cool stuff and no insane costs or not truly direct shots to data centers like most other SD-WAN providers. Thought I would share just to show that it is successfully spun up in live production environment.
1 Like