Sometimes my SIP device's don't register until I delete the connection. The connection to delete is UDP 5060.

Is there are any timer I can change to prevent this happening or renewing the connection from time to time to avoid this problem? Is there a script I can run?

I already changed the: Firewall|Connections|Tracking: UDP Timeout:1d 00:00:00 to 00:01:00. And is not solving the problem.

If I go to Firewall|Connections| I can delete manually that connection and it works, but I need something automatic, instead of doing this for each device in every router....

THX.

have you tried playing with 'Firewall->Service Ports->sip' state?

Yes, it is enabled the SIP service on ports 5060 ad 5061.

I have this problem with my SIP connections when one of my gateways fails, lost Internet Connection for a moment, change of IP, etc. and then I need to move the connected SIP connections over to the other interface, or deleting that specific connection and it will reconnect immediately after deleting that "freezed and not Real Connection". I even can disconnect my SIP device and it still appears that the connection still working... until I do the "IP - Connections - Connection Remove" It will work again as fast as I connect the device again, or if it´s already connected It will work immediately.

THX, for your help.

oh, I see... it's NAT problem. you may delete connections by something like

Thats correct, but the problem is that this is happening very often, and some Routers are in a Remote area, so I want to write a Script in each device, to do this automatically, is there a way instead of doing it manually every time?

Thx.

what if you remove connection while SIP device is in work?..

It will Reconnect automatically, and it will work again in 2 seconds.

2 seconds is too long for periodic action... so you need to determine link reconnection in some way...

I was planning to run this script every 30 minutes or every hour, thats enough for the service they need, and It will keep them connected. But I´m not so sure how to write that script. The time I checked with them right now, and They say it is automatic, they removed the connection and immediately they got the green light on the device, meaning that they are connected again.

Script:

:put [/ip firewall connection remove [/find where src-address~"1.1.2.6"] ]


Where 1.1.2.6 is the src. address and 192.168.2.200 is the Dst. Address.
is that correct?

well, if 192.168.2.200 is the address of your SIP server, then it's better to use , I believe

i think there is more going on here that we need to investigate. We have the same issue periodically and a router reboot seems to help it for a few weeks. im wondering if there is a problem with the connection tracking somehow. you shouldnt need to be removing connections manually, especially UDP, they should just flow thru.

changeip, are you using NAT in that config?

yes. worked fine for many years in same config setup, until just recently i replaced this offices x86 with a routerboard. have seen it in multiple locations with routerboards so far, all using nat. typically i assign a sip control port and a range of rtp ports for each phone behind nat so i dont need helpers, etc. same configs, just later versions of MT i am seeing more of this. sip helper disabled cuz it always seems to break things : )

i forgot to mention, it seems to only happen 1 min into the conversation, probably matching the udp timeout setting maybe. will packet sniff and investigate more now that i know others are having same issue.

I thought, canuno's problem is that when router's IP changes, it still does NAT to previous IP...

THX for your interest and help. I really appreciate your advice for this issue.

you are welcome =)

There is definately an issue with the Mikrotik maintaining and tracking a SIP connection. Obviously becomes more of an issue with multiple NAT's. For some reason, different SIP kit seems to manage/handle this better, but we have found that specifically with Quintum kit, everything breaks.

This was my solution, and I run it every 5 minutes through the scheduler... Workaround works and clients satisfied.

:foreach i in=[/ip firewall connection find dst-address~":5060" protocol~"udp"] do={
/ip firewall connection remove $i
}

HI

We have the same problems and it is only fixed by deleting the connection. I will try this script.

Dolf

I tried the script but it doesn't work. I did include an ip address. I don't see anything in my logs te help me find the fault.

Thanks

Dolf

Yes, I Got the same result, I hope they can fix the bug in a new version, instead of trying to delete connections or restarting the router every week or something like that....

THX.

I tried the script but it doesn't work. I did include an ip address. I don't see anything in my logs te help me find the fault.

Thanks

Dolf

This problem is an old one in the Linux world. I reported it many years ago but it seems there is still no solution inside kernel 2.6.

It is related to the way connection tracking and maskerading does work. It was present with Linux 2.4 but is still here with Linux 2.6.


It does show up mainly when there is NAT masquerading.

- if there is multiple gateways used for redundancy (connection tracking keep the old public IP when the gateway change)

- the gateway is a PPPoe connection (in this case sometimes Linux can forget to masquerade and you send a private IP to the world. Does exhibit if you are sending SIP or IAX frames through the PPP connection during PPP disconnects).



The solutions are (from easier to harder) :

- do not use multiple gateways with NAT masquerading

- avoid using PPPoe. Prefer IPoA, MER, MPLS or native Ethernet xDSL links.

- use a firewall who is friendly with NAT and multiple gateways support (usually found in a session border controller)

- use static NAT instead of masquerading and change the static NAT IP address according to the used gateway

- reset the ghost connection after gateway change using for example netwatch and a script

- ask mikrotik to do something for you

- change your VoIP system for a traditionnal TDM system

Has there been any progress with this?

We are running RouterOS 5.7 and have had this problem since 3.30.

Its not just NATing, we have the same issue with routing.

We have SIP clients trying to connect to the SIP server over a VPN. However, if the SIP clients try to connect before the VPN is brought up, then they will go out the Default Gateway and not the static route down the VPN (obviously because the route is not valid until the interface comes up).

Once the interface does come up (seconds after the WAN is online), Mikrotik will not route the SIP client down the VPN, but continue it out the WAN.

We remove the connection. Works

Simple Network Diagram:

(SIP Client - 192.168.1.50) -> Mikrotik -> INTERNET -> Mikrotik -> (SIP Server - 192.168.2.50)
The 192.168.1.0/24 and 192.168.2.0/24 are routable across the VPN (I've tried OVPN & PPTP)

Let me know if you have any thoughts.

Currently this is fixed with a simple script.

Once the interface does come up (seconds after the WAN is online), Mikrotik will not route the SIP client down the VPN, but continue it out the WAN.

sounds a bit like 'RouterOS routes the SIP client through the VPN, but still NATted with WAN address - because it's imppossible to re-NAT established connection'...

p.s. or, it depends on your mangle setup

just to keep this thread up to date. same problem in ver 6.1 SIP UDP sessions need to be refreshed with a script every few hours to maintain registration when gateway is a pppoe interface.

SIP UDP sessions need to be refreshed with a script every few hours to maintain registration when gateway is a pppoe interface.

and all that time pppoe is up, without disconnects?

yes.

still see the strange behaviour where a UDP connection time out will count down to 0 the start to count back up. The upwards count just continues forever till the connection is manually closed.

I am running a script to close all udp connections every 24hrs early in the morning, All SIP endpoints remain registered for the whole 24hr period ok.

I only see this behaviour when the gateway is pppoe

Same problem here.
I am using Comcast cable in US at few locations, and VPN over PPPoE in Serbia at the other locations.
In the case of Cable, it is dynamic IP, but it hasn't changed when it happened. Although, at is happening more often at some locations, and some of them works for 6 months.
In the other case, it is complex network diagram and lot of things can cause this. But it is static IP.

I did my own experiment, and I haven't had a case that I needed to wait for 2 sec until connection is reestablished. I even didn't noticed any disruption at all while in a call!

Have you tried to disable the service ports for SIP in the firewall settings?

No. How do you think it is going to help? I was playing with that befire and only thing I saw as a difference is what it shows up in firewall/connection... I will try, but I will have to wait for some time to test it. It is not showing up that often.

Just to add, I have about 50 PPPoE clients with SIP boxes, no nat, only routing. I dont have any complaints of any issues and I dont run any scripts to refresh any connections.
I have the SIP registration to 60 seconds.

BUT I have seen this issue in the linux world, and in some legacy CPE by ubiquiti. These CPE I cant use SIP and dynamic IP.
BUT I have also seen this with mikrotik and NAT, SIP breaks

Is there any progress on this issue? Are you working on it or Mikrotik developers don't want to spend time on this?

In my case it help to give the udp timeout in connection tracking a higher value. I have some setup to 3 minutes. I don't work to mutch with sip, but if a customer reports any issue with ip thelephony, I change the setting, and it use to be OK.

Hi everyone.
This is sad, but the problem still exists in 6.12.
My router works as
- internet router with NAT
- PPTP client with another NAT
I have 2 SIP connections - first one to internet service, second to private IP switch on the other side of PPTP.
PPTP connection takes some time to establish, so routerboard first tries to route the connection over internet NAT and remembers this wrong route for an hour! I have to kill the connection manually to get the phone working.
And I can't turn off SIP helper, because this way second connection works, but not the first.

I did a workaround by making the private switch listen on 5068 instead of 5060. Now it works fine, but it won't work for everyone. Mikrotik, why not lower the SIP timeout or (better) make it changeable by user?

it's working with me without any problems.

it's working with me without any problems.

What exactly is working? Do you have the same setup?

PPTP connection takes some time to establish, so routerboard first tries to route the connection over internet NAT and remembers this wrong route for an hour! I have to kill the connection manually to get the phone working.

can't you just forbid (in Firewall Filter) that connection over Internet, and allow it only via PPTP?

Thanks for the advice.
Tried this, but the problem is more complex then I thought. Plainly, sometimes it works, sometimes it doesn't, and I can't understand why.
Can you tell me, what exactly does SIP helper do?

Im seeing this problem too but with cabled WAN on dhcp. After some time sip connections cant register. Its very frustrating, and Im getting it in the neck from users!

Im on v6.12, but I just updated to v6.13. Likely its still an issue in v6.13, as I dont see any fixes related to sip or UDP connection tracking.

Yes please, Mikrotik, do tell, what does IP-->Firewall-->Service Ports-->sip setting actually do?

Im just watching the connection list with sip setting in service ports turned off and a filter in the connection table where dst-port is 5060.

Should I be seeing connections with the timeout counting up?

Just wanted to add my comment as I had the same problem.

I run the following script every 10 minutes.

/ip firewall connection remove [/ip firewall connection find where connection-type=sip and assured=no]

works for me at the moment. hope it helps others

I've been watching this topic because it's about the same problem, or a similar problem, to the one in this post:

http://forum.mikrotik.com/viewtopic.php ... 74#p439474

I listed a fix or work-around there that worked for me.

I am also having the same problem with a multiple routing scenario and I can see what is happening but cannot explain why, I'm not sure if it's a bug but perhaps someone could see if they think it should be logged.

2 interfaces with public IP addresses 1.1.1.1 and 2.2.2.2
Local SIP server on private LAN - 192.168.1.1
main routing is to the line with IP 1.1.1.1
Connection is made outbound to the IP provider on the internet at 123.123.123.123:5060.

I see a NAT connection come up as follows ...

SRC address - 192.168.1.1:5060
DST address - 123.123.123.123:5060
Reply SRC address - 123.123.123.123:5060
Reply DST address - 1.1.1.1:n (random port)
Protocol - 17 (udp)

If the routing now changes to the line with 2.2.2.2, then this NAT connection never times out and continues to NAT the same traffic from my 192.168.1.1 server. It's as though it is examining the outgoing packet and as the source and destination IP addresses match the rule then it NAT's the packet based on the information in the existing rule, regardless of the fact that 2.2.2.2 is an invalid source IP on the link that has public IP 1.1.1.1

I suspect however, this is perfectly valid and is the whole point of the connection rule to match to source and destination IP addresses and apply the NAT rule accordingly.

However, the issue as I see it is that it should only do this for as long as the timeout is valid. After which it should drop the rule and re-establish it when required. What it does instead is that the timeout starts counting up instead of down and never disappears.

As people have already stated, if I remove the rule manually then as soon as the local SIP server refreshes it's registration from it's refresh parameters the rule come back correctly on the 2.2.2.2 interface. However, it's just ugly and horrible and does not appear to be working correctly.

This is the connection that comes up as soon as I delete the old wrong connection.

SRC address - 192.168.1.1:5060
DST address - 123.123.123.123:5060
Reply SRC address - 123.123.123.123:5060
Reply DST address - 2.2.2.2:n (random port)
Protocol - 17 (udp)

I suppose one option is to have a script that roams through the connections list constantly searching entries where the Reply DST Address field is based on an IP that is considered invalid and dropping them out the table but this again is another cludge.

I'll try getting this logged if people feel I'm on the right track so I'd appreciate anyone's thoughts.

Thanks, Dominic.

domonic. Thanks for taking the time to post this, I figured it was something like this but not had time to investigate fully and log it as a bug.

Important detail is the timeout counting up which I dont believe should ever happen. You should totally log it.

Its been plaguing my customers with VOIP for some time now and although I can fix it by deleting all the "sip" connections in the firewall connections tab when it happens, its not good for customer confidence in the product.

However, the issue as I see it is that it should only do this for as long as the timeout is valid. After which it should drop the rule and re-establish it when required. What it does instead is that the timeout starts counting up instead of down and never disappears.

Timeout is being reset each time a packet matching the state hits the router, no matter what direction this packet is passing in.
Not sure if it helps, but have you tried specifying out-interface in your NAT rules? Please note though that in this case you might need to have several NAT rules (one for each out-interface).

Timeout is being reset each time a packet matching the state hits the router, no matter what direction this packet is passing in.

I'm not really sure of it ..I've just made a test monitoring 'sip' conn tracking: making a call (sip invite) I've seen no update on timeout.

Not sure if it helps, but have you tried specifying out-interface in your NAT rules? Please note though that in this case you might need to have several NAT rules (one for each out-interface).

I've different 'masquerade/src-nat' rules for every outbound wan connections (so I presume the rule must go 'invalid' changing wan conn); I've just made a simple test and the 'assured contrack item' never invalidates on failover.

I've just written some code lines and I'm going to test ..let me show you the idea:

wan1 ip: 1.1.1.1 ( wan1 connection-mark: w1c )
wan2 ip: 2.2.2.2 ( wan2 connection-mark: w2c )
Simple test show me this script is cleaning 'wrong' sip conntracks correctly.


..maybe better to include also the..

Guys,

Can your SIP application work without the Linux SIP ALG/NAT helper, and if so, have you tried just turning it off...
...to see if that fixes the problem for you?

It sounds like the Linux SIP NAT helper disregards the UDP connection timeouts you specify for connection tracking. From http://www.dslreports.com/forum/r26935307-: "The reason I suggest disabling it is that one of its 'features' is that it causes SIP connections to disrespect the UDP Timeouts and time out after one hour."

-- Nathan

Can your SIP application work without the Linux SIP ALG/NAT helper, and if so, have you tried just turning it off...

Nathan, if I've a Sip-PBX in lan I've usually disable SipAlg/helper and I make manual/specific rules for SIP and RTP, but if I've several Sip Phones which have to register to external it's really difficult to set up things (not all sip phones permit sip parameters fine tuning) ..you must do sip/rtp rules for each one's. Sometimes impossible, sometimes only .. boring

It sounds like the Linux SIP NAT helper disregards the UDP connection timeouts you specify for connection tracking. From http://www.dslreports.com/forum/r26935307-: "The reason I suggest disabling it is that one of its 'features' is that it causes SIP connections to disrespect the UDP Timeouts and time out after one hour."

interesting .. but not really promising

interesting .. but not really promising

Well, no, it's both interesting and promising. If we can pinpoint where the problem is, then that makes it easier to get specific when filing tickets with MikroTik, and perhaps even makes it easier to devise a workaround that can be used in the meantime. The better your understanding of the problem is, the more effective (and creative) you can be when you go to tackle it.

For example, the reason I asked about whether you can get away with disabling the SIP ALG in your specific case is because I have found that if my external SIP proxy is Asterisk, and I configure Asterisk to also locally bridge/proxy the RTP audio (directmedia=no, directrtpsetup=no) and then force-enable "rport"/RFC3581 behavior and symmetric RTP port response for every remote peer (nat=yes), then it solves the NAT problem. I can turn off the MikroTik SIP ALG and have multiple SIP phones behind the NAT, and even without a STUN server, all phones work fine. No manual SIP or RTP rules per phone required. It places a little bit of an extra burden on Asterisk, but it works.

Of course, if you are not running the SIP proxy that the phones are registering to and the proxy is not under your control, then you might not be able to do this.

-- Nathan

Well, no, it's both interesting and promising. If we can pinpoint where the problem is .. (cut)

..from this point of view you are absolutely right!

(cut) .. RTP audio (directmedia=no, directrtpsetup=no) and then force-enable "rport"/RFC3581 behavior and symmetric RTP port response for every remote peer (nat=yes) .. (cut) .. multiple SIP phones .. (cut) .. all phones work fine. No manual SIP or RTP rules per phone require ..(cut)

This is really interesting and worth a try! ..time to setup an Asterisk test bed