EnSuring Voip Out WAN2

Explanation
My first attempt to deal with the potential issue when testing and switching my WANIPs back and forth for my VOIP connection was to turn service media off. I noted in a wireshark capture that the modem is smart enough to send (in the voip traffic) the WANIP that is associated with the lan to wan traffic. Thus in reality the layer7 sip ALG is not required. But since the modem seems to get lost with quick changes I felt it best to leave the layer7 SIP alg in place and working. I decided use dst nat to ensure any packets originating from the SIP server could reach the VOIP modem.
This could be the case if my IP goes down or dynamically changes or maybe if I decide to do PCC load balancing.
I figured for the most part the masquerade rules would handle correctly the normal out and back flow.
So find below the DST NAT rule I originally made (still in place).

/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface=Eastlink_eth1
add action=masquerade chain=srcnat comment="SCR_NAT FOR LAN USERS" \
    out-interface=vlanbell
add action=redirect chain=dstnat comment=\
    "Force Users to Router for DNS - TCP" dst-port=53 protocol=tcp
add action=redirect chain=dstnat comment=\
    "Force Users to Router for DNS - UDP" dst-port=53 protocol=udp
add action=dst-nat chain=dstnat comment="VOIP TRAFFIC" in-interface-list=WAN \
    log=yes log-prefix="VOIP Traffic" src-address-list=VOIP to-addresses=\
    192.168.0.35   {voip is domain name of sip server which resolves to an IP}

Then I decided to FORCE all voip traffic to WAN2. Thus I applied mangle rules as seen next.
I am not sure when and when not to use passthrough=yes. My understanding is that you keep passthrough=yes until that last marking rule…
The basic premise is to mark new connections coming from the modem (hence the no-mark - but is this really required???) heading for the internet (did this with extra tab item of destination address NOT local - is that right? does this mean that traffic from the modem not being forwarded to LANs etc…)??
In other words could I have ignored and not used (no mark) and simply used out-interface-list WAN, vice the fancy pants invert local extra tab item?? When and why to use things is never explained clearly.

/ipfirewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=HomeBridge new-connection-mark=\
    cm_voip passthrough=yes src-address=192.168.0.35
add action=mark-routing chain=prerouting connection-mark=cm_voip \
    in-interface=HomeBridge new-routing-mark=useEastlink passthrough=yes \
    src-address=192.168.0.35

Finally I had to route the traffic see below. My concern is what will happen if WAN 2 goes down.
Im assuming im covered as that route wont be routable and the router will search for another path???
..

/ip route
add check-gateway=ping distance=2 gateway=8.8.4.4
add check-gateway=ping distance=3 gateway=208.67.220.220

add distance=2 dst-address=8.8.4.4/32 gateway=bbb.cc.40.p scope=10  {my Fiber gatewayIP}
add distance=3 dst-address=208.67.220.220/32 gateway=bbb.cc.40.p scope=10
add distance=10 gateway=24.xx.yyy.1  {my cable gatewayIP WAN2}

add comment=Email_bypass distance=1 dst-address=24.222.0.20/32 gateway=\
    24.xx.yyy.1
add distance=1 gateway=24.xx.yyy.1 routing-mark=useEastlink

Wow 62 views and no comments and I know some of you knew better but not mentioning any cough cough (sindy, czfan) names.
But the issue is amazingly described here in what I would call the post of the decade!!
https://forum.mikrotik.com/posting.php?mode=reply&f=2&t=129048

The issue is resolved using the above thread… Hopefully mikrotik will fix the engine issue!!!

The link you posted is a reply link not a reference link.
The correct link is http://forum.mikrotik.com/t/sip-client-cannot-re-register-in-the-sip-server-after-switching-isp-different-nat/115091/1

@rarylson provided the best 2 options IMO and rarylson superb explanation of the issue is OUTSTANDING.
I41 do not believe its an ENGINE issue and I would not expect MikroTik to sacrifice performance with a engine KLUDGE.like many others have done.

I disagree I see no solution offered that is practical and would work for me.
I am much better off going to the modem vendor, obihai and seeing if I can modify the reset timing built within the modem.

Obi configs are completely open and you can change any parameter you wish too … if you use ObiTalk you can edit the config of the ATA via the advanced option … there are a gazillion configuration options that can be set. If you do not use ObiTalk then you access the config locally but you have to be on the same subnet.

Netwatch looks like an interesting approach to help with your VoIP issue http://gregsowell.com/?p=819