@scottalanmiller said in Starting to work on an initial FreePBX setup script:

Corrected the title to FreePBX instead of FeePBX, lol. Although that name would be useful somewhere, too.

go me

@WLS-ITGuy said in Aastra phone replacement:

I don't see a firmware for the T54W nor is the EXP50 available.

These phones are basically new since October or so. They will not be in EPM anytime soon because of how that has traditionally worked. The device manufacturer has to sing an agreement with Sangoma (Schmoozecom) to get a device supported. I assume, but do not know for a fact, that the agrement includes monetary compensation also, as anything in EPM is fully tested by Sangoma also, and testing takes manpower (money).

@JaredBusch said in FreePBX update negated/erased an Asterisk Dial Code we had set?:

@Dashrender said in FreePBX update negated/erased an Asterisk Dial Code we had set?:

yes, this would drive my users insane.

It is a setting. Turn it off.

I wouldn't want it off whole sale. I could definitely do that for most users, but my phone does have a display large enough to tell me I have missed calls - and I call those people back, even if they didn't leave a message. More often than not it's beneficial to call them back and solve whatever problem they were having.

Of something to note, this same format works for iPhone text messages, but not Android. This isn't an ordeal for me (as most of our user base are iPhone users) but might be worth looking into further to figure out why it works for one but not the other.

@JaredBusch said in Incoming Call Issue:

@VoIP_n00b said in Incoming Call Issue:

Running FreePBX v14... No resent changes made, except to change the name on an extension.

When some calls in, and let's say they dial 555 then end up getting 511, 511 can then forward the call to 555 no issue, but I have no idea what is causing this.

Because they released a horrible fucking update to IVR.

Edit your IVR and set strict dial time out to No - legacy

That fixed it! Thank you so much!!!

We had the same problem with VitalPBX, and @ScottAlanMiller's suggestion, we made the Opus codec the highest priority and it resolved the issue for us. Maybe it is worth a try for you?

@Romo said in Issues with remote PJSIP extension:

Same thing on Yealink SIP-T42S 66.84.0.80.

I'm out of easy ideas. I've been on site at a location all day.

@scottalanmiller said in Webex vs. Microsoft Teams + FreePBX conference:

@bnrstnr said in Webex vs. Microsoft Teams + FreePBX conference:

One thing I didn't like about teams is that you have to install a client to attend the meeting, which is the same for Webex and just about every other major solution if I remember correctly.

Zoho doesn't have a client either. All web based. Same as Rocket and NextCloud.

They all use the WebRTC components in modern browsers.

@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.

9e3c2ef7-462b-49f6-ae9f-036c302f4b68-image.png

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.

@cdbrush said in Setting up FreePBX to send a X-Tenant SIP header for Skyetel Tenant tracking:

This is great. Thanks.

What is this significance to the numbers within the "{OUTBOUND_ROUTE_NAME:0:4}" preceding the route name?

That’s a substring. Look at the route name, starting at character zero and going for 4 characters.

Looks like the problem is with the CDR database. If I remove that from the backup (temporarily), the backup completes as normal.

@Dashrender said in FreePBX with Centurylink IQ SIP ...:

CenturyLink/AT&T/Verizon, etc are all carriers AND ISPs

But all, by law, and by physical necessity, MUST operate them as two different things. That one company owns two businesses is just common sense. That's not relevant, it's still bundling versus not bundling. And none of them pretend that they are combined, all of those sell them separately, proving the point.

If you upgrade to FreePBX 16, the script handler needs updated to reflect PHP7.

The git repository is updated, but if you have an existing install, this will fix it for you

sudo sed -i "s/php5/php7/" /etc/httpd/conf.d/yealink.conf sudo systemctl restart httpd

@FATeknollogee said in Block Spam callers:

@Skyetel Haha, ROFL. Lenny is a star!! This Jerry Jones isn't very bright!

And I'm sure his name is really Jerry Jones. lol

@DustinB3403 said in FreePBX / Queue Login/out state on BLF key ...:

Looks like your question was answered here from last year.

https://community.freepbx.org/t/solved-queue-blf-hints/49665

Thanks, this did it.

I had put an extra * between the toggle code and the extension. Which interestingly enough still worked to allow an agent to login/out but didn't work with the BLF hints apparently. Once I changed as per the link you referenced it worked as expected.

For those that are interested I changed the BLF value in the EPM definition to :

*45__line1Ext__*730

(no * between *45 and the extension number):

Now a core show hints displays :

*45250*730@ext-queue: Custom:QUEUE250*730 State:Idle Presence:not_set Watchers 1

@JaredBusch said in FreePBX Ring Group / Remove CID Name Prefix on Transfer ?:

To my knowledge, there is nothing you can do to get rid of it without custom dial plan.

This process simply prepends the text to the existing variable.

Ok, Thanks.

@JaredBusch said in Unifi AP AC EDU with FreePBX ...:

@Dashrender all of the IP phones I have worked with can handle multicast natively.

That's good - I guess, and makes it even more weird that Ubiquiti didn't have their devices supporting it out of the gate.

@marcinozga said in FreePBX hardening ...:

@IRJ The scenario described above doesn't look like automated attack, and it's rather unlikely bots would be exploiting PBX to make international calls.

I think this is the first episode of the Darknet Diaries