Hello All!

We are having a weird issue and I am about out of ideas.

About 2 weeks ago we swapped out an old Cisco ASA (Config attached) with Mikrotik 3011. This customer has VOIP phones that connect to a cloud PBX. Shortly after we swapped the router one of their phones (EX 101) stopped working. They contacted the provider and they had them re-provision the phone. It is a Polycom VVX 400. Re-provisioning did not fix it so they rebooted the Mikrotik and the phone started working. When that one started working though, another stopped. This time EXT 102. They went through the same process and re-provisioning did not fix it. They rebooted the router and again it started working but a third phone (EXT 103) stopped. At this point they called us.

I have looked at the phone and I can see where it is actually pulling the config from the provisioning server but it is failing to register. The customer is convinced that it is a router related issue since rebooting the router got phones online and the VOIP company is sure it isn’t something on their side. The tech said he can see where is it pulling the provisioning files.

When I built the configuration for the Mikrotik there were only 4 ports allowed through the firewall, 25, 443, 80, and 3389. All going to their old server (which is still in place). The Sharpen tech said they need TCP/UDP 5060-5081 allowed and UDP 10,000-20,000 allowed so I created those and can see traffic hitting those but it did not resolve the issue. And the fact that some phones will register fine, it doesn’t make sense. I also went into IP>Firewall>Service Ports and disabled SIP as I read this is the SIP helper that is similar to SIP ALG and is recommended to be disabled. Since other phones are actually registering, this didn’t really make sense, but I am reaching at this point.

Any thoughts?

Did disabling the SIP ALG make any difference to the observed behaviour?
You need a packet capture of a phone that is failing to register. SIP is quite readable in Wireshark.

Hi,

as troffasky already stated, most of the time these issues occur in conjunction with ALG settings.
Another thing to look at: As the firewall is stateful and UDP (which is used fpr SIP) is stateless, the firewall emulates stateful UDP connections by maintaining timers for those UDP connections. As SIP also maintains timers for several purposes, make sure the values of the firewall connections timers match or exceed the timers used by your SIP implementation.

Regards,
ape

If rebooting the router fixes the connections for you, as a workaround, drop the active connections every hour:
Scheduled:
I had to apply the same fix to a ZyXEL router which would keep the connection tracking in table forever.
As SIP phones tend to keep the same source port this would result in unsuccesful registrations.

Active conversations will not be affected as SIP is used for signalling only.

Did disabling the SIP ALG make any difference to the observed behaviour?
You need a packet capture of a phone that is failing to register. SIP is quite readable in Wireshark.

Disabling SIP ALG did not make any noticeable difference. The phone still failed to register.

If rebooting the router fixes the connections for you, as a workaround, drop the active connections every hour:

Code: Select all

/ip firewall connection remove [ find where protocol=udp and dst-address="1.2.3.4:5060" ]

Scheduled:

Code: Select all

/system scheduler
add interval=1h name=reset-sip-conn on-event="/ip firewall connection remove [ find where protocol=udp and dst-address=\"1.2.3.4:5060\" ]" policy=read,write

I had to apply the same fix to a ZyXEL router which would keep the connection tracking in table forever.
As SIP phones tend to keep the same source port this would result in unsuccesful registrations.

Active conversations will not be affected as SIP is used for signalling only.

I did find this listed in several forums as a possible solution but I went in and killed all active connections for the specific phone and it still failed to register. I am not sure this will resolve the problem, unfortunately.

Hi,

as troffasky already stated, most of the time these issues occur in conjunction with ALG settings.
Another thing to look at: As the firewall is stateful and UDP (which is used fpr SIP) is stateless, the firewall emulates stateful UDP connections by maintaining timers for those UDP connections. As SIP also maintains timers for several purposes, make sure the values of the firewall connections timers match or exceed the timers used by your SIP implementation.

Regards,
ape

Is that the timers listed under tracking in IP>Firewall>Connections? Specifically, the UDP Timeout vs the UDP Stream Timeout?

Hi,

yes, these two values are especially relevant for SIP/RTP.
I can't give a general advice which values to set in your case, but it's worth trying to slightly increase these values.

Furthermore, have a read of this thread: viewtopic.php?t=85039

Usually, the problem is the "keep alive" of the NAT mapping.
Do you have the possibility to periodically re-register your phones?

I'm using freeswitch and periodically re-registering my public extensions to the providers SIP gateway solved the problem for me as it keeps the NAT mapping in the router.

Regards,
Ape

Hi,

yes, these two values are especially relevant for SIP/RTP.
I can't give a general advice which values to set in your case, but it's worth trying to slightly increase these values.

Furthermore, have a read of this thread: viewtopic.php?t=85039

Usually, the problem is the "keep alive" of the NAT mapping.
Do you have the possibility to periodically re-register your phones?

I'm using freeswitch and periodically re-registering my public extensions to the providers SIP gateway solved the problem for me as it keeps the NAT mapping in the router.

Regards,
Ape

I believe they re-register every 240 seconds, according to the vendor. Unfortunately, they were pre-existing before we installed the router and were unknown to us. We are just doing a new server project for this customer so we didn't have much reason to question their phones. I feel like if it was a connection tracking issue we would get the phone to at least register sometimes. I can't even get it to register once. I will check out that link, thank you.

I believe they re-register every 240 seconds, according to the vendor.

Change this to be less than 180 seconds, say 120. The remote server maybe terminating them. MikroTik's timeout is 300. Linux is 180 I think.

I believe they re-register every 240 seconds, according to the vendor.

Change this to be less than 180 seconds, say 120. The remote server maybe terminating them. MikroTik's timeout is 300. Linux is 180 I think.

Are you talking about on the phone itself?

Are you talking about on the phone itself?

Yes

Are you talking about on the phone itself?

Yes

I will try this, thank you!