[HT813] Delay on Outbound Dial to Analog Line

#1

Hello there,

I’ve recently deployed an HT813 directly locally linked to a FreePBX (Asterisk 19.3.2). HT813 is connected as a trunk to the Asterisk, so the registration is deactivated. I have an outbound route configured in the Asterisk to hand over the calls with this dial pattern to HT813. Incoming calls (Analog line from FXO to any VOIP extension) work perfectly.
For the outbound calls, when any VOIP Extension dials to an external (analog) extension, it’s properly handled to HT813 but Grandstream is taking ~8s to initiate the dial/ringing on the analog line.

Checking on FreePBX logs we have:
[2022-12-30 18:08:31] VERBOSE[12478][C-00000010] app_dial.c: Called PJSIP/95@Grandstream
[2022-12-30 18:08:39] VERBOSE[12478][C-00000010] app_dial.c: PJSIP/Grandstream-00000022 is ringing

Full PJSIP Logs here: https://pastebin.com/LxjiQiGy

I’ve read that these delays generally are caused by DNS resolution, but I do have the Asterisk hostname on the hosts file. Also, to my naive eyes, it doesn’t seem like an Asterisk fault as in the logs we can see the 8s delay between Grandstream sending the “SIP/2.0 100 Trying” and the “SIP/2.0 180 Ringing” (Actually ring).

My infrastructure and issue seem very similar to this issue: https://forums.grandstream.com/t/ht813-dial-delay/34404

Has anyone ever seen this scenario and has a clue which configuration I’m missing here?

Thanks a lot and Happy Holidays!

#2

Dial plan matching not set perhaps as it sounds like the HT813 is using the standard dial wait time before dialling.

#3

Thanks for the reply. Where exactly can I fix this Dial Plan Matching?
Currently, I have the following set on the FXO tab. How should I adjust it to match my analog extensions (2 or 3 digits numbers)?

image
image.png1394x352 75.6 KB

I couldn’t find additional details about this field in the HT813 manual.

Thanks again.

#4

Dial Plan = area to fix… I am unsure as to what your standard dial plan is for your country, but you need to map to your codes eg…

In Australia / Victoria state we have local numbers starting with 4,5,7,8,9 that are 8 digit length…

So in the dial plan we could have {}

Australian Dial Plan
{ 1xxx |0011xxxxxxxxxxx|61xxxxxxxxx|0xxxxxxxxx|[3-9]xxxxxxx|13xxxx|1800xxxxxxx|1300xxxxxx|911|000}

The above is also to cover most if not all of our codes for Victoria to give you an idea of how to.
See my original post…
https://forums.grandstream.com/t/australian-tone-settings-for-ht8xx-series-and-dial-plan/45729

#5

Thanks for the support.
I’ve changed the dial plan from the one I’ve shown earlier ({ x+ | +x+ | *x+ | xxx+ }) to the same one I’m using as Outbound Route on the Asterisk ({ 000XX | 00XXX | XX | XXX }). As the number I’m dialing in this test is 00095, it should match.
But unfortunately, I’m facing the same issues (9s delay):

[2022-12-30 20:41:09] VERBOSE[22036][C-00000014] app_stack.c: Spawn extension (from-trunk, 00095, 1) exited non-zero on 'PJSIP/Grandstream-0000002a'
[2022-12-30 20:41:09] VERBOSE[22036][C-00000014] app_stack.c: PJSIP/Grandstream-0000002a Internal Gosub(func-apply-sipheaders,s,1(1)) complete GOSUB_RETVAL=
[2022-12-30 20:41:09] ERROR[19500] res_stir_shaken.c: Failed to retrieve certificate for caller ID '00095'
[2022-12-30 20:41:09] ERROR[19500] res_pjsip_stir_shaken.c: Failed to sign STIR/SHAKEN payload
[2022-12-30 20:41:09] VERBOSE[22036][C-00000014] app_dial.c: Called PJSIP/00095@Grandstream
[2022-12-30 20:41:18] VERBOSE[22036][C-00000014] app_dial.c: PJSIP/Grandstream-0000002a is ringing
[2022-12-30 20:41:18] VERBOSE[22036][C-00000014] app_dial.c: PJSIP/Grandstream-0000002a answered PJSIP/1001-00000029
#6

It is not clear to me what the expectation is. The HT translates/converts the SIP signaling to the actions needed to take the analog line off-hook, let the analog line settle, initiate the dial sequence and then allow the PSTN do its thing by routing the call to its destination. How long all that may take, I have no clue. However, if you take an analog phone and hook it directly to the line and dial out, how long then?

#7

@rcarlet

Try with small x instead of X

#8

The dial plan is not the issue, other than the entry shown in the snippet with the “+x+” as the “” (back slash) is not a valid entry and the “+” following the back slash is also not an acceptable entry based on its location. As there is no DTMF tone for a +, it cannot be before any defining character such as any digit, x, etc… The + is used to indicate that more than 1 digit or character can follow the initial entry so that you need not explicitly define all possible dial strings that you may need.

The number being dialed was sent in the initial INVITE which came from the PBX and the x+ entry took care of it as the entry x+ indicates that the received dial string from the PBX must be at least 1 digit (0-9) long. The + is used to tell the HT that any number of digits following the first digit is fine.

If you use x by itself, then you have told the HT that the only dial string it will accept is that which is 1 digit long.

The dial strings are not the same between asterisk and the HT, but the one you show from asterisk will also work with the 000xx and the 00xxx for your 00095 number as you have shown. The xx and xxx are telling the HT to also use 2 and 3 digit numbers.

It is not a DNS issue either as you have pointed out.

I do not know what number 00095 is trying to reach. Have you tried other “standard” numbers for your locale?

There are only two delays that the HT encounters in its settings. The first is to wait for dial tone before dialing and then the second is Min delay before dialing PSTN which is usually 500ms.

You could always tap into the analog line with a butt-set to listen to what is actually transpiring during a call and this may shed more light on the issue than anything.

#9

I beg to differ from Larry as you have not mentioned any other device / end point exhibiting the issue outside of the HT813. Usually dial plans have a wait till it matches a dial string before presenting the number as a valid string sent to the upstream.

Ergo to me it would appear to be a dial plan issue in the HT813 not receiving the digits necessary, but may be I am missing the point from your diagnostics and answers…

#10

Nope. If it did not agree with the dial plan, the HT would have responded with an error. It also would not have sent the Trying, Ringing and the call was answered according to the trace (below). However, I do note that in the trace the call was to 95 and not 00095 -

image
image.png1126x544 20.3 KB

I also found this release note from 3/21 on the version prior to what is shown on the above -

Fixed outbound VoIP to FXO slow call setup and loss of audio at start of the call

Nevertheless, a butt-set intervention (how bad does that sound?) would reveal all.

#11

I read that after a valid number was dialled, that the call did not proceed until a timer elapsed (8 seconds) ergo why I answered the way i did. I believed the HT813 was waiting for a valid digit train before it would dial or would wait till the dial timer lapsed.

So as far as I know - Asterisk - set to dial through the HT813 to the FXO port of the HT813

Asterisk extension --> Asterisk dial plan --> to HT813 --> FXO --> PSTN

#12

The delay was experienced between the 180 trying and 183 ringing, so the HT already had the number and was either in the process of dialing or already had and was waiting on the PSTN. What the user experienced was a delay before hearing the ring.

#13

I dont do downloads through this forum… but ok…

#14

After your amazing insights, the mystery has been solved!
Sorry for the delay, I couldn’t find an RJ11 splitter in a local store so I had to build a small jack to debug. Besides that, if I had a phone hooked in parallel, the HT didn’t dial and gave a busy sign. So I had to wait for for the HT to initiate the line to take the phone out of the hook. Having the debugging scenario in place, I found something.

Indeed, it is mainly the fixed line fault as @lpneblett suspected. The 8-9s were mainly for HT waiting for line, dialing, and the analog line answering with the ringing tone.
@lpneblett thanks a lot for your time and detailed explanations. I’ve turned off the “Wait for Dial Tone” and the time reduced by half. I’ll leave it like this and evaluate the negative impacts of having it that way:

[2023-01-05 14:46:58] VERBOSE[1522][C-0000000d] app_dial.c: Called PJSIP/95@Grandstream
[2023-01-05 14:46:58] ERROR[18347] res_stir_shaken.c: Failed to retrieve certificate for caller ID '95'
[2023-01-05 14:46:58] ERROR[18347] res_pjsip_stir_shaken.c: Failed to sign STIR/SHAKEN payload
[2023-01-05 14:47:03] VERBOSE[1522][C-0000000d] app_dial.c: PJSIP/Grandstream-00000019 is ringing

Clarifying the “weird” number format, it’s an internal intercom I don’t have direct access to the PBX, so not a public Land Line.

Thanks again and cheers from Brazil.