New PJSIP trunk issues


(snaplink) #1

I’m using FreePBX with Flowroute and the Nevada Point of Presence is being retired tomorrow at 12pm PST and I’m working tonight on changing things over. I can currently make outbound calls from the office but dialing in does not work. When calling from my VZW Cell phone I receive a Verizon Wireless error message “Welcome to Verizon Wireless your call cannot be completed as dialed, please check the number and dial again”

I haven’t made any changed to inbound routes since creating the PJSIP Trunk. My inbound route goes to a time condition but as mentioned, nothing has changed there.

Unfortunately, I’m not sure where to go next with this to troubleshoot inside FreePBX and would really appreciate some assistance.

Thank you!


(Nate) #2

Is PJSIP running on a port other than 5060 (i.e 5160) and does Flowroute know about this?


(snaplink) #3

just double checked, it’s running on 5060. Flowroute support is closed right now so they don’t, yet.

I’ve made a dozen calls and it seems like I’ve got it somewhat working. Out of the 12 calls I’ve made 2 went through and the rest gave me the above Verizon Wireless error message.


(Nate) #4

Can you do a packet capture and see what port the traffic is coming in on or if it’s even coming to the server at all? Are there errors in your Flowroute CDRs that might help?

Try sngrep on your FreePBX server and see if you see any INVITE coming in when you make a test call.


(Nate) #5

Also, if you don’t already have it on, see if that goes to 100% if you enable Responsive Firewall for PJSIP, or add the Flowroute POPs to your firewall…


(snaplink) #6

I’ll check that now , standby!


#7

Flowroute sends calls from several different IP addresses. Make sure that all of them are properly forwarded through your firewall (and the FreePBX firewall) and are listed in Match (Permit) for the trunk.


(snaplink) #8

sngrep results. I’m seeing 5160 here which is odd because when I look in Asterisk SIP Settings>Chan PJSIP Settings, I see this second shot showing 5060

image


(snaplink) #9

Connectivity>Firewall>Networks shows this


(Nate) #10

Those are OPTIONS to what look to be your phones. Sort of a check from Asterisk to make sure they’re still online. My guess is your extensions are still using chan_sip. Either that or maybe you changed bind ports and didn’t restart Asterisk?

Press F7 and filter everything out except INVITE and then place a call in and see if it shows up.

Also make sure all those IP ranges are also in the Match (Permit) field on your trunk as @Stewart1 said.


(snaplink) #11

The extensions are sip, should I also change the extensions to Chan_PJSIP Driver?

my match (permit) settings:


(Nate) #12

I wouldn’t worry about the extensions for now. I would filter ‘sngrep’ to show just invites (F7) and then do test calls.

I would also check your Flowroute settings and verify that calls to your PBX are sent on port 5060.


(snaplink) #13

I made 6 test calls, 3 went through

I also confirmed Flowroute is using 5060


(Nate) #14

Ok, so they actually aren’t making it to the PBX. I would look at the Flowroute end then, and possibly (but less likely) the trunk config. With sngrep you will see anything that hits the PBX whether Asterisk acknowledges it or the firewall allows it thru. It’s monitoring at the network interface level. So if you only saw 3 hit your PBX, then the other 3 didn’t for some reason. Check your Flowroute CDRs, etc.


(snaplink) #15

Nate,

Thank you for your assistance tonight. I’m tired as hell now as it’s 2336hrs here, I’ll call flowroute in the morning and see what’s going on there.


(snaplink) #16

Flowroute support is saying everything looks good on their end.

My firewall vendor support is saying everything looks good after a packet capture and this was working without issue before moving to the PJSIP trunk.

Anything else I can look at on the PBX? The nevada PoP is being retired at noon so this is fairly urgent. I’m willing to pay for support at this point.


#17

Huh? Did they say that the failing INVITE did arrive from Flowroute and was properly passed to the PBX, i.e. the problem is with the PBX, or did they say that the problematic INVITE did not show up, i.e. the problem is at Flowroute?

Are you using registration at Flowroute, or are you routing your DIDs directly to your PBX public IP?


(snaplink) #18

The vendor is saying that they can see the packets coming into the firewall correctly but the freepbx isn’t accepting or receiving them.

I’m using host based routing for my DID’s in flowroute > interconnection > inbound routes

Calls aren’t even ringing when I dial from my cell. I type the number, it says calling and then the call ends.


#19

I hope they can see the packets coming into the firewall correctly and being forwarded to the PBX.

If so, then the problem is likely with the FreePBX firewall. You can check this by running sngrep and calling in a few times. sngrep sees traffic before the FreePBX firewall and if that’s your issue, you’ll see several INVITEs (because of retries) for each failing call. If that’s what you see, make sure that all the Flowroute subnets are configured as Trusted in FreePBX firewall.


(Dave Burgess) #20

Since you’re using IP authentication, this should be as simple as you can imagine.

Make sure the Firewall is forwarding all of the 5060 traffic from Flowroute to your PBX. Check this using TCPDUMP on port 5060 of the PBX.

If the traffic from Flowroute is getting “to” the PBX but not being processed by the PBX, check the Integrated Firewall and make sure that all of the IP addresses from Flowroute are correctly identified. Restart FreePBX to reset the Integrated Firewall. Check the 5060 port again and make sure that the traffic is getting in.

If you see the traffic showing up in the /var/log/asterisk/full file, the problem is in your inbound route configuration. Hosts that are not correctly identified in the firewall will show up as “anonymous” connections, telling you that your machine will reject those (since “Allow Anonymous” should always be set to “No”).

To be clear, inbound has almost nothing to do with outbound. If you have ANY outbound connection and have correctly identified the Permit hosts (which it appears you might have) in that config, any traffic from those address blocks will be allowed as valid (not anonymous) traffic.

This is two different problems. Note about firewalls (which I include just because I love to type): traffic that shows up in a tcpdump scan on a port is happening BEFORE the firewall, so if you see the traffic on the outside of your firewall and not the inside, it’s the firewall that’s messing you up. Same on the PBX - if you see the traffic on the Interface of the PBX but not in the logs, it’s the Integrated Firewall working correctly and blocking the traffic.

At the level of networking we are working with, there’s no “accept”. If the traffic makes it to the PBX server, the PBX server is either blocking it in the Integrated Firewall (possible) or it’s being misdirected to some other device. Also, the two conditions you describe are two completely different issues. Not “receiving” means that the traffic isn’t getting to the PBX, which is a problem with your firewall or network. Not “accepting” the traffic means that the traffic is getting to the PBX and is being rejected, either actively (through a “no way, go to heck” message back) or passively (through the Integrated Firewall).