Setup a Linksys/Sipura SPA-3000 with FreePBX

Here is how you can setup Linksys/Sipura SPA-3000 series devices to
work with FreePBX. These instructions were originally written for the
Sipura SPA-3000, but for the most part are also applicable to the
Linksys SPA-3102.

It took a lot of work to get the SPA-3000 working, but what finally got it working was very simple setup.

The FXS port (where you plug in your phone) is set up in the normal
manner, just as on the Sipura 2000/1000 units. So when you want to set
up that port, just look for instructions for setting up a SPA-2000 or
SPA-2100, or even a Linksys PAP-2 - the setup of the FXS port is pretty
much identical to those devices. What were are concerned with here is
the FXO port, that is, the port that connects to the PSTN telephone
line.

Before you begin you may want to make sure you have the latest firmware, which at this writing is available at this page (note, Linksys SPA-3102 users should look for current firmware at the Linksys site
instead). Note that Sipura's site implies that if you have 2.0 hardware
you must use 2.0 series firmware. However, at least two people have
successfully upgraded a 2.0.x series SPA-3000 to firmware revision
3.1.10(GWd). No guarantees, but if you are feeling lucky you may want
to try it. Of course if you have the 3.0.x series hardware you can
definitely upgrade your firmware. The upgrade will give you some
additional settings but will wipe any current configuration, so you
will want to do that first if you intend to do it. You may want to hold
off on the upgrade unless you experience problems - that is up to you.

For the PSTN setup here is what I did to finally get it working.

1) Create a new SIP trunk in FreePBX.

2) For Caller ID I put my inbound DID there since it's from my BellSouth POTS line.

3) Max channels: I put 1 since it's only one line. This is
important because if you don't do this, and this trunk is busy, calls
may not fall through properly to the next trunk, due to a combination
of bugs in certain versions of Linksys/Sipura firmware, and a bug in chan_sip in some versions of Asterisk.
Even with this set, this bug can still bite you if you have an Asterisk
version earlier than 1.2.16, the device is in use for an incoming call
and the system attempts to use it for an outgoing call (the max
channels logic only counts outgoing channels, not incoming ones).

4) Dialing rules, Dialing Wizard and prefix I left blank. (Remember
keep it simple at the beginning will go a long way). If you want to add
or strip a prefix you can change the dialing rules later.

5) Trunk name: I called this pstn (Again simple). Note that this
must match the username in the next section, or you may have
registration problems.

6) Outgoing settings - Peer settings (don't enter the comments - the text following the semicolons):

allow=ulaw

canreinvite=no

context=from-trunk ;this is needed here very important.

disallow=all

dtmfmode=rfc2833 ;You can try inband if you have problems accessing your IVR menus

host=192.168.0.xxx ;The address of the Sipura on your LAN, SEE NOTE BELOW

incominglimit=1

nat=never

port=5061 ;We use port 5061 rather than 5060

qualify=yes

secret=XXXXXX ;pick a good password

type=friend

username=pstn ;must match the trunk name or registration may fail.

NOTE: The original author of this page had written that the host
setting should be host=dynamic and added the comment "IMPORTANT - use
this even if you set the Sipura to use a static IP." However I
(wiseoldowl) found that it works fine when set to the actual local IP
address, and I have made a couple of other minor changes that have been
tested and are working with FreePBX 2.2.0 and Asterisk 1.2.17.

7) Incoming settings - User settings

From wiseoldowl: It turns out that these are not needed
at all as long as you set the type=friend in the Peer Settings. The
original author of this page had placed some settings in this section
but I do not believe they were actually being used and in fact may have
been causing problems. Other Sipura 3000 configuration pages on the net
don't include a User context or User settings so I advise leaving these
blank, but if you really want to see the original author's settings you
can look at the page history for pages created prior to April 7, 2007

8) No Register String is used. Click Submit Changes and remember to click the red bar to update your system.

You now are ready to setup your outbound routing.

1) I called my route spa3000; again this is to keep it simple.

2) No password for the route; keep it simple

3) I only want calls to my area code and 911 via this route so under dial pattern I have:

911

305NXXXXXX

786NXXXXXX

4) Trunk sequence: I have it going to this trunk first. Then to my Voipjet settings.

5) Submit Changes and remember to click the red bar for the update.

Next you need to setup your actual Sipura 3000 PSTN settings.

Ok here is where I was playing for 3 days to get this part working.
It's strange that when I just removed everything and kept it very
simple and logical it started to work just fine.

PSTN Line - login and pick advanced; I am only putting what needs to change.

1) Sip settings: Just make sure it's on port 5061 (I did not need to change mine).

2) Proxy and Registration: I just put my asterisk box's IP address
in the Proxy text box, and left everything else the same. Some people
have reported that they had to set Make Call Without Reg and Ans Call
Without Reg to Yes before things would work - it apparently doesn't
hurt anything to change those two settings, and it may save you some
grief.

3) Subscriber Information:

Display name: Put something here that will identify this line -
this is only displayed on your phones if you get a call with no Caller
ID information (or you don't subscribe to Caller ID). Keep it at 15
characters or shorter. You could use something like LOCAL PSTN CALL.

User ID: pstn ; very important.

password XXXXX (same as you used in trunk settings).

4) Audio Configuration:

DTMF Process INFO: Yes

DTMF Process AVT: Yes

DTMF Tx Method: Auto

The DTMF Tx Method is the one you especially need to check if your
IVR is not receiving DTMF from your callers reliably. Now let's go down
some more to: Dial Plans

5) Under Dial plan it's important not to change (xx.) on any except
Dial Plan 2. I put it very simple to go to my inbound so FreePBX takes
care of my calls:

(S0<:s>)

IMPORTANT: While the above will work and is
probably adequate for initial setup and testing purposes, now that
FreePBX supports inbound routes, it is better to use something like
this for Dial Plan 2 instead:

(S0<:1234567890>)

Replace 1234567890 with the telephone number of your PSTN line.
Then define an inbound route in FreePBX for your PSTN number (using the
same number you used here). This gives you much more flexibility in
handling incoming calls from your PSTN line (also, in some cases
Asterisk does not handle calls to the "s" extension very well).

6) Now to: VoIP-To-PSTN Gateway Setup; another important settings section

VoIP-To-PSTN Gateway Enable: yes

Voip Caller Auth Method: None ; <= A must now, we'll change this later.

Voip Pin max retry: 3 ; I did not change this.

One Step dialing Yes ; <= another must.

Line 1 VoIP Caller DP: none

VoIP Caller Default DP: none

Line 1 Fallback DP: none.

Nothing else here, move on to the next.

7) VoIP Users and Passwords (HTTP Authentication): Leave all of
these blank (the drop-downs can be left set to 1), then move on to the
next section - there is nothing needed here at all.

8) PSTN-TO-Voip Gateway Setup - here is another section that made me pull my hair out.

PSTN-To-Voip Gateway Enable: Yes

PSTN Caller Auth Method: none

PSTN Ring Thru Line 1: no ; I use asterisk for my routing.

PSTN Pin Max Retry: 3

PSTN CID for VoIP CID: Yes if you subscribe to CallerID service on your PSTN line, otherwise No

PSTN CID Number Prefix: (Leave Blank)

PSTN Caller Default DP: 2 ; important - here is where it sends the calls to.

Off Hook While Calling VoIP: No

Line 1 Signal Hook Flash To PSTN: Disabled

PSTN CID Name Prefix: (Leave Blank)

Almost finished now. Next section:

9) FXO Timer Values (sec): Just change 2 items here.

Voip Answer Delay: 1

PSTN Answer Delay: If you do not subscribe to CallerID service on
your PSTN line, this can be set to 0. Most users will want to set it to
at least 3 so that the incoming CallerID data is captured. In rare
situations you may need a slightly longer delay (5 should be more than
enough).

Skip the PSTN Disconnect Detection section unless you know what
type of PSTN disconnect signal(s) are used on your PSTN line and wish
to change the settings so that those signals (and only those signals)
are detected. Generally you should only tweak this section if the
Sipura isn't properly detecting disconnected calls on the PSTN side.
The "Disconnect Tone" is by default set to detect the "fast busy"
signal usually sent after a call has ended in North America - you may
wish to tweak this setting if the switch serving your PSTN line sends a
different tone after disconnect.

And there is one final thing to at least be aware of:

10) International Control

Check the settings here - each country uses different values for
PSTN lines. If you live in Australia, Canada, the United States or most
other countries with modern telephone systems you probably won't have
to change anything except perhaps the gain levels, so we'll only deal
with them for now. The default values for both the SPA To PSTN Gain and
the PSTN To SPA Gain are 0 (zero), and that's where you should leave
them when you're first setting up the SPA-3000. But just so you know,
here's some information on those settings:

If the SPA to PSTN gain is set too low, the parties on the PSTN
side of the connection will probably complain about your volume being
too low, or will ask you to speak up or talk closer to the phone. If it
is set too high, however, you are more likely to hear echo, and
outgoing calls may fail because the level of DTMF tones sent by the
SPA-3000 will be too "hot" to register properly at the PSTN switching
equipment.

If the PSTN To SPA Gain is set too low, you'll hear low volume
levels on PSTN calls. If it's set too high, the people on the PSTN side
of the connection will be more likely to hear echo (they may hear their
own voices echoed back from your end). Also, any echo that has been
reflected back to you will be heard at a higher volume level, and will
therefore be more objectionable.

While the default levels are usually adequate, we found that
boosting both values up to 3 produced a more "natural" sounding volume
level in both directions. However, this is very much dependent on the
characteristics of the PSTN line - if you're on a very short loop,
values of 0 may be adequate for both settings, if on a very long loop
you may need to go even higher than 3. The valid range is -15 dB to 12
dB in 1 dB increments (but just enter a numeric value, do not enter
"dB" in the text field). If you have actual test equipment available
you can fine-tune the volume settings for best results.

We'll talk a bit more about settings in this section under
"Troubleshooting", below. For now, that's it. Submit and it should
register and you should be able to use the PSTN port on the Sipura.

I did not change anything from the default SIP setting.

Troubleshooting

If you are connecting VoIP adapters back-to-back (SPA-3000 PSTN
port to a line port on another device, perhaps because you are wanting
to access a line from a commercial VoIP provider that insists you use a
VoIP device that they provide) and if their device ever sends caller ID
names with a single quotation mark, those calls will either simply ring
and never answer, or will be answered but then disconnected after a few
seconds, due to a bug in the SPA-3000 firmware. This problem usually
presents itself if the other device is a Cisco ATA-186. You can either
have your provider send you a newer device (they may charge you for
this) OR you can disable CallerID passthru (which will throw away the
incoming Caller ID). To do the latter, set PSTN CID for VoIP CID to NO,
and you may as well set PSTN Answer Delay to 0 since there will be no
need to wait for CallerID. A third option involves patching Asterisk
itself but that is beyond the scope of this article (however, see the
added comment at the bottom of this article).

If you have problems getting the SPA-3000 to register with your
Asterisk box, try setting the Sipura up on a static IP address instead
of letting your router assign it one via DHCP. Go to the System tab,
and the Internet Connection Type settings:

DHCP: No

Static IP: (pick an address on your local network that will not
conflict with your router's DNCP assignments, such as 192.168.0.250)

NetMask: (usually 255.255.255.0 unless you have a large network)

Gateway: (usually 192.168.0.1 unless your local net is numbered differently)

Skip down to Primary DNS: (you will probably want to put the same
address as you used in Gateway here - usually both functions are
handled by your router).

While you are here you may want to set a Primary NTP Server so that
your Sipura will know the time. Usually you can point this to any NTP
server on your local network (such as your Asterisk box) and it will be
close enough, but you could also use a public "pool" NTP server. But if
you do this you will also want to set a time zone, and that setting is
found under the "Regional" tab at the bottom of the page (if you have
the latest firmware you can also include a Daylight Savings Time rule).
It is NOT necessary to set up a time server to get this unit to operate
as a PSTN gateway; I only mention this so that people who do want to
set the time will know where the settings are.

There are two other settings under the PSTN tab, in the
International Control section that you should be aware of if you are
having problems. If you can't seem to get calls to go out (and in
particular, if Asterisk reports that there are no circuits available),
try setting the Line-In-Use Voltage to a lower value, such as 15. Some
telephone companies use "pair gain" or "subscriber carrier" equipment
to put multiple subscribers on the same loop. If you have the great
misfortune to receive telephone service through such equipment, your
on-hook line voltage may be less than 30 volts, and if that is true the
Sipura will think the line is always in use unless the Line-In-Use
Voltage setting is lowered. In the U.S.A. and Canada, nominal on-hook
voltage is about 45 to 48 volts, and in that situation the 30 volt
setting is correct. But if you are "served" using pair gain or
subscriber carrier equipment (or are unsure of the telephone line
voltages used in your locality), you may want to use a voltmeter to
measure both PSTN on-hook voltage and off-hook voltage (the latter
being the voltage on the line when a phone is taken off-hook), and set
the Line-In-Use Voltage setting to a value about halfway between those
two measured voltages.

Also, the FXO Port Impedance default setting is 600 ohms is correct
for many places in the world. Some places use 900 ohms. You really
should try to find out the standard impedance setting for the PSTN line
you are connected to, since an improper setting can cause some
frequencies to be higher or lower in volume than others. Mismatched
impedance can also be a source of echo and DTMF recognition problems.
However, determining the best/most correct setting can be something of
a black art, as this Cisco document
illustrates. That said, if you don't know the correct impedance, the
600 ohm setting will generally work well, especially on loops of about
one mile/1.5 km or less.

Adding security

Once you have it working satisfactorily using the above instructions (test it with both incoming and outgoing calls), go into the Sipura's PSTN Line settings and make the following changes:

Under VoIP-To-PSTN Gateway Setup, change VoIP Caller Auth Method to HTTP Digest.

Under VoIP Users and Passwords (HTTP Authentication), change the following:

VoIP User 1 Auth ID: pstn

VoIP User 1 DP: none

VoIP User 1 Password: XXXXX (same as you used in trunk settings).

After making the above changes test to make sure that both incoming
and outgoing calls still work as expected. That's all the security
changes under the PSTN tab.

However, the Sipura's web pages are still wide open (unless you
have already set up passwords) and if anyone on your local network goes
there (or someone manages to hack their way in) they can go to the
Sipura's web pages, and see and change all your settings. So you will
probably want to password protect the settings pages. Note that there
are separate user and admin passwords - you can set these in the System
Configuration section of the page accessed through the System tab. BE
CAREFUL - take your time and think about what you are doing here,
because if (for example) you make a typo in a password and don't catch
it, you could lock yourself out of your Sipura!

Additional information

If your adapter is at a remote location, or for some other reason
you would like incoming calls on the PSTN line to ring through directly
to "line 1" (the phone port) WITHOUT first passing through Asterisk
(but still having the ability to send the call to voicemail if no one
answers), set PSTN Ring Thru Line 1 to Yes, set PSTN Answer delay to whatever number of seconds delay you wish before the call goes to voicemail, and then set PSTN Caller Default DP to 1 and set Dial Plan 1 as (<:*extensionnumber@asterisk_ip:port>)
- the * in front of the extension number tells FreePBX to send the call
directly to that extension's voicemail without building a inbound
route. So, incoming calls from the PSTN should ring directly into any
telephones connected to the phone port, but if not answered in the
specified time they will still get transferred to the extensions
voicemail (thanks to "cyberglobe" for suggesting this in the IRC
channel).

Other pages with Sipura 3000 setup instructions

Different people have different ways of setting up any particular
piece of hardware. Here are some alternative approaches to setting up a
SPA-3000:

Asterisk@Home Handbook Wiki

Voipspeak

Added comment about Caller ID name problem

As mentioned above, if the SPA-3000 receives a CallerID name from
the PSTN line that contains only one quotation mark, the call will
fail. This issue, or a very similar one, has been raised in Digium Issue Tracker report 0007333: Malformed callerid string causes SIP clients to silently drop packets. The report contains a patch to callerid.c that MAY or MAY NOT solve this problem:

656c659

< /* Just trim off any trailing spaces */
---
> /* Just trim off any leading spaces or quotes */
658,661c661,664
< while(!ast_strlen_zero(instr) && (instr[strlen(instr) - 1] < 33))
< instr[strlen(instr) - 1] = '\0';
< /* And leading spaces */
< *name = ast_skip_blanks(*name);
---
> while(*(*name) && ((*(*name) < 33) || (*(*name) == '\"'))) (*name)++;
> /* And trailing spaces or quotes */
> ne = *name + strlen(*name) - 1;
> while((ne > *name) && ((*ne < 33) || (*ne == '\"'))) { *ne = '\0'; ne--; }

The above is offered only as something that could be tested to see
if it resolves the problem, providing you are comfortable with patching
and recompiling code. Be sure to save the original, unpatched file in
case it doesn't work. On the other hand, if anyone does get this to
work, a comment to that effect would be appreciated.