Search results

Yeh, we do it all the time. The default out of the box config for FreeSwitch is designed for a medium sized PBX. I'd up it to at least the number of extensions you have. The only thing to look out for is performance issues if it's too many, by watching CPU usage.

Looks like it's missing the 'answer' to me.

It's a big blast of invites, for the most part it will probably be fine but you'll really have to test it out yourself. I can't remember if it requires upping the FreeSwitch limits to beyond 30 sessions per second or not. I recommend if your phones have the capability and you are on the same...

Only when you create one, after you pulled that update. If you did at all, you can always compare a working one in the dialplan with a broken one. The IVR is in XML format, so make sure to click the button in the top right for XML

sofia_profile_name in the CDR detail probably if you see one. If you can post a log of an attempted call, that might help. Remember to find and replace any sensitive information like phone numbers and domain names.

It's free CPU usage. It's dumb, and I'm not entirely sure why they added it tbh.

It typically won't be an issue on most routers as the port will be rewritten to another external port during the NAT process. You only really need to change this when an overzealous IT admin has created a custom firewall rule to drop traffic sourced from/to 5060.

If the phones are in the external context, that tends to tell me that they are not registered and are simply sending INVITES to the PBX.

"Thomson Speedtouch ST546 v6 DSL modem/router" Holy shit, a 546! That was my first router I dabbled with back on the support desk days. No WiFi on the bugger, but it did have an SNMP responder!

Possibly the behaviour change is this commit? https://github.com/fusionpbx/fusionpbx/commit/92123052e1921adccc8b48248f48bdb2b3e87412

Probably a question for your SIP trunk provider, I have seen a similar fault where an inbound carrier had the DTMF clipped as some sort of VAD/compression, was only for specific routes into the network though.

It's way easier if your SIP endpoint does this already, most do at least support a 3 way. Alternatively, the att_xfer feature of FreeSWITCH does allow you to make a 3 way upon pressing a designated key. There is already a *4 bound digit: I suspect all that needs adding is the feature code to...

Does the INVITE look correct when it arrives at the PBX? You can monitor SIP traffic via SSH using sngrep. You should see at least one field on an INVITE that has the caller ID in the FROM, Remote-Party-ID or P-Asserted-Identity headers. If we don't, then the carrier might be stripping it for...

https://docs.fusionpbx.com/en/latest/additional_information/sngrep.html Run sngrep, check your INVITE messages. Is it being sent in a form that your carrier needs? Some want E164, some want local presentation, some want it in the RPID, some in the PAID fields, etc. Alternatively, ask your...

You'll have to use sngrep to capture what you are sending, and what the carrier is rejecting because that is how it works.

The SBC is required in some form, either an appliance, hosted, cloud or as a service because Teams isn't talking SIP. You also have to have some logic to bridge calls, send them out a special trunk, etc for the Teams 'extensions'. It's essentially like connecting 2 PBXs together. Until...

Set the relevant number in the Outbound Caller ID Number field on the extension.

Looks like another classic case of bad documentation, I got it working. Apparently you need to specify the profile before the username with a slash. freeswitch@pbx.example.com> chat sip|1000@pbx.example.com|internal/1001@pbx.example.com|Hello

If your DNS provider doesn't support it, you can always do what I did and go for individual domains. You'll have to get even more creative for the FreeSWITCH TLS cert though, I don't think it's possible to have more than one: template.conf is the base config for each domains virtual server...

Not Grandstream, but for a while Yealink didn't have the CA of LetsEncrypt pre-installed for a while, so we had to enable insecure TLS. If it's not that (you might be able to tell from a packet capture/log, then it's potentially a problem with the nginx configuration?