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. ...