Introduction
Many of today's commercial routers implement SIP ALG (Application-level gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers' ALG implementations are wrong and break SIP.There are various solutions for SIP clients behind NAT, some of them in client side (STUN, TURN, ICE), others in server side (Proxy RTP as RtpProxy, MediaProxy). ALG works typically in the client LAN router or gateway. In some scenarios some client side solutions are not valid, for example STUN with symmetrical NAT router. If the SIP proxy doesn't provide a server side NAT solution, then an ALG solution could have a place.
An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol packet-inspection of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signaling and audio traffic between the client behind NAT and the SIP endpoint possible.
SIP ALG example
- caller behind NAT with private IP 192.168.1.33.
- caller router public IP 192.0.2.200
- SIP proxy in Internet with domain "example.com".
INVITE from the LAN client (with private IP)
INVITE sip:destino@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.33:5060;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: "Iñaki" <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.168.1.33:5060>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312
v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.168.1.33
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
Via: SIP/2.0/UDP 192.168.1.33:5060;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: "Iñaki" <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.168.1.33:5060>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312
v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.168.1.33
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
Note that text in red needs to be fixed before it arrives to the proxy (in case our proxy doesn't provide us a NAT server solution). If not, the proxy reply will not arrive at the client (caller):
- The caller couldn't receive in-dialog/sequential messages (ACK for the INVITE, BYE, REFER, re-INVITE...) since the address in "Contact" is not routable outside their network.
- Unidirectional audio since the caller told the callee to send audio to a non-routable address and port (so the caller won't hear the callee).
The text in blue doesn't need to be fixed since SIP already handles it (the server adds the parameter "received=REAL_SOURCE_IP" to the "Via" header and sends the replies to that address). Anyway some ALG implementations also change this value.
The same INVITE modified by the ALG router:
INVITE sip:destino@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.200:12345;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: "Iñaki" <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.0.2.200:12345>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312
v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.0.2.200
t=0 0
m=audio 33445 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
Via: SIP/2.0/UDP 192.0.2.200:12345;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: "Iñaki" <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.0.2.200:12345>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312
v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.0.2.200
t=0 0
m=audio 33445 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
The ALG has fixed the NAT related problem by:
- Replacing IP in "Via" header with the public IP and port.
- Replacing "Contact" with mapped public IP and port.
- Replacing SDP media address with public IP and port.
SIP ALG problems
The main problem is the poor implementation at SIP protocol level of most commercial routers and the fact that this technology is just useful for outgoing calls, but not for incoming calls:- Lack of incoming calls: When a UA is switched on it sends a REGISTER to the proxy in order to be localizable and receive incoming calls. This REGISTER is modified by the ALG feature (if not the user wouldn't be reachable by the proxy since it indicated a private IP in REGISTER "Contact" header). Common routers just mantain the UDP "conntection" open for a while (30-60 seconds) so after that time the port forwarding is ended and incoming packets are discarded by the router. Many SIP proxies mantain the UDP keepalive by sending OPTIONS or NOTIFY messages to the UA, but they just do it when the UA has been detected as natted during the registration. A SIP ALG router rewrites the REGISTER request so the proxy doesn't detect the NAT and doesn't mantain the keepalive (so incoming calls will be not possible).
- Breaking SIP signalling: Many of the actual common routers with inbuilt SIP ALG modify SIP headers and the SDP body incorrectly, breaking SIP and making communication just impossible. Some of them do a whole replacing by searching a private address in all SIP headers and body and replacing them with the router public mapped address (for example, replacing the private address if it appears in "Call-ID" header, which makes no sense at all). Many SIP ALG routers corrupt the SIP message when writting into it (i.e. missed semi-colon ";" in header parameters). Writting incorrect port values greater than 65536 is also common in many of these routers.
- Dissallows server side solutions: Even if you don't need a client side NAT solution (your SIP proxy gives you a server NAT solution), if your router has SIP ALG enabled that breaks SIP signalling, it will make communication with your proxy impossible.
List of routers with SIP ALG enabled
The following is a list containing SIP ALG router models, their issues and how to disable SIP ALG (enabled by default in most of the cases). Please add more data to this list if you have experimented problems due to a SIP ALG router.SpeedTouch
Models: ST530 v6 (firmware >= 5.4.0.13) comes with SIP ALG enabled by default.NAT type: symmetrical
Issues:
- No incoming calls.
- It replaces the private IP appearing in SIP headers with the public IP using a dumb text replacement. If for example the private IP appears in the "Call-ID" it replaces it too (that it's completely unnecessary).
~# telnet router
-> connection unbind application=SIP port=5060
-> saveall
-> connection unbind application=SIP port=5060
-> saveall
Zyxel
Models: 660 family comes with SIP ALG enabed by default.NAT type: symmetrical
Issues:
- No incoming calls.
- SIP protocol broken making 50% of outgoing calls impossible because the wrong values are inserted into SIP headers.
~# telnet router
Menu option "24. System Maintenance".
Menu option "8. Command Interpreter Mode".
ip nat service sip active 0
Menu option "24. System Maintenance".
Menu option "8. Command Interpreter Mode".
ip nat service sip active 0
Netgear
Models: WGR614v9 Wireless-G Router, DGN2000 Wireless-N ADSL2+ Modem RouterFirmware V1.0.18_8.0.9NA
To disable SIP ALG: From Wan Setup Menu, NAT Filtering, uncheck the box next to "Disable SIP ALG"
SMC
Models: ToDoNAT type: No symmetrical
Issues:
- The ALG doesn't replace the private address in "Call-ID" header (that is correct) but it does replace the "call-id" value in "Refer-To" header so SIP transfer is broken.
Linksys
Models: WRV200, WRT610NNAT type: Symmetrical
Issues:
- The ALG replaces the private address in "Call-ID" header (not needed at all). Some phones (as Linksys with latest firmware) encode the "Call-ID" value in the "Refer-To" header (by escaping the dots) so the private IP appearing there is not replaced with the public IP. This causes that the call transfer fails since the proxy/PBX/endpoint will not recognize the dialog info.
To disable SIP ALG on WRT610N: Web Interface: Administration, Management, under side heading 'Advanced Features' SIP ALG, can be disabled.
Peplink Multi-WAN routers
Models: All multi-WAN modelsTo disable SIP ALG, go to http://<router.LAN.IP>/cgi-bin/MANGA/support.cgi
Click the "Disable" button under "SIP ALG Support"
Issues:
- I'm not aware of any SIP ALG issues, but if you just want to turn it off, here you go.
Fortinet
Models: 800 comes with SIP ALG enabed by default.To disable SIP ALG:
~# telnet firewall
config system settings
set sip-helper disable
set sip-nat-trace disable
end
config system session-helper
delete 12
end
config system settings
set sip-helper disable
set sip-nat-trace disable
end
config system session-helper
delete 12
end
See Also
- SIP ALG Detector An utility to detect routers with SIP ALG enabed
- NAT survey
- NAT and VOIP
- Application-level gateway (ALG) in Wikipedia
- RFC 2633 IP Network Address Translator (NAT) Terminology and Considerations
http://www.voip-info.org/wiki/view/Routers+SIP+ALG