This is something that i cant figureout what is going on and its really driving me crazy.

I have a very simple setup, 2 gateways with diferent distance so it works as a failover, 2 networks and 2 switchs, one for each. Recently we started using a sip trunk on our 3CX server, i just cant use my main gateway for it, if it registers, it will only work for a few hours at best, and then will loss registration and will never connect again. It goes unreachable.

So im using a mangle rule to force all outbound traffic to the sip provider IP route via the 2nd gateway, this works, mostly, but every now and then it will losse connection refuse to register, afer several days.

For a time i belived this to be a issue with my 1st gateway, maybe something is blocking VOIP traffic for 5060 port, as the sip trunk is using the default port.

But now i realise im having a similar issue with some of my external extensions, some (not all) of the external extensions has a timeout problem attemping to connect to my 3cx server using UDP, offcourse im using not standart ports for VOIP. But this is the strange thing, it is random, it may work for a while and it does unregister and never register again, and at the same time, all other external extensions conecting to the same UDP port have no issue.

I see in the firewall the packets coming from outside from those extensions but they never get to the server... on the server it recives nothing.

And this is the fun part... as the voip server support both TCP and UDP, switching the transport type from those extensions from UDP to TCP fixed the issue.

I dont understand, the packets are getting dropped on the mikrotik nat? This is very strange.

It could be due to firewall connection tracking settings. Default has these two settings:
I'm not familiar with how VoIP works, but settings above might be too short for some idle VoIP clients.

Solution would be either to enable sending keep alive packets (if VoIP system and clients support that) or to raise these two values (I guess the udp-stream-timeout might be the right setting to raise).

It could be due to firewall connection tracking settings. Default has these two settings:

Code: Select all

               udp-timeout: 10s
        udp-stream-timeout: 3m

I'm not familiar with how VoIP works, but settings above might be too short for some idle VoIP clients.

Solution would be either to enable sending keep alive packets (if VoIP system and clients support that) or to raise these two values (I guess the udp-stream-timeout might be the right setting to raise).

You can also make a receive line in NAT and secure it down to the addresses used by your VOIP provider. dst-nat

Setting udp-stream-timeout: to 5 mins and a few seconds should solve a lot of out of contacts.
You can look in the connections screen how often your VOIP sends a reconnect.

Please check the conntrack table in the firewall and remove any entries relating to the 3CX and the phones.

Also very strongly I would ask you to check that the SIP ALG is turned off on the router. 3CX can be setup to use STUN to help resolve NAT issues however for a more reliable setup with static NAT rules in and out (assuming you have a static public IP)

If you don't have static public IP Addresses check if your ISP is issuing new IP Addresses or anything else around the time you lose the service of those extensions (and double check there is no CGN being used - 100.64/12 IP Address)

Check that your configuration isn't falling into the traps mentioned in https://mum.mikrotik.com/presentations/ ... 948376.pdf these are all issues that can significantly limit your reliability of connection and with SIP one thing that has the biggest impact on traffic is reliability (and yes I know UDP is "connectionless").

If things burst back into life under TCP (assuming clearing the conntrack entries removal doesn't also burst things back into life) then check if you are dropping fragments for UDP or are handling things differently there? 3CX has a habit of flicking some things to TCP when they get big enough but it can also be coerced into fragmenting UDP in order to handle larger SIP messages in the dialog.

If traffic is captured in a packet sniff in the router try doing a capture of traffic on port 5060 and leaving the other fields unselected to capture to a file in the router, when you open it in wireshark then it will look a bit crazy as the packets should be repeated three times in the capture as they pass through the router (inbound interface, router processing, and outbound interface) which can help you see where in the process things are being dropped.

Let me know if I can help further, I have over four years experience working with 3CX in a Mikrotik environment (infrastructure and end user) so I can probably look into things a bit deeper and help further.

Regards
Alexander

Thanks, ill look into that. But im going to be away for the next week now.

The issue is now getting worse, i fixed remote extensions problems by switching to TCP for sip register, the SIP Trunk registration now it SEEMS to work on my main wan, ive added a mangle rule to "passtrought" all conections going to sip trunk ip, no problems with unreacheable sip trunk status for 2 weeks now.

But now i have a huge issue, outbound audio to my sip trunk drops randomly, it may be at 5 seconds, at 15 at 2 min or never. All i know this is getting far more common and it starting to happen faster and faster. Not sure if this was due to increase the UDP timeout to 35 seconds and UDP stream to 5 min or it was the passtrought or what... The 3CX is set to have nat keep-alive at 30 seconds this should not be happening.

Today i saw this viewtopic.php?f=2&t=35196 i cant access the router now since im out of the office but i need to check if there are zombie conections.

BTW this is always the outbound audio that cuts, the inbound audio always work. Also this issue is not present on my ATA... i have a ATA to connect two copper phone lines to the pbx, this issue dosent happens on the lines attached to the ATA, mainly due the ATA is on the same network and traffic is not going trought nat.

BTW2, yes, sip alg on mikrotik router IS disabled.