Unable to make outbound phone calls HT813 Grandstream


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?

Review the log as a starting point:

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?

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.

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.

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


[2021-07-12 22:06:55] VERBOSE[32358][C-0000002f] pbx.c: Executing [[email protected]: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.

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).

1 Like

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).

1 Like


Apologies for the late reply.

I went through gigaset and I could not find anywhere where the 9283444002 was being prefixed.
I ran another test where I called the number 9283368211, and the following came back on the log:


Thanks in advanced!

It appears that you don’t have an Outbound Route matching 92833368211. If your Outbound Routes have anything in the CallerID field, that also could cause a mismatch.

1 Like

That was the issue! the CallerID fields had values in them. Once removed The outbound calling now worked. Yaay! :slight_smile:

Last question is the following:

My POTS provider allows me to have 2 simultaneous calls at the same time, however when someone calls into my IVR, only one call is answered by the machine. Is there a way for the IVR to handle multiple calls?

By default an IVR will answer anything presented to it as often as it is presented, We don’t know what “2 simultaneous calls” means yet. if you sent the first call out through that same carrier,would that count as a separate call?

1 Like

Apologies, I should have specified a little more.
My question is now in regards to inbound calls coming into my IVR;

Lets say, user A calls my office number, then my IVR gets the inbound call, it gets picked up and such user navigates through the options given to hear what they need.
While user A is playing with the IVR options, user B calls into my office, and because user A is still on the call, user B gets hanged up automatically with no options given.

My telephone provider gives me what I believe is call waiting, so that is how 2 employees at the office could answer the 2 calls from user A & B at the same time before implementing the IVR.

I’m trying to have the IVR answer as many calls as possible without the 1-call-at-the-time limitation.

You will have to check with your VSP where the second call is sent to. Generally that would be to the same as the first and the IVR that answered would so process it identically as the first call.

sngrep is your friend here

1 Like

If you have (or can get at low cost) ‘busy call forwarding’, set that up to forward to a number that comes in as a SIP trunk.

This does not sound like call waiting, unless it was possibly combined with another feature. With classical call waiting, the person on the first call would hear a beep and could press a key to put the first call on hold to answer the second. However, there would be no way for a different employee to answer the second call, nor would there be a way to transfer one of the calls to another employee and return to the other.


That certainly makes sense, surprisingly I did not check my VSP. Will definitely check with them to see if I can check the second call.