SIP Dual Wan 378.56 and 378.56_2

[pendetim]

I have a Asus Rt-AC66W configured as a dual wan in load balance mode; Primary is Cable and Secondary is Verizon DSl PPPoE.

The configuration is both WAN connections are active all the time and there is a 9:1 ratio set in the speeds for the load balance.

If I fail either the cable WAN or the DSL WAN traffic routs over to the active WAN and will revert when I restore the failed WAN. All is good for that.

The problem occurs with SIP based VoIP. I have several VoIP adapters that are set by routing rules to use the secondary WAN. As long as the secondary WAN is active, this rule is obeyed. If the secondary WAN fails, the VoIP adapters will revert to the the primary WAN as expected. The problem I am having is that when the secondary WAN is restored, the VoIP adapters loose registration and stay unregisterted for hours and hours. Rebooting the adapters does not fix the problem, It seems the only way I can get the adapters to re-register is to either reboot the Rt-AC66W or fail the primary WAN.

The VoIP adapters are a mixture of models: an OBI 100, a Linksys PAP2 and a Linksys SPA942. so it is not model specific. VOIP.MS is my provider.

This behavior is consistent between 378.56 and 378.56_2.

Is there a setting or someting somewhere I am missing?

Tim

 

[A.D.]

I have several VoIP adapters that are set by routing rules to use the secondary WAN. As long as the secondary WAN is active, this rule is obeyed. If the secondary WAN fails, the VoIP adapters will revert to the the primary WAN as expected. The problem I am having is that when the secondary WAN is restored, the VoIP adapters loose registration and stay unregisterted for hours and hours. Rebooting the adapters does not fix the problem, It seems the only way I can get the adapters to re-register is to either reboot the Rt-AC66W or fail the primary WAN.

The VoIP adapters are a mixture of models: an OBI 100, a Linksys PAP2 and a Linksys SPA942. so it is not model specific. VOIP.MS is my provider.

Not familiar with the routing mode you use, but unless you have a SIP proxy there in your router, how could it contribute to the problem?

I'd look at the SIP device log files first and presume that the VoIP provider may be part of the problem. Does it allow several clients for the same account in parallel? If not, how does it handle a new registration before the old expires?

In my WAN failover cases, SIP matters stabilise pretty quickly. But my SIP provider does allow for several clients which register with the same account.

 

[pendetim]

Not familiar with the routing mode you use, but unless you have a SIP proxy there in your router, how could it contribute to the problem?

I'd look at the SIP device log files first and presume that the VoIP provider may be part of the problem. Does it allow several clients for the same account in parallel? If not, how does it handle a new registration before the old expires?

In my WAN failover cases, SIP matters stabilise pretty quickly. But my SIP provider does allow for several clients which register with the same account.

I have the 4 devices on separate "sub-accounts" with VOIP.MS. so concurrent registrations are achieved through these independent sub-accounts. Each sub-account has it's own login username/password.

Once the devices register, they are very stable, until that is the WAN they are using drops.

I have also tried the Dual WAN failover-fail back mode. The devices register on the active WAN, I drop the active WAN and the Backup WAN connects and the devices register. However when I reconnect the Primary WAN the secondary disconnects, as it should, and all traffic except VoIP passes through the Primary WAN.

 

[A.D.]

I have the 4 devices on separate "sub-accounts" with VOIP.MS. so concurrent registrations are achieved through these independent sub-accounts. Each sub-account has it's own login username/password.

I'm not familiar with the details of this provider here but I don't see how what you mention supports concurrent registration of the same VoIP client. For the VoIP provider, if the public IP address changes, it looks as if a second device of the same type registers with the same sub-account. Since the IP adddress for all four VoIP clients changes at the same time, ´for the provider it may look as if there are two times four clients in parallel.

Either way, the client logfiles would be the first thing I look at, and your clients will certainly allow for some kind of registration refresh interval. You may want to set that to a shorter time. And also, look at the status page of your provider when a failover takes place. That's what you can do on your side.