HT813 FXO / FXS - 172.16.50.119
HT814 4 port FXS - 172.16.50.118
FreePbx 172.16.40.64
VLAN configuration - Router on a Stick Pfsense,
I did have them all on an isolated VLAN, but I have moved things about to simplify the debug process.
I am thinking of factory defaulting all of the ATA units and doing a complete reinstall of FreePBX and not restoring any backups.
At this point, it seems like overkill, since you may be fairly close.
Do one of the following:
Hi,
I seem to have internal to external calls partially working. I can now get external numbers to ring such as my mobile number except it is not quite right.
Calls from FreePBX seem to ring for a second and then stop and go quite. The mobile then starts ringing but if I hang up the call from the FreePBX side it carries on ringing for 20 seconds or so.
External calls into the system is not working at all. I have an incoming route defined and a ring group.
So paste logs (with pjsip logger on) for both outbound and inbound cases. Do internal calls work correctly?
Internal calls were working but seem to have stopped.
I am going to try and get everything moved back to the same VLAN on the same switch to cut out problems with firewalls etc
Hi,
I have had some time to come back to this and I now have internal calls working and I can even make external calls via the HT813 adapter.
Incoming calls from the BT Openreach PSTN Line still do not work and they seem to immediately place the external party on hold, and then hangs up the call. No internal phones will ring.
The other issue I have is when placing an outgoing call the first few seconds of the call are missing. I think this has something to do with the DTMF settings on the HT813.
The Ht813 is showing as having the FXO port and the FXS port as registered and they show up in Asterisk reports.
I have disabled the firewall and have added all of my internal VLANS under Asterisk sip settings for NAT.
The configuration on the HT13 FXO port is to send all calls to trunk user 900
I have an incoming route with a catchall dial plan and I have ring group setup to call all of my extensions.
I can provide logs if you specify what you need and can check settings if you tell me which ones.
Thanks
If you mean there is a delay between when the callee answers and the caller is connected, that is probably because the HT813 isnât detecting the battery reversal used to signal answer supervision, and is applying a fixed timeout after dialling. (Iâm finding it difficult to get a clear answer from Google, but unless you have a line intended for business PABX use, you may find that there is no answer supervision, as the caller is expected to use their ears to detect answer. One problem with documentation is that such lines probably havenât been sold for a long time. Iâd assume a hub emulating the PSTN interface probably wouldnât provide it. In any case, the HT813 administration guide doesnât explain if and how it is handled.).
You havenât included an image of the page on which you set caller ID mode to SIN 227.
You should make sure that the A and B wires are connected the right way round. It is possible that line reversal detection only works when this is correct.
In any case, this is a question about the adaptor, not about FreePBX.
You almost certainly need logs from the adaptor, rather than Asterisk.
With pjsip logger turned on, does anything appear in the Asterisk log on an attempted incoming call? If so, paste that. If nothing, set up syslog on the HT and paste what gets logged there.
The issue with the outgoing call audio being cut off is identical to this post
Outgoing call, 9 second delay - FreePBX / Endpoints - FreePBX Community Forums
His solution is the exact same solution I tried previously which seemed to cure the issue. Can anybody confirm the correct value for UK PSTN lines from Openreach?
Please explain when the delay occurs:
If you call your mobile and donât answer, is there a 9 second delay before it starts ringing? Or, does it take 9 seconds after it starts ringing before you hear the ringback tone on the PBX extension?
If you call your mobile and answer quickly, is there a 9 second delay before the PBX user can hear the mobile? Is there a 9 second delay before the mobile can hear the PBX user?
Ok
Perfect example for outgoing calls if you ring 1471 you do not hear any ringing, the audio suddenly cuts in and you can listen to the number of the last person who called except the first two numbers have already been read back to the caller.
When I adjusted the DTMF settings to match the changes the user in the other thread made it works perfectly on outgoing calls. No missing audio or parts of the conversation.
The solution quoted in Outgoing call, 9 second delay - #10 by RichieH doesnât really make sense. It speeds up the sending of the number, but the value suggested is the absolute minimum allowed by SIN 351, and the change from 60 to 40 would only make a 1/5th of a second difference in the time to set up a call to a 10 digit number.
Best practice would, I think be to use something more like 150% of the minimum, so the 60% he claims doesnât work would seem to me to the reasonable value to use. A human dialling would, almost certainly significantly exceed this. I can successfully dial 1471 with digit and pause lengths over 500ms each, so long ones are not a problem, at least for my exchange, which was System Y (Ericsson AXE), but might have changed. (Simple phone, directly to domestic line.)
My feeling is that this is to do with how the HT813 handles answer detection, which is always a problem when using analogue lines, particularly domestic ones or one man type business ones. Unfortunately, the administration guide does not explain how answer detection is handled.
(If you used Asterisk, directly with analogue hardware, I think your choices would be answer supervision by a line reversal, or using dialplan logic on the audio (e.g. silence detection). I suspect, in your case, line reversal is not a service that will be provided, and it is not clear that that the HT813 would support it. It looks as though it doesnât offer an option of answering the SIP side immediately after sending the digits, which is what Asterisk DAHDI would do, with line reversal detection off.)
Are you picking up the called phone very quickly. Itâs possible the HT813 looks for ring back tone, followed by silence and signals SIP answer when the next round of ringing doesnât start when expected. Maybe some echo of the last digit is being recognized as ring back tone, in the other 9 second delay instance that you reference, and the 9 seconds is the fallback timeout for never receiving ring back tone.
The normal advice when answer or disconnect supervision is important, is not to use an analogue interface.
Hello,
I can confirm that setting the DTMF Dial Pause (ms) value higher than 40 causes a delay in audio when placing calls using the Grandstream HT813 with an FXO connected to a domestic landline. Iâve just re-verified this behavior, and my current settings are identical to those I shared in the linked forum thread last year.
As a test, I adjusted the DTMF Dial Pause (ms) value again, and the issue persists: any value above 40 results in the beginning of calls (e.g., dialing 1471) being cut off.
I agree this issue is likely tied to the HT813 firmware, specifically how it handles answer detection. While the expected value for DTMF Dial Pause might differ, setting the value to 40 has consistently resolved the problem for me.
Cheers,
Richie
Here is a pastebin from the HT813 syslog.
The call is placed on hold and then hangs up
Looking through the Pjsip log for the correct partsâŚ
The line reversal to start the SIN 227 caller ID sequence was at 2024-11-20 20:37:49
The incoming caller ID was 07824-037101 at 2024-11-20 20:37:50
First ring was at 2024-11-20 20:37:50
There was only one ring, which ended at 2024-11-20 20:37:51
An incoming PSTN call was recognized at 2024-11-20 20:37:51.
The SIP request URI user (DID) was 900.
It was answered by SIP at 2024-11-20 20:37:52
Original line polarity was restored at 2024-11-20 20:37:52
It was closed by FreePBX at 2024-11-20 20:37:54, with reason 16, which is normal clearing.
At NO time was the HT813 told that it was on hold.
This is inconsistent with the OPâs report that nothing appears in the Asterisk log on an incoming attempt. Conceivably, the HT is badly misconfigured and sent the call to the wrong PBX?? More likely, the Asterisk log was not correctly monitored. Please turn on pjsip logger, make another incoming call attempt, and if anything appears in the Asterisk log, paste it. If itâs really nothing, please post screenshots of ALL the HT FXO settings.
Hi,
I am hoping to have time to play with this fully this weekend however I should clarify it is not the HT813 that is saying the call is on hold. The call is on hold message is what appears on the mobile handset that dials the landline number. No music on hold is played. The number is called and the handset immediately says the call is on hold and then hangs up.
Upon removing the HT813 from the physical line connection and plugging in either a hardwired phone or DECT device all works as expected.
Thatâs how CLEAR and RELEASE signalling is handled on analogue networks, particularly for the called number.
When the callee hangs up the phone the underlying digital network sends a CLEAR signal, which some SIP gateways and, at least, some mobile phones, will interpret as HOLD. There is then a period in which the phone can be taken off hook, again, and a REANSWER signal sent, which will remove the hold. If the caller doesnât hang up first, the network will send RELEASE to both ends, at which point the call is over.
Originally the delay before network release was several minutes, with the intent that if you have several extensions wired in parallel (plan 1), you could put the phone down in one room and pick the call up in another, without losing the call.
Because scammers took advantage of this by getting victims to phone their bank, to check the call was genuine, whilst simulating dial tone, and people used DECT phones, rather than multiple extensions, this was reduced to a few seconds, but there is still a delay between called party CLEAR and network RELEASE.
Itâs possible that lines intended for PABXes went straight to RELEASE, but anyone doing anything with Asterisk in the UK now, with an analogue line, is likely to be using a line intended for a phone, and, almost certainly, a domestic one.
Logs, please, including pjsip logger.