I have everything up and running. The only issue I have ran into is that I can’t get the GXW4108 to work correctly with FreePBX on Inbound calls. Outbound works great.
User Context: from-trunk
Currently getting this error: “Rejecting unknown SIP connection from IP_ADDR”
Any help would be greatly appreciated.
It’s not the solution to your problem, but you don’t need the incoming section if you are using a “type=friend” entry in the Outgoing section.
The IP_ADDR you are using should be the address of the GXW box. Make sure your IP_ADDR doesn’t have anything crazy like commas in it.
Alright, wasn’t 100% sure.
Yeah, IP_ADDR isn’t anything crazy, no commas or spaces.
Don’t use letters for the trunk name. Only numbers will get you a correct authentication. So instead of GXWT1 use 2345678 or any number that means anything to you, like your DID for example.
You also need to make sure that the field “Unconditional Forward to VoIP” is correctly filled. It should point to a valid SIP URI on your PBX.
So the numbers only Trunk Name is only for the Outgoing SIP Settings?
Each channel on the GXW4108 uses the phone number that it’s connected to. So does that mean I should create a user account for each Phone Number?
You don’t need to create one trunk per port, but if you do, each port will behave independently from the others. If you want a trunk like behaviour, create just one trunk and use the same username for all ports. You can use these docs as a starting point.
I’m using the same number for SIP UserID and Authenticate ID.
Looked over the documentation, actually made things worse (no outgoing phone calls).
But before that happened, I did get this:
Received incoming SIP connection from unknown peer to PHONE_NUMBER
WARNING,"Rejecting unknown SIP connection from IP_ADDR””
If you have default FreePBX settings with chan_sip on port 5160, you must set the GXW to connect to that port.
When I first set it up, I used this tutorial: https://wiki.freepbx.org/display/FOP/Configuring+a+Grandstream+GXW-410X+Device+to+act+as+an+FXO+Gateway
I have tried, 5060 & 5160. Setting both FreePBX and GXW to those ports, I end up with the same results.
The value of Sip Destination Port (in step 5 of the tutorial) must match the value of Bind Port in Asterisk SIP Settings.
If you still have trouble, please post current settings of trunk and GXW.
Step 5 says use 5060, which is what I tried on the GXW and is the Bind Port for pjSIP and also have set on my trunk.
For a quick test, I turned “Allow Anonymous Inbound SIP Calls” on and the call eventually did ring my phones, but after the 6th ring.
Current Trunk Setting
User accounts for all channels have the same UserID & Authenticate ID & Password.
For the delay, try setting Number of Rings Before Pickup to 1. If that reduces the delay, something is wrong with the caller ID setup. Do you know if the carrier is sending it? What country are you in?
The local port for pjsip is called port to listen on. In chan_sip it’s Bind Port. Your trunk is chan_sip, so set the destination port in the GXW to use what you have in Bind Port.
I did see the correct CallerID show up on the phone. In the United States.
GXW Listening and binding port match what FreePBX is using for Chan_SIP.
Please confirm that setting Number of Rings in GXW to 1 didn’t help the delay.
Please confirm that setting destination port in GXW forward to VoIP to match Bind Port didn’t fix the anonymous issue.
If you post your trunk configuration and the gateway configuration, specially the " Calling to VoIP" section, I might be able to help you.
Calling to VoIP
SIP Server: ch1-8:p1;
SIP Destination Port: ch1-8:5160;
SIP Channel Setting
DTMF Methods(1-7): ch1-8:2;
No Key Entry Timeout(X1s): ch1-8:4;
Local SIP Listen Port: ch1-8:5160++;
SRTP Mode(1-3): ch1-8:1;
Port Caller ID Setting
Number of Rings Before Pickup: ch1-8:1;
Caller ID Scheme: ch1-8:1;
Caller ID Transport Type: ch1-8:1;
Chan SIP Settings
Bind Port: 5160
What is connected to the FXO ports? If they are not copper lines fed from a telco central office, please explain (cable MTA, fiber ONT, locked ATA from VoIP provider, etc.)
To troubleshoot the delay, connect an analog phone (preferably a single-line line-powered corded one) in place of one line to the GXW. Call in and note when the analog phone begins to ring, relative to when you hear ringback tone on the calling phone. Possibly, some of the delay is fake ringback tone being played by the originating carrier.
If that’s not an issue, reconnect to the GXW and at the Asterisk command line, type
sip set debug on
and make a test call in. Note when you first hear ringback tone, when the incoming INVITE is sent to Asterisk, when the outgoing INVITE is sent to the extension, and when the extension starts to ring. You will then know whether there are delays in the GXW, in Asterisk, or in the extension.
All the FXO are CO lines provided by Frontier, so copper lines from a telco.
I hear the analog phone ring pretty much at the exact same time as the phone calling in. Which is about within 1 sec of hitting the call button.
When logged into the GXW, when I call a line that’s connected to the GXW, its about 1 sec that it’ll show the line is busy, then after the 2nd ring it’ll show the phones number that’s calling in.
After the 2nd ring, the INVITE request comes in.
chan_sip.c: Using INVITE request as basis request
chan_sip.c: No matching peer for ‘CELL_NUM’ from ‘IP_ADDR:5170’
chan_sip.c: Failed to authenticate device "CALLER_ID"sip:[email protected]_ADDR;tag=
Assuming that IP_ADDR matches what you have for host= in your trunk configuration, adding
to the trunk settings should tell chan_sip to accept calls from any port.
A normal US ring cycle is 2 seconds on, 4 seconds off.
Caller ID FSK typically starts 1 second after the first ring and takes less than 1 second to send, so the data is available about 4 seconds from the start of the first ring.
It appears that the GXW is taking about 8 seconds before sending the INVITE, so there is about 4 seconds of unnecessary delay. I don’t know whether there are any settings that might reduce or eliminate the extra delay. You may have to live with it.
If your calls are answered by an IVR or queue, 8 seconds to answer will sound normal to the customer and shouldn’t be a problem. If you are routing directly to a ring group where agents may not answer quickly, you may want to provide ‘music’ with appropriate announcements so the customer won’t abandon the call before it is answered.