@romo said in Errors in outbound calls in one extension - Freepbx:

This would be an inbound call right?

You have a bad inbound route setup (you have ports forwarded and no catchall any/any route) or you allow SIP guests.
This is a call terminating on your system but to with a DID you do not own.

This is a probe.

@jaredbusch Ok thanks for the explanation

@jnaugle also worth noting, no one actually delivers PRI today, that entire market is a scam. It's actually SIP and then they translate the SIP to PRI on your network edge to make it "sound cool" for people who are out of date and remember when PRI was both still available and actually practical (early 1990s and earlier.) PRI is not nearly as powerful as SIP, nor as cheap, so phone providers long ago "all" moved to providing SIP instead (PRI isn't possible without a physical T1) and "virtualizing" PRI on top of it. All the PRI does it increase cost and lower performance, flexibility and reliability.

So the best solution is to get the phone provider to stop pretending to do PRI and just give you the raw SIP. This improves your phone quality by removing unnecessary steps and limitations, removes the need for you to convert back to SIP (gateway, card, however you do it) and makes everything better for everyone. The PRI interface has no advantages, only disadvantages. It takes the better SIP, and cripples it.

For people running ancient phone systems from before VoIP, SIP isn't possible, so these terrible PRI interfaces are useful for them to continue to be able to hook up those ancient phone systems while still being able to connect to current phone companies. They aren't totally useless, but they are useful only for that one terrible niche case.

@jaredbusch said in Asterisk 13 CRITICAL ERROR! Required Service CHAN_SIP is disabled! This device is unusable!:

does chan_sip.so exist in /usr/lib/asterisk/modules/?

My guess is, no. But once we determined that there was no simple restoration and all evidence of chap_sip was gone from the system, they just rolled back to a snapshot from before the outage and all is well. So we might never know.

You may also want to look into cable management solutions as well.

@bigbear said in Manually Updating FreePBX:

@jaredbusch said in Manually Updating FreePBX:

@bigbear said in Manually Updating FreePBX:

@jaredbusch said in Manually Updating FreePBX:

@scottalanmiller said in Manually Updating FreePBX:

@bigbear said in Manually Updating FreePBX:

@scottalanmiller said in Manually Updating FreePBX:

@bigbear said in Manually Updating FreePBX:

So at this point I would assume a clean install of FreePBX 14 with Asterisk 14 is recommended?

I've had better luck with Asterisk 15.

So FreePBX14 with Asterisk 15?

That's what we are using.

Yes, FreePBX 14 with Asterisk 14 is what I have everywhere.

I was thinking this. 14 and 14. Have you used FreePBX14 with asterisk15 in production?

All of my production FreePBX 14 are Asterisk 15.

So now that everything is fixed and the update is complete I see the update software section of System Admin is gone. I had read that they can automatically manage security and updates now. Is that what you are doing, or did you disable it?

I prefer to do it myself because I don't want to deal with a down PBX. Granted that has never happened from a normal update, at least to me.

It is now under Admin -> Updates
0_1535136718470_ecab0baa-2524-40e2-889c-fa6997c2afbc-image.png

It has this scheduler, but it does not seem to actually do anything except check.
0_1535136794470_b9a17dbd-3dda-4446-8149-aa65545fb604-image.png

@obsolesce I think that is what I had to do a couple years ago once. No idea why it started doing it and couldnt figure out any other way.

@scottalanmiller said in All Yealink Phones Down at One Site:

@dbeato said in All Yealink Phones Down at One Site:

@scottalanmiller said in All Yealink Phones Down at One Site:

@i3 said in All Yealink Phones Down at One Site:

Factory reset a phone and try manually programming? How about a packet capture at the site firewall, do you see attempts from that IP phone to where? I am assuming that the PBX is hosted elsewhere.

This is basically where we went. We did this series of events and it appears to be fixed...

Rebooted the firewall. Removed SIP-ALG, but this appears to have had no effect. Updated the firmware on each phone. Went to static DNS rather than DHCP set. DNS to CloudFlare instead of AD. Ensures STUN was on and set correctly. Added the PBX as a Proxy, manually enabled STUN for the proxy.

After those seven steps, all phones are now registered. Couldn't find any step there that individually made a difference.

To me looks like the DNS was caching something for the devices to get to. That's my theory.

If so, why did changing the DNS alone not fix it?

Not sure, I am just going by what you said. Basically very strange.

github updated. files renamed a bit. Still a work in progress, but things working much better.

0_1533163657304_1cb7dbcf-38f3-48da-a102-fc1f7348fe17-image.png

The downside to this is that the FreePBX team simply implemented the no reboot flag to the existing reboot-yealink command. unlike the multiple commands for the Sangoma phones.

0_1543282841223_bc79c9df-ec75-492b-a23b-d976e99dd85a-image.png

So this means, you have no way to reboot Yealink phones at all with a built in sip notify command.

@jaredbusch said in FreePBX 14 super slow to update and then reboot:

I did not post a bug report there yet as I have no idea if this is reproducible.

I mean I reverted to the snapshot prior to the update and then did all of this. But I reverted because I had exactly this same problem after the update last night.

But I would expect a system to perform the exact same under this scenario.

We still have the error, but we did determine that it's just an error message and the clients can register fine. The registration issue was unrelated. So not a big deal, but it would be nice to know why we get this.

To Do: Find a way to make that the default setting on a new extension.

@tm1000 said in FreePBX 14 Module Update Errors:

Our QA team has confirmed that firewall has no issues:

https://community.freepbx.org/t/bug-in-latest-firewall-adding-ip-to-firewall-trusted-zone-no-longer-updates-iptables-firewall-rules-on-firewall-restart/50181/9?u=tm1000

I've got a few on the latest and haven't seen anything ourselves, yet. Seems good.

/sigh. The expected answer.
0_1527375600424_4f024dd0-c6f1-42f4-a1a0-055199a803e3-image.png

I know that EPM is a huge pain in the ass. But that is also why I willingly pay for it.

Made no configuration changes to the firewall tonight. Shutdown FreePBX VM, made a new one, and stuff seems to be working as it should. I'll do a few more tests tomorrow to make sure all is well.

Edit: I lied. I made a new DHCP reservation for my new FreePBX server.

@dashrender said in FreePBX - Determine if Extension has dedicated callin:

Look at your inbound routes. See what the destination on the inbound routes are.

Yup, that extension itself doesn't know what points to it. So it is looking at the pointers. Think of the Inbound Routes like aliases and you are looking to see if an alias mentions that extension.

@Danp Instead of disabling globally, it would be better to temporary change the DNS on your computer instead.

It's my first time running into it. Wondering if it might not be a corrupted client.