Hi,
A VoIP technician asked me to to turn off SIP ALG in my RouterBoard RB750. Unfortunately, I have no idea what that is so I researched it & the closest thing I could find was the SIP Helper. First question; are they the same thing? Second question; to turn off SIP Helper (assuming that's what I'm supposed to do) Do I just disable the SIP entry under Service Ports in the Firewall page?

Thanks.
Luke.

Usually SIP ALG refers to B2BUA (Back to Back User Agent).

I dont think its related to firewall service SIP which is a helper, not a B2BUA

Sonicwall's, Cisco ASA's, Motorola Cable Modem/Routers, Cisco Small Business (Linksys) routers, all have SIP ALG. Sonicwall in particular calls theirs "SIP Transformations" which usually spells disaster for most proprietary SIP phone systems.

Others like the one present in the Cisco Small Business/Linksys cant be turned off.

Im new to Mikrotik so I cant yet comment on it except that my Allworx SIP phone system works fine through it, and my Allworx dies with SIP ALG turned on.

Yes, the VoIP technician is referring to the SIP Helper. Disable it with the command:

Yes, the VoIP technician is referring to the SIP Helper. Disable it with the command:

Code: Select all

/ip firewall service-port disable sip

Thanks, guys! Just out of curiosity, is that command the same as disabling it in the Service Ports tab on the Firewall page of WinBox?

Yes, it's the same.

Hi all, I always interested in NAT helpers. How it works in background. What is the exactly mechanism?

does anyone have information on how the SIP helper works for the Mirkotik products?

I think it catches SIP messages on configured ports and changes local IPs to public mapping in Contact, Via etc.
Also it changes the media address in SDP, so, you don't have to worry about STUN etc.
However, it doesn't help with incoming media streams, so, you have to fix a port range for RTP on your SIP client and dst-nat it to client

I think it catches SIP messages on configured ports and changes local IPs to public mapping in Contact, Via etc.
Also it changes the media address in SDP, so, you don't have to worry about STUN etc.
However, it doesn't help with incoming media streams, so, you have to fix a port range for RTP on your SIP client and dst-nat it to client

Yep.. correct , but helper usually breaks more than it fixes.

You shouldn't have to open RTP ports, the firewall should 'see' that the packets are RELATED and it will open up the ports as needed.

Bye!

Menno

helper usually breaks more than it fixes.
Menno

do you have an example? I have tested this thoroughly some time ago, and found only 1 problem with it, which I will disclose later if it is different from yours Just curious to see if I missed something.
In general, it works fine for me, no major issues

I never had problem when SIP helper is enabled. I solved VoIP issue using ROS with SIP helper, when Watchguard X550 could not do it.

Many (most?) routers that have built-in SIP ALG/helper have a crap one, but the one built into RouterOS (which I suspect is probably very similar to the one that comes with the Linux kernel, if not the same) has always functioned just fine for me, both in testing as well as in the field.

-- Nathan

Vey useful.
I do not know about this SIP feature en MT config.

helper usually breaks more than it fixes.
Menno

do you have an example? I have tested this thoroughly some time ago, and found only 1 problem with it, which I will disclose later if it is different from yours Just curious to see if I missed something.
In general, it works fine for me, no major issues

Off the top of my head I can think of a good example where SIP ALG has caused issues. However this wasn't on a Mikrotik product.

The ALG was changing private IP's to the Public IP in the SIP and SDP messages, but it wasn't updating the content length, so the packets were being rejected by a strict SIP Proxy.

SIP ALG is often poorly coded, probably by someone with little understanding of SIP, which is why it can cause issues.

SIP ALG is often poorly coded, probably by someone with little understanding of SIP, which is why it can cause issues.

Not only that, but the RFC is somewhat open to interpretation (at least that's what the engineers at a couple of different SIP vendors I've spoken with have told me) because the protocol is so generic. (it started the whiteboard for the old MSN messenger client, for instance)

In general, you want one and only one device doing the NAT workaround. If there are multiple then things can slowly drift into the unusual. (I call it "haunted phones"). For instance, our SIP gateway recognized phones behind NAT, and allowed for "short circuit" if two phones on the same virtual PBX wanted to call "extension-to-extension" and it could see they were behind the same NAT, it would direct them to use each other's private IP as the media address. However, an ALG would see this SIP message telling the phone to use a private IP as the media address, and alter the message to some other IP (the sip gw, or the router itself) and that would break the audio... the SIP gw really did intend for the phone to send its media to a private IP, but the ALG thought it was being helpful by obscuring this in the messages by the time they reached the phones.....

Other times, some endpoints would think they were registered and the server would think they were dead. Sometimes the phone would ring and when the person hits answer, nothing happens, it keeps ringing, or they hear fast busy when they pick up, but the caller still hears ringback.....

Basically you only want ALG if you have SIP clients behind it that are not configured to work around NAT, and they're talking to other simple SIP endpoints that are also not trying to work around NAT.

sip + nat = problems

Hi,
A VoIP technician asked me to to turn off SIP ALG in my RouterBoard RB750. Unfortunately, I have no idea what that is Do I just disable the SIP entry under Service Ports in the Firewall page?
Thanks.
Luke.

There is a lot of confusion about sip alg. As far as I can tell it has nothing to do with the sip entry in service ports. These are the ports that the MT is listening on for incoming Invites.
Sip alg is a setting in your gateway router (assuming you are not running pppoe in the MT)
It works a bit like stun and replaces your private addrs in sip pkts with the public one of your router. This can fool your voip provider into thinking the sip client is not behind a nat so the audio port in your SDP is used by the voip provider for rtp. If your sip client is behind a nat the nat may translate your local port to a different public port and one way audio can occur.
By leaving a local private addr in the sip pkt the voip provider knows you are behind a nat so can ignore the sdp port and wait for the first few pkts of rtp to arrive and then knows the public port these are coming from and sends rtp to this port. Not all voip providers are fooled by this but It is always best to disable it in your router to be on the safe side.

Personally, I like deploying SBC's instead of enabling SIP ALG's on routers. Of course, this requires multiple public IP's, which are not cheap. For the time being, I simply don't expose my VoIP system directly to the Internet. All my extensions are internal, or routed through VPN into my network, so no unencrypted RTP exists outside my network. I'm debating whether to even bother with an SBC, though, or just use SIP-TLS and SRTP.

I just gave a presentation on SIP ALG at the Mikrotik MUM in Denver Colorado 2017 explaining everything about SIP ALG in RouterOS
watch here:
https://youtu.be/tM7wyKdnIKA

I was there. It was very informative as to what exact fields it modifies.

One question I thought of is this:

Suppose you have two phones on a LAN behind a Mikrotik router doing NAT with SIP helper activated, and they're talking to a SIP server on the public Internet. If phone1 calls phone2, would the SIP helper modify the A: component of the SDP messages when the two phones call each other and the server attempts to let the call perform direct media?

In other words, will both phones receive SDP messages telling them the remote media endpoint is "public.IP.of.Mikrotik" (requiring hairpin NAT)? Would enabling direct media support in the configuration on the Mikrotik prevent this?

In general, we disable SIP helper at our company because our SIP server has an SBC which does its own NAT discovery / work-around activities, and we've found that having two devices trying to do NAT workaround at the same time tends to lead to problems.