FreePBX call not routing
-
I have a skyetel trunk delivering several DIDs to my FreePBX 15 (asterisk 16) system.
I added a new DID to Skyetel yesterday and also to my FreePBX and setup a destination - I'm getting "the-number-you-have-dialed-is-not-in-service" message from FreePBX.
Quick googling has lead me to an IP missmatch on the Skyetel trunk, so the system is rejecting the call basically.
Here is a log for the failed DID
log removed
The difference starts at line 5 where my failed line says
[2020-05-20 07:11:42] VERBOSE[7487][C-00001239] pbx.c: Executing [xxxxxxxxxxx@from-pstn:2] NoOp("PJSIP/Skyetel_trunk-000028b8", "Received an unknown call with DID set to 1xxxxxxxxxxx") in new stackand the working one says
[2020-05-20 07:17:06] VERBOSE[8358][C-0000123e] pbx.c: Executing [5312011927@from-pstn:1] Set("PJSIP/Skyetel_trunk-000028bd", "__DIRECTION=INBOUND") in new stack
[2020-05-20 07:17:06] VERBOSE[8358][C-0000123e] pbx.c: Executing [xxxxxxxxxx@from-pstn:2] Gosub("PJSIP/Skyetel_trunk-000028bd", "sub-record-check,s,1(in,5312011927,dontcare)") in new stack
[2020-05-20 07:17:06] VERBOSE[8358][C-0000123e] pbx.c: Executing [s@sub-record-check:1] GotoIf("PJSIP/Skyetel_trunk-000028bd", "0?initialized") in new stacketc.
I don't see any IPs listed here, so I'm not sure where to check what IP this call is coming in on?
-
Anything in the logs from Skyetel's side?
-
![2117b5fc-4fc1-4738-b907-a8b288078779-image.png]
removed image -
Do you have any Caller ID handling? That's where the two diverge. The one sends the one call one place, the other tries to identify the caller ID.
-
@scottalanmiller said in FreePBX call not routing:
Do you have any Caller ID handling? That's where the two diverge. The one sends the one call one place, the other tries to identify the caller ID.
No, I shouldn't, let me double check.
-
working DID
![caa71836-d2fb-44b3-8129-f2a0c5e8c780-image.png]image removedNot working DID
![80eb53e4-c475-4b01-8963-a864a14fa4d0-image.png]image removed -
Only difference is the destination, well, and the incoming DID #
-
@Dashrender said in FreePBX call not routing:
Only difference is the destination, well, and the incoming DID #
Anything different under Advanced or Other?
-
Also, try setting them to the same destination until it works, just in case it is a destination issue.
-
Skyetell sends an 11 digit number so basically your number with a 1 added by default unless you change it to send only 10 digits your inbound route is missing a one.
14029733266
-
@scottalanmiller said in FreePBX call not routing:
Also, try setting them to the same destination until it works, just in case it is a destination issue.
No change, still "not in service"
-
@Romo said in FreePBX call not routing:
Skyetell sends an 11 digit number so basically your number with a 1 added by default unless you change it to send only 10 digits your inbound route is missing a one.
14029733266
While this was not specifically the issue - it did lead me in a direction, found a change I missed on the Skyetel side - testing now.
-
@Dashrender - I haven't used Skyetel yet but do they have an inbound setting like voip.ms does? On voip.ms there is the device type under inbound settings - "IP PBX Server, Asterisk, or Softswitch" or "ATA device, IP Phone or Softphone".
-
OK anyone reading this in the future,
Skyetel has the option to set the SIP Format as seen here. Following their instructions for use with FreePBX requires changing this to +1NPANxxxxxx from 1NPANxxxxxx, then FreePBX will drop the +1...
In my case, since I didn't originally make this change, FreePBX wasn't dropping the 1 (It was looking for +1, didn't find it so it did nothing) and therefore my number didn't match.
image removed
-
@syko24 said in FreePBX call not routing:
@Dashrender - I haven't used Skyetel yet but do they have an inbound setting like voip.ms does? On voip.ms there is the device type under inbound settings - "IP PBX Server, Asterisk, or Softswitch" or "ATA device, IP Phone or Softphone".
Not that I know of, this is the trunk settings on the Skyetel side
FYI - my problem is now fixed, after I changed the SIP Format option.
-
@Dashrender said in FreePBX call not routing:
OK anyone reading this in the future,
Skyetel has the option to set the SIP Format as seen here. Following their instructions for use with FreePBX requires changing this to +1NPANxxxxxx from 1NPANxxxxxx, then FreePBX will drop the +1...
In my case, since I didn't originally make this change, FreePBX wasn't dropping the 1 (It was looking for +1, didn't find it so it did nothing) and therefore my number didn't match.
It is not their instructions. it is my instructions.
The guidance you were given, and that is stated in my instructions, is that you want your DID to be in a clean format within your PBX.
Skyetel, which defaults to the stupid NANPA format of 1NPANXXXXXX, gives you have no easy method built in to FreePBX to strip the 1, and thus have clean 10 digit numbers everywhere within your call flow.
So to fix that, you tell Skyetel to set your inbound calls to an actual standard called E.164. Then you tell your trunk that it is expecting calls in that standard, and that you are in the US, by using the built in context
from-pstn-e164-us. This results in the context stripping the +1 from the inbound call prior to any other processing by your PBX. Thus you only ever see 10 digit numbers in caller ID and redial history on the phones. -
@Dashrender said in FreePBX call not routing:
Quick googling has lead me to an IP missmatch on the Skyetel trunk, so the system is rejecting the call basically.
Dunno WTF you searched up, but it was wrong as shit.
Also, basic logic tells you that if the call is hitting your PBX it is impossible for it to be a firewall issue.
-
@Romo said in FreePBX call not routing:
Skyetell sends an 11 digit number so basically your number with a 1 added by default unless you change it to send only 10 digits your inbound route is missing a one.
14029733266
See my previous reply, but changing it to a 10 digit number is jsut as bad as the stupid 11 digit number.
Standards are a good thing.
-
-
@Dashrender if oyu are going to ignore my recommendations, then just create an any/any inbound route and point it someplace. Then you would never have had this problem.
Of course, when you tried to specifically route the DID to something later, it woudl not have worked, as it would not match and fail to the any/any route. but meh. At least you would not have been thinking of unrelated things like firewall.
