I don't have "full info", but it is essential to see the "before" and "after" state to say more.
In particular, comparison of the output of
/ip firewall connection print detail where dst-address~"ip.of.the.exchange" issued when the SIP connections are stale, and of the same command issued once you remove these stale connections and the phones successfully re-register, should reveal whether it is a bug of the Mikrotik firewall or whether it is a consequence of something else.
In short:
- if the registration expires at the exchange side, the exchange should terminate any incoming call immediately as it doesn't know where to send the INVITE
- if there is a pinhole problem somewhere between the exchange and the called phone but the registration has not expired, the exchange should send an INVITE to the called side and only terminate the incoming branch of the call after the timeout for 100 Trying expires because it did not arrive from the called side
Just an example of what may happen, which may not be related to what happens in your case - whereas the registration usually takes 4 packets (REGISTER, 401(auth-challenge), REGISTER(auth-response), 200), a keepalive only takes two packets, or even one if the phone doesn't send a valid SIP request as a keepalive. As long as the phone "assumes" it is registered, it only sends keepalives; if the pinhole went away for some reason (e.g. since
action=masquerade is used for src-nat and the WAN address of the router got lost for a while), the keepalive creates a new one. But in case of UDP, the pinhole lifetime switches from
udp-timeout (default 10s) to
udp-stream-timeout (default 3m) only after the second "LAN->WAN" packet. So each keepalive only re-creates the pinhole for 10 seconds, and until a full re-registration takes place, the incoming calls will be failing most of the time, or even always if the new pinholes use a different socket on the WAN IP, which is more a rule than an exception if all phones use the same port. But removal of the existing connections (pinholes) is not a remedy for this scenario, so your case is likely to have a different root cause.