What is an ALG?

ALG's, or Application Layer Gateway's (also sometimes called SIP Helpers), are software components embedded within most routers and firewall's designed for the SOHO or SME market.  Their intention is to allow VoIP traffic to traverse between Public and Private networks (ie solve the problems that NAT gives us).  However, thevoicefactory employs a Session Border Controller within our data-center that performs this exact job, amongst others.

Basically, the ALG conflicts with our SBC and this results in a wide variety a side effects.

Symptoms of an active ALG

thevoicefactory have witnessed many different types of symptom caused by an ALG at the customer's site.  As time progresses and others un-earth themselves, we will update this list.

• Unable to Register
• One-way audio, this can occur on calls within the LAN or traversing the WAN (ie PSTN or another on-Platform user)
• Zero-way audio, this can occur on calls within the LAN or traversing the WAN (ie PSTN or another on-Platform user)
• Unable to Transfer a call (either Blind or Consultative transfer)
• Transfer softkey not appearing when on an active call, even when the account contains the Call Transfer licence
• Calls automatically disconnecting after a precise period of time (10 minutes / 30 minutes)
• This has been seen when SIP UPDATE messages are not handled correctly.  This method is used by Broadworks to ensure both ends of the call are still online.  Messages are sent periodically, and if they are not responded to the call is torn down as Broadworks believes one endpoint has been lost.
• Audio disappearing after a precise period of time
• This is similar to the SIP UPDATE issue above, whereby Broadworks does tear the call down to the far end but in this scenario the near end does not tear down thus a loss of audio
• A limited number of IP handsets are able to register.  Disconnect a working handset and a previously failing handset starts to work.
• This issue has also been seen with Busy Lamp Field subscriptions
• Unable to dial users from remote sites when more than 3 codec's were offered.
• This one affected a site using Linksys 941's, although the handset model is possibly irrelevant.  The device would not respond to the INVITE when a large selection of Codec's were offered.  As these users were behind a Hunt Group, this resulted in all calls routing directly to Voicemail.

Diagnosing an ALG

Without using any tools at the local site, we can sometimes see ALG activity within the SIP messages as seen in Palladion.

Above, is a real INVITE (on the right) with only the user details edited for privacy.  On the left, is a mocked-up example showing what we typically see after the ALG has done its work.

Note that any Private IP's - particularly in the SDP portion, have been exchanged for the WAN IP of this user.

Unfortunately, not all ALG functionality can be spotted remotely, and there is ultimately no substitution for comparing a local packet dump to that taken from Palladion.

Where ALG's can live

Typically, the ALG will live within the device performing NAT - typically this is the local Router/Firewall.  However, we have seen them in other locations - at one Enterprise site we found 4 on the same network!

• WAN Router
• LAN Firewall
• Layer 3 Switch (never witnessed in a dumb Layer 2 Switch) 
• ISP Firewall
• ISP MPLS Concentrator

Disabling an ALG

This is the desired solution to the problem, but not always possible without changing Routers, Firewalls or sometimes even ISP's.

For instructions on how to disable the ALG on your specific device, please consult the documentation.  I tend to find Google-ing "deviceX disable alg" often points you in the right direction.  Usually, you will find the ALG settings under the NAT or Firewall section of the Web GUI.

Points to note:

• Not all devices can disable their ALG.
• Some devices allow you to disable the ALG, however still continue to do some manipulation.
• Some devices do not expose ALG functionality to the Web GUI, instead they can be disabled by Telnet-ing to the device and issuing the correct command, for example the Draytek Vigor 2820.

Example Telnet to a Draytek Vigor 2820:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
Password: ********
Type ? for command help
> sys sip_alg ?
usage: sys sip_alg [value]
 0 - disable SIP ALG
 1 - enable SIP ALG
 current SIP ALG is disabled
>

Methods to work around an ALG

If you have been unable to identify and elimate all ALG's from your customers network, you may try one or more of the following techniques.

• Use TCP, rather than UDP, for SIP.  Using Device Management Tags, %TRANSPORT% controls the Transport Protocol that the device will use.  Most devices we support allow you to change this.  Please see the appropriate Device Management Configuration articles for Tag examples for the device in question as the format does change between vendors.
• Use a non-standard port for SIP.  Using Device Management Tags, %SBC_ADDRESS% can be set to "alt-proxy.thevoicefactory.co.uk".  The DNS SRV record for this address returns "6050" as the port to use.  If your device does not use DNS SRV records, also set the %SIP_PORT% to "6050".

Related Articles

Firewall Configuration