Hi Guys
So until my local UK telco can provide VoIP trunks I’d like to try and get a Linksys SPA3102 working.
I’ve followed this excellent guide: http://www.aoakley.com/articles/2008-01-08.php
Connection to the PSTN is using a 4-wire straight through BT to RJ-11 cable salvaged from a working BT phone. Cable is fully tested and there are no issues there.
Line voltage measures 49.6V on-hook.
However I cannot get the SPA to work (even in bypass mode with power off)
Logging into the /admin/voice/advanced info page I see the following:
Line Voltage: 4 (V)
Registration State: Not Registered
I would expect to see a line voltage ~50V
Line impedance is set:
FXS & FXO Port Impedance: 270+750 150n
I’m not familiar with BT phones but have seen EU phones with nonstandard wiring on its RJ11 connector. The SPA Line port expects the Ring (-) wire of the pair on pin 3 and the Tip (+) wire of the pair on pin 4. I don’t know whether pins 2 or 5 connect to anything internally; to be safe your cord should not connect those pins to earth (or anything else). See https://en.wikipedia.org/wiki/Modular_connector#6P2C
for pin designations.
Likewise, the analogue phone should connect to pins 3 and 4 of the SPA’s Phone port.
If you still have trouble, check for ~50 V between pins 3 and 4 (the middle two pins) on the plug intended for the Line port.
The guide you linked does not set up PSTN->VoIP or VoIP->PSTN at all, so it’s not surprising that it shows not registered. You can set that up after the other functions are working.
Many thanks for the clear explanation. I’ll test this tomorrow when I get a few minutes spare.
Regarding the PSTN->VoIP setup I failed to provide all the info, this has been configured using the information here: https://frag.co.uk/2017/08/14/cisco-spa-3102-freepbx-uk-caller-id/
Although I kinda gave up on troubleshooting the whole shebang when I could not get the PSTN working.
Interesting though the FreePBX Dashboard shows the trunk as online.
I’ll dig around a bit more if I can get the PSTN up.
The setup in the frag link is using static configuration (not registration), so it is normal that the PSTN Line Status shows Not Registered. I did notice a couple of anomalies in that link:
It shows the trunk configured for Registration: Send. The SPA is not a SIP server and won’t respond to REGISTER requests, so the trunk will log the registration as failed (though that shouldn’t prevent you from making or receiving calls). Unless the author is depending on some bizarre side effect, Registration: None would be the correct setting.
He’s using Dial Plan 1 to send incoming calls to the PBX, so I’d assume that VoIP Caller Default DP should be set to something other than 1, e.g. 2, if Dial Plan 2 has the default value of (xx.)
PSTN Answer Delay is the time from when ringing is detected until the call is sent to the PBX. In most countries, it should be set to 4 to allow caller ID to be received after the first ring. But if BT is sending caller ID after a polarity reversal but before the first ring, setting it to 1 should suffice.
I have re-wired the BT cable and now get 49V when the line is idle.
If I dial into the line from my mobile the voltage is reversed to -49V.
So a good start.
Still not working from FreePBX though, calls never get picked up.
I’ve set dial pattern in the Outbound trunk to prefix with 9 but if I attempt to dial out from any extension I just get a busy tone and extension indicates line busy.
FreePBX Dashboard shows the trunk as online.
I’ll have another play around with it this evening.
Looks like I can get away with an answer delay of 1 and CID displays properly. Also get a nice fast answer.
The incoming DP of 1 defiantly works, I tried 2 and got some very odd stuff happening.
Apologies, just re-read your post and tried VoIP Caller Default DP: 2. I changed the incoming which was why it went odd.
Anyway 2 still does not route out to the trunk.
I assume this entry is of some significance:
[2019-05-02 20:12:12] WARNING[2689] res_pjsip_outbound_registration.c: Fatal response ‘501’ received from ‘sip:192.168.2.200:5060’ on registration attempt to ‘sip:[email protected]:5060’, stopping outbound registration.
Try changing VoIP Caller Default DP from none to 2. Also Auth INVITE to no.
If you still have trouble, at the Asterisk console type pjsip set logger on
attempt a call and post a new log.
The ‘Fatal response’ entry is caused by Registration Send in the trunk. Try setting Registration None.
After you get things working, I strongly recommend that you set up the system to not require dialing 9 before external numbers. I believe that extension numbers in the range 160-199 are unlikely to conflict with anything you’d need to dial externally. Start with 170-179, which AFAIK have not yet even been considered by Ofcom.
Apologies for the delay on getting back, it’s been a bank holiday weekend here.
So, I’ve made a bit of progress today and now make inbound & outbound calls.
Thanks for all your help in trying to resolve this.
Here’s the current working config for anyone else looking to get this working:
SPA3012 PSTN Tab:
SIP Settings:
SIP port: 5061
SIP Remote-Party-ID: yes
Auth INVITE: yes
Proxy and Registration
Proxy: FreePBX IP
Register: no
Subscriber Information
Display Name: ‘Landline’ – display this text if no caller ID available
User ID: pstn_fxo
Password: Secret – must match FreePBX pjsip settings below
Use Auth ID: yes
Auth ID: pstn_fxo
Dial Plans
Dial Plan 1: (S0<:My phone number>) – this dial plan is used for incoming calls
Dial Plans 2-8: (xx.) – default values
VoIP-To-PSTN Gateway Setup
VoIP-To-PSTN Gateway Enable
VoIP Caller Auth Method: none
Line 1 VoIP Caller DP: none
VoIP Caller Default DP: none
Line 1 Fallback DP: none
VoIP Caller Default DP: none
PSTN-To-VoIP Gateway Setup
PSTN-To-VoIP Gateway Enable: yes
PSTN Caller Auth Method: none
PSTN Caller Default DP: 1 – match to Dial Plan 1 on incoming calls
FXO Timer Values (sec)
VoIP Answer Delay: 0.3
PSTN Answer Delay: 1
PSTN Dialing Delay: 1
The FXO values will depend on your telco and FreePBX setup but the above work for me.
FreePBX settings:
Connectivity>Inbound Routes:
General Tab:
Description: Inbound-PSTN
DID Number: My phone number
Set Destination: Ring Groups>Household ring group
Other Tab:
Superfecta Lookup: yes
Superfecta Scheme: Default
Connectivity>Trunks:
General Tab:
Trunk Name: My phone number
Outbound Caller ID: My phone number
CID Options: default values
Maximum Channels: 1
Everything else is default:
pjsip Settings Tab:
General Tab:
Username: pstn_fxo
Secret: Secret – same as SPA Subscriber Information Password
Authentication: Outbound
Registration: None
SIP Server: IP Address of SPA
SIP Server Port: 5061
Context: from-pstn
Transport: 0.0.0.0-udp
Advanced Tab:
DTMF Mode: Auto
Permanent Auth Rejection: no
Qualify Frequency: 15
All other values default
Connectivity>Outbound Routes:
Route Settings Tab:
Route Name: PSTN
Route CID: My phone number
Trunk Sequence for Matched Routes: Trunk created with my phone number
Dial Patterns Tab:
match pattern: 0. – Note that is a zero followed by a dot
All other fields blank.
So now I can receive incoming calls with Caller ID. I’ve entered a few common phone numbers in the FreePBX phonebook and Superfecta will look them up and display who is calling.
I can make outgoing calls with any number beginning with zero.
A slightly annoying feature of the caller ID is that UK mobile numbers are displayed as XXXXX-XXXXXX. Superfecta will not find a match if the number is entered in the phonebook as XXXXXXXXXX. Now this may be down to my telco, so this will be work-in-progress.
Some observations:
Outbound calls take about 7-10 seconds to route through and ring
Inbound calls ring about 3 time on the calling phone before the internal extensions start ringing, so quite a delay there. I may have a go at tweaking the SPA timings but I don’t really see that improving without possibly losing the caller ID.
You should also allow short codes and other special formats, certainly 999 and 112.
You may want to dial local numbers without the area code.
If you have only one trunk, the match pattern could be [*0-9].
or even just .
to send anything (that’s not an extension or feature code) to the trunk.
If you actually see the - character in the CDR reports, you could filter it out by sending the Inbound Route to a Set CallerID which then goes to the Ring Group. Though not tested, my guess is that the value for CallerID Number should be ${CUT(CALLERID(num),-,1)}${CUT(CALLERID(num),-,2)}
Let me know whether this works (if not, post the bad result).
If you want to do more extensive editing, a custom context would be best.
I suspect that most of that delay is the Snom waiting to see whether more digits are coming, before sending the call to Asterisk. You can set up a dial plan to recognize when a number is complete and send the call immediately. Unfortunately, both the Snom dial plan and its documentation are user hostile. See http://wiki.snom.com/Features/Dial_Plan/Regular_Expressions and http://wiki.snom.com/Features/Dial_Plan/XML . Of course, there is also delay while the SPA waits for dial tone and sends the number as DTMF. You could try setting e.g. PSTN Dialing Delay: .5
and PSTN Dial Digit Len: .07/.06
then test if dialing out is still reliable. The only way to eliminate this delay is to use a SIP trunk instead of FXO.
Something seems wrong there. Find out where the delays are. From when the caller first hears ringing, how long until an analogue phone on the line starts to ring? Until the SPA sends the call to Asterisk? Until the extension rings?
Some of this is because some systems send Caller ID information after the first ring. Your SPA could take the call, get the CID information, then ring your PBX and wait (again) for the CID to be propagated to your PBX. To figure out if that’s the case, you’ll need to compare the logs in the SPA with the logs in Asterisk (/var/log/asterisk/full) and look at the time stamps.
True, but in UK the CPE is signaled to receive caller ID info by a polarity reversal. Then, caller ID is sent, followed by the first ring. The OP already has PSTN Answer Delay set to 1 and is not losing the caller ID info.
So it does look like the outbound delay was caused by the Snom in the office as even the UI was very sluggish. Well spotted Dave. Testing with the other Snom’s, and Softphone’s seem fine. A reboot of my office Snom seems to have made a difference.
I have also made the changes to the SPA Stewart suggested and all in all it does connect pretty quickly now (a couple of seconds).
The inbound delay I’ve not fully looked into yet, but I was calling in from my mobile while testing.
So I tried switching off the SPA (bypassing PSTN to connected Line 1 phone) and there is a delay of one to two rings before the analog phone rings so this may actually be some latency in the mobile network. (I have pretty poor network coverage)
Only thing really that I have found now that is slightly troublesome:-
For the moment I have my existing Panasonic DECT basestation plugged into the Line jack on the SPA as a temporary SIP phone. It’s quite handy as it means that we can pick up any incoming calls using these existing phones (which my wife really likes). We get all the caller info and can still use the built-in intercom feature to call the kids bedrooms. We can dial out & call all the other PBX extensions which is great.
Here’s the but:-
If I answer any call (internal or external) on the DECT handsets and the remote party hangs up, the line does not clear on the SPA line 1 jack.
I don’t see any setting on the SPA for line 1 to adjust detection apart from a few settings on the PSTN page. None of which seem to make any difference. I can see the remote party has been cleared on the SPA info page.
This may be something I’ll have to live with until I purchase suitable SIP DECT phones.
Any recommendations would be appreciated - I was thinking of sticking with Snom but now I’m not so sure, (Only reason I have Snom in the first place is that my previous employer supplied a 300 for my office phone. I kinda liked it so when I left that employ I bought some 821’s as I wanted a bigger display)
On the Regional tab, try setting CPC Delay to 2 and CPC Duration to 1.
If no luck, on the Line 1 tab, try setting Idle Polarity: Forward, Caller Conn Polarity: Reverse, Callee Conn Polarity: Reverse.
If still no luck, test: While on a call, unplug the Line 1 jack for 2 seconds and plug it back in. If the DECT handset still shows connected, it has no disconnect detection and you’re stuck until they are replaced.
Thanks Stewart,
You are spot on with the DECT phone, pulling the jack does not clear the call.
I can live with this until I get some new SIP DECT phones.
