SOLVED Skyetel: Call records exist, but getting "The number you've dialed not in service..."

[JamesP]

Hello again,

So I'm using Skyetel. It worked just fine with HiFormance. Now I'm using hosting73. All of the setup completed, and I can get into the Incredible PBX admin area just fine. I've added the trunks, and setup my inbound and outbound routes.

After adding my inbound routes, I tried dialing the DID per the instructions. I'm getting "The number you have dialed is not in service. Please check the number and try again." However, when I login to skyetel's site, I can see on the call records page that it recognized my call. I also verified that my endpoint group is setup to go to my new public IP address at hosting73, and not the former IP address from HiFormance.

Incidentally, the Endpoint Health page on Skyetel's site indicates my endpoint is healthy. Three green status dots, so that's good.

The Endpoint group is using UDP and port 5060, also per the setup instructions. I'm hoping that's correct. It just seems strange that skyetele recognizes my call, appears to have endpoint group setup properly, but I'm getting a "not in service" message.

Any thoughts from the community?

As always, thank you in advance!

 

[The Deacon]

I'm running into this exact problem - has anyone else seen this issue or have a clue as to where to start?

Here is the output from asterisk when the call comes in:

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
> 0x7f0ce807edb0 -- Strict RTP learning after remote address set to: 208.93.41.141:14986
-- Executing [+1XXXYYYZZZZ@from-trunk:1] Set("SIP/Skyetel-1-0000001b", "__FROM_DID=+1XXXYYYZZZZ") in new stack
-- Executing [+1XXXYYYZZZZ@from-trunk:2] NoOp("SIP/Skyetel-1-0000001b", "Received an unknown call with DID set to +1XXXYYYZZZZ") in new stack
-- Executing [+1XXXYYYZZZZ@from-trunk:3] Goto("SIP/Skyetel-1-0000001b", "s,a2") in new stack
-- Goto (from-trunk,s,2)
-- Executing [s@from-trunk:2] Answer("SIP/Skyetel-1-0000001b", "") in new stack
> 0x7f0ce807edb0 -- Strict RTP learning after remote address set to: 208.93.41.141:14986
-- Executing [s@from-trunk:3] Log("SIP/Skyetel-1-0000001b", "WARNING,Friendly Scanner from 52.41.52.34") in new stack
[2019-01-26 11:06:45] WARNING[855][C-00000018]: Ext. s:3 @ from-trunk: Friendly Scanner from 52.41.52.34
-- Executing [s@from-trunk:4] Wait("SIP/Skyetel-1-0000001b", "2") in new stack
> 0x7f0ce807edb0 -- Strict RTP switching to RTP target address 208.93.41.141:14986 as source
-- Executing [s@from-trunk:5] Playback("SIP/Skyetel-1-0000001b", "ss-noservice") in new stack
-- <SIP/Skyetel-1-0000001b> Playing 'ss-noservice.ulaw' (language 'en')
> 0x7f0ce807edb0 -- Strict RTP learning complete - Locking on source address 208.93.41.141:14986
-- Executing [s@from-trunk:6] SayAlpha("SIP/Skyetel-1-0000001b", "+1XXXYYYZZZZ") in new stack
-- <SIP/Skyetel-1-0000001b> Playing 'letters/plus.ulaw' (language 'en')
-- <SIP/Skyetel-1-0000001b> Playing 'digits/1.ulaw' (language 'en')
== Spawn extension (from-trunk, s, 6) exited non-zero on 'SIP/Skyetel-1-0000001b'
-- Executing [h@from-trunk:1] Macro("SIP/Skyetel-1-0000001b", "hangupcall,") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/Skyetel-1-0000001b", "1?theend") in new stack
-- Goto (macro-hangupcall,s,3)
-- Executing [s@macro-hangupcall:3] ExecIf("SIP/Skyetel-1-0000001b", "0?Set(CDR(recordingfile)=)") in new stack
-- Executing [s@macro-hangupcall:4] Hangup("SIP/Skyetel-1-0000001b", "") in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/Skyetel-1-0000001b' in macro 'hangupcall'
== Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/Skyetel-1-0000001b'

 

[wardmundy]

Did you follow the Nerd Vittles tutorial??

 

[The Deacon]

Did you follow the Nerd Vittles tutorial??

I did - went back and double checked my work...

So the call makes it in, but the PBX doesn't quite know what to do with it - it reports that the number I've dialed isn't in service amd terminates the call, regardless which destination I send it to...

I deleted the inbound route and re-created it. Did the apply and for good measure, I rebooted the PBX. Now the output from asterisk is a little different...

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
> 0x7f96480602f0 -- Strict RTP learning after remote address set to: 68.68.120.25:21426
-- Executing [+1XXYYYZZZZ@from-trunk:1] Set("SIP/Skyetel-NW-00000002", "__FROM_DID=+1XXXYYYZZZZ") in new stack
-- Executing [+1XXYYYZZZZ@from-trunk:2] NoOp("SIP/Skyetel-NW-00000002", "Received an unknown call with DID set to +1XXYYYZZZZ") in new stack
-- Executing [+1XXYYYZZZZ@from-trunk:3] Goto("SIP/Skyetel-NW-00000002", "s,a2") in new stack
-- Goto (from-trunk,s,2)
-- Executing [s@from-trunk:2] Answer("SIP/Skyetel-NW-00000002", "") in new stack
> 0x7f96480602f0 -- Strict RTP learning after remote address set to: 68.68.120.25:21426
-- Executing [s@from-trunk:3] Log("SIP/Skyetel-NW-00000002", "WARNING,Friendly Scanner from 52.41.52.34") in new stack
[2019-01-26 14:52:24] WARNING[2856][C-00000002]: Ext. s:3 @ from-trunk: Friendly Scanner from 52.41.52.34
-- Executing [s@from-trunk:4] Wait("SIP/Skyetel-NW-00000002", "2") in new stack
> 0x7f96480602f0 -- Strict RTP switching to RTP target address 68.68.120.25:21426 as source
-- Executing [s@from-trunk:5] Playback("SIP/Skyetel-NW-00000002", "ss-noservice") in new stack
-- <SIP/Skyetel-NW-00000002> Playing 'ss-noservice.ulaw' (language 'en')
> 0x7f96480602f0 -- Strict RTP learning complete - Locking on source address 68.68.120.25:21426
-- Executing [s@from-trunk:6] SayAlpha("SIP/Skyetel-NW-00000002", "+1XXYYYZZZZ") in new stack
-- <SIP/Skyetel-NW-00000002> Playing 'letters/plus.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/1.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/X.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/X.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/X.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Y.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Y.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Y.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Z.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Z.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Z.ulaw' (language 'en')
-- <SIP/Skyetel-NW-00000002> Playing 'digits/Z.ulaw' (language 'en')
-- Executing [s@from-trunk:7] Hangup("SIP/Skyetel-NW-00000002", "") in new stack
== Spawn extension (from-trunk, s, 7) exited non-zero on 'SIP/Skyetel-NW-00000002'
-- Executing [h@from-trunk:1] Macro("SIP/Skyetel-NW-00000002", "hangupcall,") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/Skyetel-NW-00000002", "1?theend") in new stack
-- Goto (macro-hangupcall,s,3)
-- Executing [s@macro-hangupcall:3] ExecIf("SIP/Skyetel-NW-00000002", "0?Set(CDR(recordingfile)=)") in new stack
-- Executing [s@macro-hangupcall:4] Hangup("SIP/Skyetel-NW-00000002", "") in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/Skyetel-NW-00000002' in macro 'hangupcall'
== Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/Skyetel-NW-00000002'

 

[JamesP]

I ended up wiping the server and re-installing, and that seemed to do the trick. I'm a PBX amateur; I figured it wasn't anything on Skyetel's end based on what they were reporting. But I didn't know how to examine the logs and do any real troubleshooting on the PBX side. But everything is working now. Sorry, that's not much help!

 

[The Deacon]

I ended up wiping the server and re-installing, and that seemed to do the trick. I'm a PBX amateur; I figured it wasn't anything on Skyetel's end based on what they were reporting. But I didn't know how to examine the logs and do any real troubleshooting on the PBX side. But everything is working now. Sorry, that's not much help!

That's kinda what I was thinking about doing on this box too, but want to poke around with it just a little longer before I spent a couple of hours rebuilding it...

 

[mmfoley]

so I am having the same problem I have already STARTED FRESH new iso boot and still no such luck. I have almost the same log files as OP.

 

[mmfoley]

so I am having the same problem I have already STARTED FRESH new iso boot and still no such luck. I have almost the same log files as OP.

Ok figured it out, make sure the CID field in your inbound rout is set to "any" aka blank and not your phone number. I cleared this field and bam working like it should.

 

[wardmundy]

Actually, you should add an inbound route for each of your Skyetel phone numbers. Check the CLI to verify the format of incoming DID calls before adding them.

 

[mmfoley]

Actually, you should add an inbound route for each of your Skyetel phone numbers. Check the CLI to verify the format of incoming DID calls before adding them.

Agreed you can and will need a different inbound route for each DID aka phone number, but the tutorial doesn't show/screenshot how the inbound route should be set up. I know it talks about it, but unlike other parts of the tutorial it doesn't show a screenshot. The walk through is great but... make sure the CallerID field is blank in each of your inbound routes, this is what Skyetel says to do see pic attached.

 

[The Deacon]

TL; DR - Check the CLI to verify the format of incoming DID calls before adding them. @wardmundy was right!

Ok - So I solved this too, but my solution was initially different from what is listed above.

I noticed that when the call comes in from Skyetel, it is prepended with a plus "+" sign (e.g. +1XXXYYYZZZZ) . I added the plus sign to the inbound DID number and things worked as expected.

I went back to my account at Skyetel and started poking around a bit and found that the SIP format was set to include the +.

Once I changed the SIP format back to an 11 digit number, things started working as expected.

 

[wardmundy]

Another way to handle this is to change the context setting in each of your Skyetel trunks from from-trunk to from-pstn-e164-us.