SIP-ALG

Voice-over-IP (VoIP) uses separate communication channels for SIP (or signalling) and RTP (media transport - aka, your voice). Due to the design of SIP the two device at the far ends of a SIP conversation need to be able to communicate directly with each other on the advertised IP addresses. This is almost never the case because most sites use NAT for IPv4, and the migration to IPv6 (which makes this dicussion moot) is going ever so slow.

Various mechanisms have been proposed to get around this limitation and to in effect stretch IPv4 even more thinly than it is currently spread. Most solutions use a combination of STUN, TURN, rport and co-media. SIP-ALG is an older alternative that is implemented on the NAT gateways (typically your Fibre or LTE router) and attempts to modify both the SIP headers and RTP session descriptions in the SDP contained in the SIP payloads.

Going into the exact details of SIP-ALG in this page is possible but besides the point. The important point is that SIP-ALG has limits. It's implemented in-kernel in most implementations, it prevents hardware offloading and as a rule, except for very, very specific use-cases causes more problems than it solves. The reasons for this is manyfold, from our perspective the following reasons are the most important:

• It has limited memory available for tracking Call-ID and session data, and thus in many cases end up forgetting what it advertised, resulting in breakage. It should be noted that each REGISTER also takes up a memory slot here, and as such as the number of extensions increases so does the probability of problems.
• It hides the fact that the endpoint is behind NAT, resulting in the remote side (IEWCs servers) from being able to detect this and take appropriate measures (by forcing rport and relying on co-media).

In short, the NAT device isn't actually part of the SIP conversation, but to one side (the public side) pretends to be, and it does this by modifying certain aspects of the SIP conversation. Tracking this is error-prone, and we've not seen many cases where this improves the overall voice situation.

As a result, our recommendation is to simply switch it off wherever it's found.

How this is done varies from router to router.

Mikrotik

Look under /ip firewall service-port and ensure that the sip module is disabled.

You can perform this via the GUI, or alternatively on the terminal:

/ip firewall service-port set [find name=sip] disabled=yes