Cisco SPA-3102 PSTN Trunk Woes

Hi Everyone,

I’ve been trying to get this Cisco SPA-3102 set up as a PSTN trunk for what feels like forever, and I must have read and tried everything posted on these forums and on the wiki, but to no avail. I have the SPA setup as an extension (100) on Raspbx no problem, and Line 1 shows as registered on the SPA info page.

My problem is that no matter what configuration I try, I can’t get any inbound or outbound calls through the SPA-3102. The info page shows that the PSTN line is on hook, and when I call my phone number it will show the ringing status correctly, but it’s registration status always Unregistered.

I’ve attached some images of my configuration and I’m hoping that someone can spot something really obvious that i’ve missed because honestly, I feel like i’ve been banging my head against the wall for a long time now.

SPA PSTN Line Config

FreePBX Trunk Config

I’m seeing this error in the asterisk logs
[2019-01-31 16:38:23] ERROR[1050] netsock2.c: getaddrinfo(“SPA3102 ip address”, “(null)”, …): Name or service not known
[2019-01-31 16:38:23] WARNING[1050] acl.c: Unable to lookup ‘SPA3102 ip address’

however no where in my config is the string “SPA3102 ip address”

On the 3102, the udp port 5060 belongs to the fxs, not the fxo.

I have no idea where the error message came from. The REGISTER request from the SPA does contain a header similar to
User-Agent: Linksys/SPA3102-5.1.7(GW)
but it makes no sense that just the word after the / would be extracted. At a shell prompt, try
grep SPA3102 /etc/asterisk/*
and see if anything shows up.

Recent versions of FreePBX have pjsip on port 5060 and chan_sip on port 5160 by default. If that’s your case (check the value of Bind Port in Chan SIP Settings), the value of Proxy in your SPA config should be
If you changed chan_sip to use port 5060, be sure that you moved pjsip to another port or disabled it.

In the PEER Details, add
and remove

Don’t bother to test calling until registration is successful.

If it still won’t register, at the Asterisk command prompt, type
sip set debug on
then reboot the SPA. If you can’t tell what’s wrong from the results, post the log of a registration attempt.

Hi Stewart1,

Making those changes has made the SPA report that both the VOIP and PSTN lines are registered, but when a call is inbound it just rings out and doesn’t get forwarded, likewise any attempt to dial out over the trunk results in “Your call can not be completed as dialed”

Here’s the info page of the SPA and my route configs

For outbound calling, the Outbound Route is incorrect. I am guessing that you expect to dial 9 before an outside number. If that’s what you really want, leave the 9 prefix alone and set match pattern to
However, unless you are replacing a legacy PBX and need to maintain compatibility with that, I strongly recommend that you set up the system to dial outside numbers without any prefix. This avoids many problems, some technical (e.g. returning a call from device history won’t work) and some human (you should be able to dial the same way you use a landline or mobile). For this plan, the prefix should be blank, with
for the match pattern.

In your first post, the trunk name was pstn_fxo but your Outbound Route is using pstnfxo1 . If you have multiple trunks set up there could be conflicts.

If you still have trouble calling out, post the Asterisk log from a failed call, preferably with
sip set debug on
given at the Asterisk console before the attempt. Paste the relevant section of the log at and post the link here.

I can’t spot what’s wrong with incoming. Simplify it by leaving the DID number in the Incoming Route blank (making it a catch-all route) with a destination of a single known working extension (other than the one on the SPA). If that still doesn’t work, post the log for a failed attempt as above.

@Stewart1 I only have the one trunk, I changed the name during testing in case using the _ was causing problems.

I’ve done what you suggested and removed the 9 prefix, however dialing out still doesn’t seem to work. Here’s the log output of a dial out attempt from extension 101 to my mobile number.

I think the problem is these two lines:
[2019-02-01 16:15:52] WARNING[1988][C-00000025] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2019-02-01 16:15:52] VERBOSE[1988][C-00000025] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)

Which seems to suggest it thinks the trunk is busy or not there? I’m not sure I’m reading that correctly.

At the time of the call, the PSTN line was Idle

Usually, Subscriber absent means that the device is not registered. Possibly, Asterisk was reloaded and the test made before the 300 second expiry in the SPA expired and caused it to reregister. At least for testing, set (on the PSTN page) Register Expires to 60. Also, add
to the trunk PEER details. After applying config, wait one minute to be sure it has reregistered and examine
Reports -> Asterisk Info, Peers and confirm that the status for the trunk is OK.

Once you get that far, turn on sip debug and make another test call.

Here’s the Peer report

I guess I should be concerned about the UNREACHABLE status against the chan_sip peer. Is it supposed to be reporting the host as the loopback address?

Loopback address is definitely not normal. Try looking at the register request with sip debug to see whether the SPA is actually sending that in the Contact header.

Or, give up on registration. Set the SPA to not register and set host=(SPA’s IP) and port=5062 in the trunk.

1 Like

So I did all that and the trunk status was OK, but I still wasn’t able to make calls out over the SPA. I’ve since bricked the SPA by changing the IP settings to see if that would kick something into working and advertising the correct IP address in the REGISTER headers, but I don’t care enough about the damn thing to fix it.

I don’t suppose you’re aware of a decent VoIP gateway replacement are you?

I doubt that you bricked the unit. See .

Pick up the phone connected to the Phone port. Dial **** (ignoring whether you hear dial tone or any error tones). Do you hear the “Llinksys configuration menu” prompt? If so, do a Factory Reset as described above. After the unit has reset and finished rebooting, enable the Wan Port Web Server, then use option 110# to hear its WAN IP address. Open your browser to that address and set up the SPA again, from scratch. (This assumes that you computer is connected normally to the router, not to the Ethernet port of the SPA.)

If dialing **** doesn’t get you the prompt, unplug all cables from the SPA except the Phone port. Plug in only the power adapter, wait one minute, then pick up the phone and try **** again. If still no luck, report what the SPA indicator lights show.

There are several gateway devices with one FXS and one FXO port, including Linksys SPA3000 (very old), Obihai OBi110 (old) and OBi212 (current model), Grandstream HT503 (old) and HT813 (current). These are all very similar to what you have. There are also many professional gateways with four or more FXO ports. You’ll also find cards with one or more FXO ports that plug into a server chassis, rather than connect over the network. However, unless you are convinced that your present device is defective, I don’t recommend jumping ship yet.

You don’t need to use registration in order to make the trunk work. In fact, the most important thing to do and the easiest way to configure the trunk is to not use authentication. Just use host=ip_address_of_spa3102 and port=5062, if you haven’t modified the default configuration. I suggest you use chan_sip first.

Sure. I originally suggested registration, because I have an SPA3102 that is working fine with chan_sip and was hoping to duplicate the setup for the OP. My case needs registration because the SPA is behind a NAT on a dynamic IP and the PBX is in the cloud. I had hoped that copying as much as possible would quickly lead to a working configuration. Unfortunately, the OP’s SPA, for reasons currently unknown to me and him was apparently sending a bogus Contact header in the REGISTER request. I then recommended that he switch to a hard configuration, exactly as you suggest, which he did; he then reported that the qualify status of the trunk became OK. Unfortunately, call attempts still failed.

If he resets to factory settings, I hope that whatever mistake was made will not be repeated and it will start working. If not, we’ll have to use debugging tools to see what is really going wrong.

Setting up a SPA3102 recently because I’m having issues with at TDM400P I used this guidance. Includes a couple of settings changes to make things work.
I think in my case it was that the inbound user context and user name were not matching so incoming calls were rejected.

1 Like

FWIW, this was also helpful:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.