Search results

No idea on your infrastucture but doing it over a vpn, I'd use wireguard if possible, will get rid of that problem.

Interesting, I have never considered this. I'm not fully awake yet but I would probably go into the external sip profile and disable the "auth-calls" true requirement. Then, instead, to protect your external profile modify your iptables rules to only allow your carrier and your ip to port 5080

In the extensions advanced settings for the expire to 120 secs then unregister and reregister

You should not have added that acl, just delete it and add the cidrs for the caiier to the domains acl

With regards to the ports, what ports are showing in the registrations in fusionpbx? In general, they should not be the same as the ports on the phones as most routers will be doing PAT (Port Address Translation) The ones that don't usually work in a mode I have seen described as overload, ie...

I agree with Adrian about TCP masking underlying network problem but I've personally been moving away from UDP now for years. We should all really be using TLS in 2022 for voip and that needs TCP. TCP will usually also stop any ghost calls in their tracks as the source port is now a random high...

Yes, TCP is much better for NAT. You absolutely should NOT be using port 5080 for extensions, that is for the external profile only, ie carriers. You should never have to assign static ports to phones. The only time that ever seems to cause problems is when a SIP ALG is in play and that is the...

No, they are the RTP phones that the phones will use at their end, they can be anything.

Well, I can immediately see the dialplan looking in the public context, this usually means people have added things to the access control list that they shouldn't have. The only thing that should be added there are carrier IPs.

No, wildcards work fine What happens if you try curling https://valid-isrgrootx1.letsencrypt.org/ from the server, do you get any error?

Please do not reopen threads from years ago, open your own thread.

What OS? Are your permissions OK on the recording directory?

You should definitely not be using 4.4.3. It has security flaws. I would just rebuild the box using latest master, particularly if it is only a single domain.

Go into the destination and resave it, make sure the domain is set to the fqdn. Also, flush your cache rm /var/cache/fusionpbx/*

You have renamed it, now you have to change the phones etc to register to the fqdn

You didn't need to create a new one you just needed to change the existing one. When did you install this, this was fixed already?

I just prefer not to rename, I'd rather leave the IP domain there, a rename should work too though.

Just add a new domain with fqdn

No, I do not use the backup scripts, there is definitely no need to back this db up Also, do you have it running in tmpfs? That should make life easier.

If you are using sqlite for this db which most of us are you can just delete it and restart freeswitch. Many of us run with this in tmpfs eg: in /etc/fstab: tmpfs /var/lib/freeswitch/db tmpfs defaults 0 0 So: service freeswitch stop rm /var/lib/freeswitch/db/* service freeswitch start...