Cloud Based DID With a POTS Based Asterisk System

A while back I wrote about my experience setting up a business phone system with Asterisk, Polycom, and POTS. This system has been working fine over the last year, I’ve only had to dive in once or twice to fix a couple issues (which I’ll detail in a future post).

However, recently someone using the phone system needed a Direct Inward Dial (DID) to their phone. I couldn’t find any concise walkthrough about how to set this up, so I’ve written down my processing in figuring this out.

I knew Asterisk supported DID, and I found a guide that walked you through setting one up.

If you using POTS for your calls and not a SIP trunk, DID gets tricky really fast. Some information mentioned voltage, analog signaling, and other tricks; having to work with your telephone provider; and PRI, number pulsing, and reversing polarity on analog lines. Both solutions seemed very messy and time consuming to me (working with my telephone company – Verizon – has only been painful). My hunch was that the lines coming into our building weren’t clean and we would have issues with the connections (the contractor who set up the lines mentioned something about the lines being dirty and not being able to fix them). I’m not a VOIP professional – nor do I want to be – line voltage and electrical signaling is the last thing I want to deal with.

Another possibility would of been to dedicate a physical line to the specific phone off the PBX and take that number off the hunt group. I could create an inbound route in Asterisk linking the dedicated line to the extension off the PBX. If I used this method, I would of had to take the line off the hunt group because depending on the number of people calling in the line might be picked up and then anyone using the DID will get a busy signal.

However, this would require buying more hardware and ordering another POTS line, something I didn’t want to do (mainly because of the time involved).

At this point I started to regret going with POTS over SIP trunks for our phone provider. However, POTS offered significant savings for us. Our lines through Verizon are relatively cheap (somewhere around ~$25/line) and came with unlimited minutes. When I looked at cloud phone providers they were charging $0.02 – 0.03 a minute. With our call volume this would of ended up costing us a good chunk more per month. Taking a look at cloud phone providers now it looks like the landscape has changed and cloud and land line providers seem to be much closer to price parity.

I figured it must be possible to forward a call over the PSTN to a SIP. Twilio definitely doesn’t allow connection to SIP endpoints right now (although, they have a service in beta). With Tropo it seemed like it was possible, but I couldn’t test an outbound phone connection without going through a verification process. Additionally, outbound calls ran $0.03/minute which seemed high.

After some googling I found DID Logic which on their front page mentioned call forwarding to a SIP URI – great. The company seems a bit  shady (“bought a theme + plugged in some standard marketing copy” sort of site), but since I could test things out for a couple bucks I went ahead and tried it out – it works great.

I grabbed a number off of DID Logic for ~$1/month + $0.007/minute and forwarded it to my PBX.

However, the Asterisk box was not setup to pick up anonymous SIP calls and my SonicWall firewall was not setup to expose SIP ports to the PBX.

Setting up Asterisk to Support SIP Call Forwarding From DID Logic

Make sure “Allow Anonymous InBound SIP Calls?” is enabled in the General Settings on your FreePBX admin (a SIP call from DID Logic will be anonymous).

Then add an InBound DID number in the extension’s control panel. With this DID assigned you can now call your phone using the SIP URI “220@yourdomain.com”. Most likely your PBX is behind a firewall, you’ll have to configure your firewall + NAT settings to forward SIP traffic to the PBX.

Sonic Wall SIP Traffic Forwarding Setup

You need to have both a firewall rule and a NAT routing policy for SIP traffic to work on a Sonic Wall device. Check out this comment for information about UDP timeout settings and some other general information about SonicWall Config.

Your Firewall rule should look something like:

• WAN –> LAN
• Source: Any
• Destination: Any
• Service: VOIP
• Allow

Your Firewall rule should nothandle the routing to a specific IP address even though there is an option for it. The routing is handled via your NAT rule (General > Nat Policies) and should look like:

• Original Source: Any
• Translated Source: Original
• Original Destination: Any
• Translated Destination: PBX
• Original Service: VOIP
• Translated Service: Original

The PBX destination won’t exist by default. To create that destination, go to Firewall > Address Objects and add one referencing your PBX on your LAN.

Also, ensure that “Enable consistent NAT” is enabled under VOIP > Settings. Do not enable any of the transform options.