VoIP Hairpinning Issues

Posted on in voice

When using Asterisk and a remote bank of <acronym title="Primary Rate Interface">PRI</acronym>s (or any other form of <acronym title="Public Switched Telephone Network">PSTN</acronym> connectivity for that matter), you may encounter an issue known as hairpinning. Hairpinning describes what happens when a call coming from the PSTN is routed by the access server (a Cisco AS5300, for example) back out through the PSTN. In <acronym title="Voice Over Internet Protocol">VoIP</acronym> this is often caused by the inability of the access server to initiate a session with the VoIP gateway.

VoIP and Hairpinning Illustration

In a simple scenario like the one illustrated above, another call leg is added when the PSTN routes the call back into the access server. If the access server again fails to reach the VoIP gateway, it will be routed back out the PSTN. Each leg of the call consumes a PRI B-channel; decreasing the overall number of channels available for new calls.

<!--more-->

When setting up a Cisco AS5300 to act as a remote PRI bank, I used the advice of other users and made the following configuration changes to the built-in <acronym title="Internetwork Operating System">IOS</acronym> <acronym title="Session Initiation Protocol">SIP</acronym> user agent:

sip-ua
 retry invite 4
 retry response 3
 retry bye 2
 retry cancel 2

As the call volume was small, this configuration worked fine for a couple of years. I could see the hairpinning happening, but it wasn't affecting call quality or channel availability. Recently, the call volume increased dramatically, and although the call quality was still not affected, there was a real chance that the hairpinning could cause an outage if too many calls used too many channels.

The solution to the problem was to revert to the IOS defaults for SIP retries. This increases the number of INVITE retries from 4 in the configuration above to 10. Since making that change, I haven't seen a single hairpin. Although call setup might take longer (potentially as much as 5 seconds based on timers and retries), the efficient channel usage on the PRI (not to mention possible charges depending upon how the PRI is provisioned) is well worth it. To date, I haven't received a single complaint from caller or callee regarding call setup times.

Slaptijack's Koding Kraken