What exactly does this mean? Is the device complaining about registration aging, or does the proxy server (actually, it would have to be the registrar) complain about anything?
I see the connection open in the tracker, but I see no packets going back and forth. At this point, I’m thinking this is now an issue on the SIP proxy server side. They are expecting keep alives, and I’m not sending them because of the default setting of 3600
It seems to me you are missing some significant point somewhere.
Leaving SIP aside: with UDP, the firewall cannot extract any information regarding the state of the “connection” from the contents of the packets because UDP itself does not support any idea of “connection” or “session” like TCP does. So the only criteria which the firewall can use to determine whether the connection is alive or not is whether packets are flowing or not. Therefore, after the first pair of packets passes, each in another direction, any further packet restarts the udp-stream-timeout timer. So in another words, the firewall drops the context of the connection udp-stream-timeout seconds after the last packet seen, or in yet another words, it drops the context of the connection if the gap between two subsequent packets of the connection (in any direction) is larger than udp-stream-timeout seconds.
This fact is the reason why keepalive packets are used - something must be sent every “less than udp-stream-timeout” so that the firewall would maintain the context and let the packets from the public side to the protected side get through. Once the context is dropped (aka connection closed at the firewall), eventual further member packets of that UDP “connection” which come from the public side are dropped. Eventual packets coming from the private side create a brand new connection from the perspective of the firewall.
The SIP helper, among other things, extracts the information regarding SIP registration state from the payload of the UDP packets, and modifies the udp-stream-timeout of that particular UDP connection to the value sourced from its own configuration if the registration succeeds. Therefore, the connection context is maintained for that time. The helper does not parse the registration response for the actual duration of the registration, so if it is longer that the timeout in the helper’s configuration, the connection context is dropped although the registration is still valid.
So the SIP servers normally do not “expect” keepalives to come. Depending on the vendor’s creativity, they may leave the responsibility of keeping the firewall context alive on the client and tolerate the keepalives sent by the client, or they may limit the registration duration to less than 3 minutes so that the clients would re-register (some firewalls only extend the context life if the first packet of a close pair went from the protected side to the public one), or they may send a message not changing the client state (usually OPTIONS) to yield an answer from the client. Some compare the IP in Contact in the REGISTER with the source address of the packet, and only send OPTIONS or reduce registration validity if they differ, assuming that a difference means that the client is behind a NAT which is not SIP-aware while same address at both places means that either the client is at public address or it is behind a SIP-aware NAT so no keepalives are necessary.
So the behaviour you observe is perfectly right from my perspective - the client registers for an hour, and as you haven’t asked it to send keepalives and as the SIP server doesn’t care of that either, there is no reason why any packets should be seen in the connection until either the client re-registers or until a call is initiated in either direction.
So if your Mikrotik shows that the connection is still alive but when you call your phone and the phone does not ring and the packet counter of the connection does not increment, the problem is not the connection tracking but something else.
If you can call your phone within, say, first 60 seconds after registration but not after, say, 10 minutes, there is likely some other firewall between you and the SIP server which is responsible for that.
If you cannot call the phone even within the first ~60 seconds after registration, the SIP server is probably unable (or not configured) to handle client-side, non-SIP-aware NAT.