I'm trying to connect some sip phones to our PBX. The worked fine for about 10 minutes and then they lost connection. I needed to disable sip helpers to get them to register in the first place but now they wont register at all, but I do see this line in my firewall logs over and over again:

[dsnat: in:wan out:(unknown 0), src-mac 11.11.11.22.33.44, proto TCP (SYN), 31.32.33.12:519111->192.168.20.10:5060, len 60]

where 31.32.33.12 is our public ip
where 192.168.20.10 is the address of our Wan
and our internal ip subnet is 192.168.0.0

It seems like voip traffic is not getting to our Lan.

Any advise?

Do you have a destination nat rule for you PBX? Something like:

Do you have a destination nat rule for you PBX? Something like:

Code: Select all

/ip firewall nat add chain=dst-nat dst-address=192.168.20.10 protocol=tcp dst-port=5060 to-address=192.168.0.5

This sounds like the PBX is "hosted" in a DC or another location, so that's not going to work as there would be multiple phones listening on port 5060 for their respective IPs and thus you just can't NAT those ports to specific IPs.

However, if your phones are no longer receiving inbound calls after 10 minutes, can they make outbound calls? If so, you have a NAT issue and you should show what you have going on. I run sites with numerous phones behind Mikrotik routers and tend to not have these issues at all. But like I said, if after this 10 minute mark the phones can make outbound calls but can't receive inbound or start having inbound audio issues then it's 100% NAT.

Thanks, No it's not hosted in a DC. The PBX is a standalone PBx connected to a microtik router and a couple of onsite ip phones on the same router. It's the off site phones that are being blocked.

Whats strange is that if I turn on the SIP helpers the Offsite phones register immediately, however if I try and call them or they any other extension they get an error. If I turn off the SIP helpers we get a minute or two of working phones then they loose connection and deregister..

I'll try opening up that nat route now.

Thanks, No it's not hosted in a DC. The PBX is a standalone PBx connected to a microtik router and a couple of onsite ip phones on the same router. It's the off site phones that are being blocked.

Whats strange is that if I turn on the SIP helpers the Offsite phones register immediately, however if I try and call them or they any other extension they get an error. If I turn off the SIP helpers we get a minute or two of working phones then they loose connection and deregister..

I'll try opening up that nat route now.

OK so you have phones that are "remote" to the PBX. The context of my statement still applies. What router is being used at the site where the phones are? Because that's where this needs to be looked at.

So you have Phones/PBX -> Mikrotik -> The Interwebs -> Other Router -> Remote Phones. Now when the PBX sends a call to those remote phones, it is the router in front of the phones that is having the NAT issue. Do you have a Mikrotik at that site as well? Because right now the Mikrotik in front of the PBX isn't the issue. You need to be looking at where the remote phones are.

What is the setup where the remote phones are located?

Hi, have you tried to disable the /ip firewall service-port sip ?

If you have: Phones <--> Mikrotik <---> Internet <---> Mikrotik <---> PBX then set up the nat rule as mentioned for the PBX mikrotik. Leave SIP Helpers ON for both Mikrotiks. Or tunnel so NAT and PAT are not in the mix.

If you don't have control of the router in front of the phones, then there are too many variables and you should consider sending your own router for your phones to tunnel back.

SIP-Helpers analyze the SIP packets passing through a router. The SIP packets establish ports and ips to for audio/video. Sip Helpers replace private IPs, and adjust ports if the router will be doing port translation. Mikrotiks do this well.

Some routers (I think Sonicwall?) will do Port Latching where it detects if Port Translation is happening and tries to accommodate for it. This "feature" can cause issues if both sides are trying to detect and accommodate for each other. Sonicwalls will do port translation and revert back to it's original port. If the other side does port latching, then now you have audio problems.

Then there is PAT. It's totally legit for a router to alter src-ports as it needs. In some routers PAT may always happen. This will cause audio channels to not get established (unless the other side supports port latching).

With SIP Helpers on, you say your phones register for a few minutes. Maybe at some point it also expects to see an RTP channel to work and de-registers if it can't.

Too many variables.

Concur, but for a good appreciation of SIP traffic and mikrotik SIP services, I really suggest reviewing this presentation which may very well answer your questions and issues!!
https://mum.mikrotik.com/presentations/ ... 084451.pdf

If the issue is one of performance and prioritizing sip traffic then this seems useful.
https://mum.mikrotik.com/presentations/ ... 512668.pdf