Search results

*75 = Ring Group Forward. Modify the dialplan entry in the Dialplan Manager to remove/alter the PIN number and set the ring group and destination, or let it prompt for it. *72, *73, and *74 are enable, disable and toggle call forwarding. You can also modify the dialplan entry in the Dialplan...

That's not wrong, SIP clients can use any ports they wish using rport. Otherwise you would only be allowed to use one SIP client per IP address. Does that network have some sort of SIP ALG enabled? If so disable it. Also arbitrary port blocking rules for UDP? If so, whitelist the PBX address.

Had a look myself at the member documentation, doesn't seem to state which level. Probably best giving them a call: https://www.fusionpbx.com/support

This should do it, this is in Dialplan Manager -> user_record, right at the bottom.

It's either going to be FreeSwitch itself, mod_sofia or the openssl libraries those two are built against. As FreeSwitch isn't really a 'Debian' piece of software, it could just be breaking ABI changes or something. Found this, with no answer...: Anything in the journal or freeswitch logs?

I should add, the new 'Event Guard' that is in the latest release of FusionPBX doesn't need this. As soon as a valid registration is seen, it's 'whitelisted' for future violations of SIP auth failures. This is a useful script for those still using Fail2Ban for things like nginx auth problems. :)...

If Azure is like AWS, you'll need to put your external IP address in the variables external_sip_ip and external_rtp_ip, otherwise your contact header will have the local address of the VM on:

Does the database show the correct paths for the relevant UUID of a record? root@pbx:~# su postgres postgres@pbx:/root$ psql postgres=# \c fusionpbx fusionpbx=# select xml_cdr_uuid,record_path from v_xml_cdr;

# fs_cli -x 'show registrations'

https://docs.fusionpbx.com/en/latest/applications/call_center.html

Don't know if it's the exact same issue, but I had a cascading registration failure using the SQLite coredb. So many simultaneous registrations just caused it to lock up. Switched to postgresql core which handles locks and caching a bit better and the problem disappeared. There's a script...

If you have remote phonebooks set up, it's the setting below. In the templates it's: features.remote_phonebook.enable = {$yealink_remote_phonebook_enable}

SIP Trunk providers should normally give it to you.

Well, the initial_callee_id_name wasn't set in local_extension, despite being in the template XML files. Not sure what happened there. I just stuck it in at 36: initial_callee_id_name=${user_data(${dialed_extension}@${domain_name} var effective_caller_id_name)} Anyway, tried it out and it...

Oh right, the callee name. This should already be set in local_extension under initial_callee_id_name. I'll see if it shows up. Might try changing it to origination instead.

Yes, I think this is one thing that doesn't get cached as an XML file, mainly as it's only read at launch usually. fusionpbx=# select * from v_sip_profile_settings; You should be able to export this specific table using pgdump or COPY commands to a CSV import. Something like: pg_dump...

Probably better setting that in the call-forward-all/busy etc dialplan entry. I reckon that would work without wrecking your outbound routes.

Smells like SIP ALG to me. Disable it if it is enabled. Router manufacturers haven't quite figured out rport now exists.

Here you go, we hide the Outbound Name and Emergency, as they get clipped by the SIP trunk anyway so it's pointless setting them. The only thing I can possibly think of is that your phones are in the public context by mistake? I've seen this when the providers/domains ACL is set to the network...

Which ultimately pulls from switch.conf.xml: <param name="mailer-app" value="/usr/bin/php /var/www/fusionpbx/secure/v_mailto.php"/> https://github.com/fusionpbx/fusionpbx/blob/4.4/secure/v_mailto.php At line 335 is the mailer error, which could be 'error_log' for debugging I suppose.