during day we have that mikrotik don’t forward bye commands during call and operator have empty line and call must be manually closed.
I have collected log but not sure what is happening.
Maybe some UDP timeout and mikrotki loses NAT mappings and don’t know where to forward packets.
Maybe someone have idea what is happening and what could be reason.
I suppose the 192.168.181.15 is on the LAN side of the Mikrotik, is that correct?
The timestamps are missing in your screenshot, but already the 200 OK messages are not forwarded, so the timeout has to be quite short or the called party must be picking up quite late, as the normal timeout for a responded UDP session (which is this case, there were the 100 and 183 responses to the INVITE) is 180 seconds.
So what is the output of :put [/ip firewall connection tracking get udp-stream-timeout] and of /ip firewall service-port print where name=sip?
yes 192.168.181.15 is LAN side of mikrotik.
:put [/ip firewall connection tracking get udp-stream-timeout] = 00:03:00
/ip firewall service-port > sip disabled=yes sip-direct-media=no
one of latest examples
OK. Since the distance between the 183 (that went through) and the 200 OK (that didn’t) is some 27 seconds, which is far less than the UDP stream timeout on the firewall, we can exclude an issue with the normal UDP NAT. The 200 OK may be huge but the BYE should be relatively small, so issues with LAN MTU should also not be an explanation. So the next question is what does /ip firewall connection print detail where dst-address~“:506” show? Change the public addresses before posting of course.
yes that is strange why mikrotik don’t NAT those messages from provider to client(192.168.181.15) and I can’t find why.
Also we can’t reproduce problem, it just happens several times a week.
Even better… OK, what I could imagine would be expiration of ARP cache and lazy reaction of the ISP gateway at 192.168.181.15 to ARP requests, making the Mikrotik unable to send the message received from the SIP server after un-src-nating it. To check that, please try to set up a static ARP record for 192.168.181.15 and see whether it helps.
Another possibility would be some blackhole route or IPsec policy matching the un-src-nated packet, but these would have to appear only temporarily as you say it happens only occasionally.
Questions without any particular thought behind them:
RouterOS : 7.12
I have setup static arp under /IP arp
There is no IPSec tunnels on mikrotik.
Also no specific routes under /ip route
I have setup NAT only for 5060.
Do you think I should set dst-nat for port 5062?
chain=dstnat action=dst-nat to-addresses=192.168.181.15 protocol=tcp dst-address-list=MediaWAN dst-port=5060 log=no log-prefix=""
chain=dstnat action=dst-nat to-addresses=192.168.181.15 protocol=udp dst-address-list=MediaWAN dst-port=5060 log=no log-prefix=""
No, just because two distinct ports are used for SIP at 192.168.181.15, I’ve assumed it’s some 2-port gateway or so and hence I was expecting you to have a symmetric setup for both; since you don’t, I am a bit confused about the type of the SIP device. But it’s not related to what the captures show, as the 200 that is not forwarded arrives to port 5062 so it should get un-src-nated just fine.
Let’s see whether the static ARP record changes anything.
How did the static arp go?
For the following topic with vaguely similar issues
rdp connection dying
http://forum.mikrotik.com/t/rdp-connection-dying/151731/1
Setting the UDP Timeout to 20s from its default 10s fixed the problem in a lot of cases.
It shouldn’t make any difference but…
Mikrotik might also like to know about this issue, given that while not repeatable on demand, it happens quite a lot
and might help them solve it. (I think it might be some sort of longstanding bug)