SIP ALG (SIp Passthrough) and Outbound Policies

[ngefvert]

@TK_Liew

Hi ngefvert.

Enable/Disable SIP ALG will not overwrite the routes you defined in Outbound Policy.

1. Can you share how you noticed SIP traffic was going into WAN1 and WAN3? Possible to provide screenshot on this?

These are logs from our SIP providers. Our CDR reports show the source IP for every outbound call we make. For example, I just checked one provider and of 81 calls out in the last 24 hours, all of them went out over WAN 1, which is the secondary priority for that outbound policy. WAN 2, which is the highest priority for that policy, has been up that whole time. I can provide a screenshot but because we present customer ANI’s and the destination numbers are confidential, i’d have to scrub a lot of it.

@TK_Liew

2. Possible to share the screeshot of your Outbound Policy (Network > Outbound Policy > Rules)?

So for example, I just made a test call out via Flowroute. That call went to sip.flowroute.com, and so should go out via NETCARRIER, which is set to enforced for that policy (so terminate session link on recovery does not come into play). Their logs show the call coming from a COMFIBER IP. Even if for some reason the Peplink did not match that traffic as going to sip.flowroute.com, then since the traffic was originating from the .219 address in the rule below, it should have gone out over NETCARRIER anyways.

For the 81 calls in the last 24 hours I mentioned above, they would have gone out over a different SIP provider, but originated from the .219 address, so that rule should have routed that over NETCARRIER as well, but it went out over COMFIBER.

The 3 Adtrans see the same behavior where they would route over the VZFIOS instead of their primary of COMFIBER, but the mailservers and outbound test machine (first rule) work properly.

@TK_Liew

3. I do agree with Don. Please enable Terminate session on link recovery to see any different.

I just set this to ON for the FreePBXtoWorld rule, and the SIP traffic appears to be routing properly - but that stirs up some more questions:

1. ‘Terminate session on link recovery’ is not an option for the ‘Enforced’ rule for the Flowroute traffic, but enabling it for the rule below it also affected that. So even though that enforced rule was above the other one, it wasn’t being obeyed because of an established session matching that lower rule?

2. We have never used this function before (Sonicwall has a similar feature for outbound load balancing) to try to prevent the following case: Primary WAN goes down and so outbound traffic fails to the secondary one. Call is established during that time, and then the primary WAN comes back up, so now that call is interrupted as the Peplink starts routing traffic out over the primary WAN again, and the carrier sees RTP packets coming from an IP that didn’t establish that call. Or will the there be another SIP handshake to say ‘now my RTP is coming from this new IP’?

3. I had thought that it was a problem with the established sessions in the Peplink not expiring and keeping sessions going over the lower priority WAN’s, so one of the things I had tried was disabling the other WAN connections for 10 minutes. Traffic routed over NETCARRIER properly during that time, but then as soon as I enabled them again SIP traffic would resume going out over them… That was with this identical setup, so I have no idea why this was occurring.

4. Is it the low qualify frequency on our trunks keeping the sessions open? I guess if I set the qualify frequency to at least 2 times the UDP session timeout in the Peplink (what is that by the way) then during low traffic periods overnight the sessions would terminate, and I may not need to worry about the ‘Terminate session on link recovery’ option, correct?

Thanks for all the help so far…