SIP ALG – General Overview
SIP Training for $20. This is a limited time offer!
This video is from the “Become a SIP Expert” series available on Udemy.com. If you are working in a VOIP support role, you need this course. Do you want this course for 50% off? Scroll to the bottom of this article to earn your discount coupon code.
=======================================
SIP ALGs have been added to most small office / home office ( SOHO) routers over the past few years. SIP is notorious for having issues with Network Address Translation (NAT) and the ALGs are the solution offered by most vendors.
One of the reasons that NAT and SIP do not play well is that ports need to stay open for a long period of time. Take the below registration message as an example. Notice the “Contact” in the headers. The expiration timer is set at 3600 seconds. This means that every hour my soft phone will attempt to register with the proxy.
Request-Line: REGISTER sip:proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.34.132;rport;branch=z9hG4bKebbzhcmh
Max-Forwards: 70
To: “keithtest” <sip:keithtest@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=afrlz
Call-ID: jgatcznxemdrtux@croxford1
CSeq: 496 REGISTER
Contact: <sip:keithtest@192.168.34.132>;expires=3600
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0
It just so happens that my router will close any NAT pinholes after 60 seconds or inactivity. Once the 60 seconds have lapsed my phone will not be able to communicate with the proxy. The phone will wait for an additional fifty nine minutes then send a registration message. During this time if an inbound call or a SUBSCRIBE / NOTIFY event is sent to my phone it will not make it through the firewall and the call will be rejected.
Most service providers combat this by sending an acknowledgement to the REGISTER with a lower expiration timer:
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.168.34.132;branch=z9hG4bKihfnwefm;rport=5060
To: “keithtest” <sip:keithtest@proxy.sip.test>;tag=aprqg7m9pp1-gmmvhl200g0i0
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=qlhos
Call-ID: jgatcznxemdrtux@croxford1
CSeq: 521 REGISTER
Contact: <sip:keithtest@192.168.34.132>;expires=45
The provider has replied with an expiration time of 45 seconds. As this is lower than the 3600 seconds from the original request, the phone will register as requested by the proxy.
If the provider does not have a Session Border Controller or proxy controlling the expiry timer, your NAT pinholes are going to close. If a SIP ALG is in place on the router it may attempt to register >= 10 seconds prior to the NAT pinhole closing. This should keep the registration active.
What about audio?
One way audio is a common issue in VOIP environments. Besides the VIA and Contact headers, media is controlled by the Session Description Protocol (SDP). The SDP defines which ports RTP will use for audio. It will define the IP address for audio packets, codec preference and many other attributes. In the below INVITE, scroll down to the Session Description Protocol section.
Session Initiation Protocol
Request-Line: INVITE sip:4801001001@proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.34.132;rport;branch=z9hG4bKuukvcokj
Max-Forwards: 70
To: <sip:4801001001@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=xghqr
Call-ID: hosfhlkkboehkga@croxford1
CSeq: 155 INVITE
Contact: <sip:keithtest@192.168.34.132>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 312
>Session Description Protocol
>Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 457748375 1076164210 IN IP4 192.168.34.132
Session Name (s): –
Connection Information (c): IN IP4 192.168.34.132
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 20000 RTP/AVP 98 97 8 0 3 101
Media Attribute (a): rtpmap:98 speex/16000
Media Attribute (a): rtpmap:97 speex/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
While other fields are important, we are specifically looking at the “Connection Information” . Notice the IP address of “192.168.34.132”. This is an RFC1918 address and not routable on the Internet. This is essentially my phone saying “when you send me audio packets, send them to this private address”. This is fine, assuming that a bidirectional route to the other call agent is present. If the other end replied with the Connection Information of “4.2.2.1” somthing similar to the below would happen.
Request : Soft-phone >> NAT Router >> Internet >> 4.2.2.2 (Audio is received)
Reply : 4.2.2.2 >> No route to the other host >> (Audio is dropped)
A SIP ALG will take the “Connection Information” and replace the RFC1918 address with a public IP address. It will also change the VIA and Contact headers to reflect the same IP address :
Session Initiation Protocol
Request-Line: INVITE sip:4801001001@proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 70.162.1.1 rport;branch=z9hG4bKuukvcokj
Max-Forwards: 70
To: <sip:4801001001@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=xghqr
Call-ID: hosfhlkkboehkga@croxford1
CSeq: 155 INVITE
Contact: <sip:keithtest@70.162.1.1>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 312
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 457748375 1076164210 IN IP4 192.168.34.132
Session Name (s): –
Connection Information (c): IN IP4 70.162.1.1
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8000 RTP/AVP 98 97 8 0 3 101
Media Attribute (a): rtpmap:98 speex/16000
Media Attribute (a): rtpmap:97 speex/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
In the above example the ALG also modified the audio port. Originally it was “20000” and the ALG changed it to “8000”. Assuming that the proxy does not use a method to detect private IP addresses you should be in good shape. Call control should be functional and bi direction audio present.
If your service provider (or enterprise proxy) utilizes an SBC, the ALG will need to be disabled. There is no need to have both ends of the connection making changes to the IP addresses and ports. If an SBC is in place and you are a running a SIP ALG, I can almost guarantee problems.
