Unable to make outbound phone calls HT813 Grandstream

(Jma) #1


I’m having issues while trying to make outbound calls on my system. Inbound calling works like a charm tho.
I currently have the following setup:

FreePBX installed on a VM with an IVR system deployed.
My PSTN landline
Grandstream HT813 VoIP Gateway
Gigaset C530 IP Wireless phone system

I created an outbound route for emergency, & a general outbound route for all other calls, however when dialing any number, it sends my call to my IVR I have setup on my FreePBX.

Would anyone be able to point me in the right direction?

(Communication Technologies) #2

Review the log as a starting point:

(Jma) #3

I checked and I cant seem to determine why it forwards the call back to IVR. Do you normally need to create a new trunk for outbound? Or can I combine the inbound and outbound trunks?

(Communication Technologies) #4

Are you going to post the log so others could help?


So it was working on June 17 but isn’t anymore. Do you have any idea what caused this (system update, module updates, HT firmware update, manual config changes, etc.)?

Paste a log of a failing call at pastebin.freepbx.org and post the link here.

(Jma) #6

Hey Stewart!

Sorry, I’ll clarify a little more. Back then I didn’t have my IP phones just yet, so I couldnt test inbound or outbound calling; I was able to get my machine to pikcup the call and provide the prompts for the caller to choose. Just a couple days ago, I received my IP phones & I was able to get my IVR to transfer the call to my desk when the caller asked for a live person. The inbound call was properly transferred after playing around with the settings to match the IP addresses. Now, when trying to make an outbound call from my IP Phones that’s when I run into issues as it takes the call I make back to the IVR prompts. I will work on getting the log in the next few minutes, but kinda wanted to give you out a general overview of the issue.

(Jma) #7

Sorry for the delay, here is the link for the code:



[2021-07-12 22:06:55] VERBOSE[32358][C-0000002f] pbx.c: Executing [9283444002336821@from-sip-external:1] NoOp("PJSIP/anonymous-0000000c", "Received incoming SIP connection from unknown peer to 9283444002336821") in new stack

This makes no sense to me at all. Do you recognize any part of that long number? What device did you call from? What number did you dial? Possibly, this section of the log was triggered by an attempted attack and is unrelated to your failing call (do the time stamps agree with when you made the test call)?

Start with the simplest thing that fails. Does your device register ok? If not, we’ll troubleshoot that. Can you call *43 (echo test)? Can you call from one extension to another? After all these are working, we can look at outgoing calls.

BTW, when you paste logs, be sure to leave Delete After at Keep Forever, so future readers of this thread can follow along.

(Jma) #9

Yes sir, the 9283444002 is the IVR phone number, and then it seems it added whatever I dialed on my handset to it (the 336821 part).

When calling *43, the same thing happens. (Please see the code for the log of *43).

When I dial a different extension, the extension DOES ring & there we can hear each other. (Please see code below)

The handset seems to be properly registered (Or at least the GUI for Gigaset shows registered).


These calls are coming in to pjsip and the extension number is not being recognized.

Did you set up the extensions as pjsip; they seem to be chan_sip? If the latter, you likely need to specify port 5160 somewhere in the Gigaset config, as it seems to be connecting to port 5060.

If you can’t find the trouble, please post screenshots of the Gigaset config.

Also, at the Asterisk command prompt, type
sip set debug on
and paste a new log for a call to *43 (which will now include a SIP trace).

(Jma) #11

That is correct, they are set as Chan_SIP. I did change everything to 5160, and now the echo test works (please see the below for the log)

Also, please see below for my Gigaset config: is my FreePBX’s IP addres.


The echo test looks normal now. I’m guessing that the 9283444002 is somehow being prefixed by the Gigaset. If you have that number somewhere in its config, try leaving that field blank. If you believe that the number belongs there, please explain.

If outbound calls still fail, paste another log of a test call, including SIP trace (note that sip debug is canceled by Apply Config and must be reissued).