FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ..."
-
I'm having an issue on inbound calls from a Skyetel trunk. Here is a capture of the asterisk messages on the incoming call (I x out our DID))
== Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Executing [12524xxxxxx@from-sip-external:1] NoOp("SIP/52.8.201.128-000001d6", "Received incoming SIP connection from unknown peer to 12524xxxxxx") in new stack -- Executing [12524xxxxxx@from-sip-external:2] Set("SIP/52.8.201.128-000001d6", "DID=12524xxxxxx") in new stack -- Executing [12524xxxxxx@from-sip-external:3] Goto("SIP/52.8.201.128-000001d6", "s,1") in new stack -- Goto (from-sip-external,s,1) -- Executing [s@from-sip-external:1] GotoIf("SIP/52.8.201.128-000001d6", "1?setlanguage:checkanon") in new stack -- Goto (from-sip-external,s,2) -- Executing [s@from-sip-external:2] Set("SIP/52.8.201.128-000001d6", "CHANNEL(language)=en") in new stack -- Executing [s@from-sip-external:3] GotoIf("SIP/52.8.201.128-000001d6", "1?noanonymous") in new stack -- Goto (from-sip-external,s,5) -- Executing [s@from-sip-external:5] Set("SIP/52.8.201.128-000001d6", "TIMEOUT(absolute)=15") in new stack -- Channel will hangup at 2019-08-21 10:40:29.601 EDT. -- Executing [s@from-sip-external:6] Log("SIP/52.8.201.128-000001d6", "WARNING,"Rejecting unknown SIP connection from 52.8.201.128"") in new stack [2019-08-21 10:40:14] WARNING[25477][C-0000052a]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from 52.8.201.128" -- Executing [s@from-sip-external:7] Answer("SIP/52.8.201.128-000001d6", "") in new stack -- Executing [s@from-sip-external:8] Wait("SIP/52.8.201.128-000001d6", "2") in new stack -- Executing [s@from-sip-external:9] Playback("SIP/52.8.201.128-000001d6", "ss-noservice") in new stack -- <SIP/52.8.201.128-000001d6> Playing 'ss-noservice.ulaw' (language 'en') -- Executing [s@from-sip-external:10] PlayTones("SIP/52.8.201.128-000001d6", "congestion") in new stack -- Executing [s@from-sip-external:11] Congestion("SIP/52.8.201.128-000001d6", "5") in new stack == Spawn extension (from-sip-external, s, 11) exited non-zero on 'SIP/52.8.201.128-000001d6' -- Executing [h@from-sip-external:1] Hangup("SIP/52.8.201.128-000001d6", "") in new stack == Spawn extension (from-sip-external, h, 1) exited non-zero on 'SIP/52.8.201.128-000001d6'It's telling me that it is rejecting an unknown SIP Connection
I then made change in the SIP settings to allow anonymous inbound like this :
This allowed the call to complete and be routed properly through our inbound routing but the call did not have audio in either direction. So allowing anonymous seems to let the SIP messaging complete successfully but the audio is lost somewhere.
Is it safe to allow anonymous inbound calls like this? If so, is my lack of an audio path most likely a firewall issue or something in FreePBX?
Thanks
-
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
Is it safe to allow anonymous inbound calls like this?
No. Never.
-
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
Is it safe to allow anonymous inbound calls like this?
No. Never.
Ok, thanks, I have disabled on my system.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
So my issue ended up being bad port forwarding. I guess most are using port 5060 for pjsip but on my system pjsip is listening on 5160. Once I changed the firewall port forward to 5160 then I had two way audio as expected.
For some reason though, the call drops automatically after 30 seconds, and this is repeatable. Every call drops this way. It looks like Skyetel is hanging up the call so not sure what is causing that at the moment.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
So my issue ended up being bad port forwarding. I guess most are using port 5060 for pjsip but on my system pjsip is listening on 5160. Once I changed the firewall port forward to 5160 then I had two way audio as expected.
For some reason though, the call drops automatically after 30 seconds, and this is repeatable. Every call drops this way. It looks like Skyetel is hanging up the call so not sure what is causing that at the moment.
Don't use PJSIP on non-stardard ports and you don't have this problem.
Gods I fucking hate people clinging to CHAN_SIP. Asterisk killed it years ago. Barely any updates for years now. I get that you probably followed some older guide or something but FFS I hate how some old shit never changes.
Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
Is it safe to allow anonymous inbound calls like this?
No. Never.
Ok, thanks, I have disabled on my system.
I was traveling Tuesday evening, busy all day Wednesday and traveling again Wednesday evening. sorry for hte slower than normal FFS and help.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
First you need to understand call flow.
When you make a call the PBX is reaching out to the SIP provider on WTF ever port you have setup. The PBX is the one in charge of setting up the ports for the audio. The PBX is the one sending information constantly about the call. There is no need to worry about port forwarding because the ports are automagically opened by the NAT setup like any other outbound connection.
When you receive a call, the provider side is doing all of that. Nothing is initiated from the PBX side. SO you have to ensure the inbound information can get through to where it needs to, aka port forwarding and firewalls.
So that means you need to make sure that you are forwarding all the right things. Additionally, you should only allowing this traffic from the @Skyetel IP blocks, but that is not important immediately as you have things not working right. Fix that first, then secure it properly.
So your PBX is designed to use a PJSIP based trunk on port 5160. This means INBOUND SIP TRAFFIC that you want to use the pjsip channel driver needs to come in on port 5160. This doesn't mean dick for outbound. You are behind NAT, your outbound connection might come from any port on your router.
Your PBX is also designed to use the port range 10000-20000 for RTP (the audio) traffic.
You need to port forward udp/5160 to your PBX.
You need to port forward udp/10000-20000 to your PBX.This is the extent of your router changes. On the assumption that a port forward setup obviously includes the router firewall also.
On your FreePBX system, you need to have the @Skyetel network IP blocks whitelisted in the FreePBX firewall as I mention in post two of my topic on setting up a Skyetel PJSIP trunk.
Once you have adjusted your router, FreePBX settings, and Skyetel Endpoint settings to all match, I would expect your problems to go away, or at least change.
The 30 second cut off you are experiencing are liekly because things are not talking back and forth to each other on the same ports and so the call is being hung up assuming the other side timed out or dropped offline.
-
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
So my issue ended up being bad port forwarding. I guess most are using port 5060 for pjsip but on my system pjsip is listening on 5160. Once I changed the firewall port forward to 5160 then I had two way audio as expected.
For some reason though, the call drops automatically after 30 seconds, and this is repeatable. Every call drops this way. It looks like Skyetel is hanging up the call so not sure what is causing that at the moment.
Don't use PJSIP on non-stardard ports and you don't have this problem.
Gods I fucking hate people clinging to CHAN_SIP. Asterisk killed it years ago. Barely any updates for years now. I get that you probably followed some older guide or something but FFS I hate how some old shit never changes.
The guide I used at the time as my template was this video from the Crosstalk Solutions youtube channel. He talks about those settings at about the 4:15 mark. I guess he got that part wrong and I unfortunately copied.
Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.
This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.
-
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
Is it safe to allow anonymous inbound calls like this?
No. Never.
Ok, thanks, I have disabled on my system.
I was traveling Tuesday evening, busy all day Wednesday and traveling again Wednesday evening. sorry for hte slower than normal FFS and help.
No problem. I really appreciate the help and the knowledge that you share on this forum.
-
@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.
Outbound calls are ok over this trunk. Two way audio is good.
First you need to understand call flow.
When you make a call the PBX is reaching out to the SIP provider on WTF ever port you have setup. The PBX is the one in charge of setting up the ports for the audio. The PBX is the one sending information constantly about the call. There is no need to worry about port forwarding because the ports are automagically opened by the NAT setup like any other outbound connection.
When you receive a call, the provider side is doing all of that. Nothing is initiated from the PBX side. SO you have to ensure the inbound information can get through to where it needs to, aka port forwarding and firewalls.
So that means you need to make sure that you are forwarding all the right things. Additionally, you should only allowing this traffic from the @Skyetel IP blocks, but that is not important immediately as you have things not working right. Fix that first, then secure it properly.
I had limited the incoming SIP traffic to just the Skyetel IP blocks (albeit I had the poorly implemented port forwarding going on as discussed in the other posts in this thread) but I had left the forwarding of the udp/10000-20000 as from any outside IP. I thought this was necessary for this block because Skyetel mentions on their site that their system architecture is such that their servers are not involved in the audio path and that audio comes directly from the PSTN.
https://skyetel.atlassian.net/wiki/spaces/SUG/pages/16580671/Our+Network+Topology
Maybe that's bad thinking and I need to lock down udp/10000-20000 to just their IP's as well. I'll experiment with that tomorrow.
So your PBX is designed to use a PJSIP based trunk on port 5160. This means INBOUND SIP TRAFFIC that you want to use the pjsip channel driver needs to come in on port 5160. This doesn't mean dick for outbound. You are behind NAT, your outbound connection might come from any port on your router.
Your PBX is also designed to use the port range 10000-20000 for RTP (the audio) traffic.
You need to port forward udp/5160 to your PBX.
You need to port forward udp/10000-20000 to your PBX.This is the extent of your router changes. On the assumption that a port forward setup obviously includes the router firewall also.
On your FreePBX system, you need to have the @Skyetel network IP blocks whitelisted in the FreePBX firewall as I mention in post two of my topic on setting up a Skyetel PJSIP trunk.
I had seen this thread that you had done and have made those changes.
Once you have adjusted your router, FreePBX settings, and Skyetel Endpoint settings to all match, I would expect your problems to go away, or at least change.
The 30 second cut off you are experiencing are liekly because things are not talking back and forth to each other on the same ports and so the call is being hung up assuming the other side timed out or dropped offline.
-
Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.
This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.
As @JaredBusch figured, this fixed my issue. Once I made this change I had two way audio and no call's being taken down prematurely.
-
@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":
Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.
This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.
As @JaredBusch figured, this fixed my issue. Once I made this change I had two way audio and no call's being taken down prematurely.
Audio issues are always port related. Though mostly because firewalls are fucking things up.
