Search results

Make sure you set the ring group strategy to, "Enterprise", otherwise it will not execute the call forwarding or Follow-Me routes.

Set the variable sip_h_X-My-Header, where X-My-Header is your variable, before the bridge or do the transfer. Do not exclude the X- prefix for your header name. On the client app, you'll need to parse the X-My-Header from the INVITE request.

The easiest method would be to add a new extension, click on "Call Routing" from the extension form, enable "Call Forward", and enter the destination number in the appropriate field. Then add this extension number to your IVR.

We tried that, but his provider did some weird authentication against the "from" header that caused the invite to be rejected. Having his provider look at the rpid was the answer in this case.

In the outbound route, it should create a condition based on the destination_number. Add another condition that matches the variable ${sip_from_user} to the extension number and ensure its order is lower than any other outbound route with the same destination_number condition.

There isn't enough information there to help you, and what you did provide indicates that you want to register the Grandstream FXO device. If that's the case, and assuming you've installed FusionPBX correctly, do the following: Create an extension. After saving it, write down the extension...

This looks like a FreePBX/Asterisk screen. I think you might need to find a more appropriate forum or reach out to FreePBX for support.

You're welcome. The reason I prefer updating the variables list is that the sofia profiles are saved to the database. I believe the variables list is saved to a file. As such, the variables can be different per server. If you are sharing a database or using database replication, you'd be...

Based on your call detail record, it looks like you might need to set your variables as such. set effective_caller_id_name=${caller_id_name} set effective_caller_id_number=${caller_id_number}

Try hardcoding the effective_caller_id_name and effective_caller_id_number again but make sure you enable inline to the dialplan line.

The dialplan is currently doing a set for the caller id information. See below. Dialplan: sofia/internal/15051001000@FreeSWITCHPBXIP:5060 Action set(effective_caller_id_name=${outbound_caller_id_name}) Dialplan: sofia/internal/15051001000@FreeSWITCHPBXIP:5060 Action...

The following UUIDs refer to your gateways. 2022-12-07 07:43:21.274790 94.30% [NOTICE] sofia_reg.c:463 Registering 1717c8a4-aee1-4316-bc3b-5e53c800efc0 2022-12-07 07:43:31.314794 94.70% [NOTICE] sofia_reg.c:463 Registering 1532a4b6-abba-44d2-8551-a21e218835fc 2022-12-07 07:43:33.314783 94.73%...

The ACLs will come into play with the requests coming to your server. In this case, it looks like you cannot reach the gateways. Is it possible that you are triggering an IPTABLES rule via fail2ban? Maybe you can flush your iptables rules, stop fail2ban, and see if the issue persists.

Disable registration for Telnyx. Telnyx does not require registration. I believe you have to whitelist your IP address on their portal.

Hi, your logs are showing TESTDID as also being evaluated. I'm afraid it's tough to figure out what's going on because the log has been redacted, but I'm not confident that the log is still an accurate representation of what happened. Additionally, can you send a screen shoot of the...

On each server, go to Advanced/variables Add/Update the variables external_sip_ip and external_rtp_ip to the appropriate external IP address for each server. On any server, go to your Sofia sip profile and add/update the variables as such: ext-sip-ip=$${external_sip_ip}...

In an effort to save you tons of time, here is what I have found. Live call recovery/failover only works with UDP. As soon as the TCP/TLS connection is lost, the call is terminated, leaving nothing to recover but a cold and lonely CDR. Live call recovery usually takes several seconds...

To my knowledge, that is not natively built into FusionpBX. The most efficient way to create such a thing would be to set a variable in the variables dial plan such as, "set monthlyquota=2000" and then call a Lua script in a later dial plan that checks the v_xml_cdr table to total the minutes...

Try this. # fs_cli -x 'fsctl shutdown now' # reboot If it reboots quickly, you'll know that the shutdown routine is what is taking a long time when you try to do a normal reboot. FreeSWITCH tries to gracefully shut itself down without the 'shutdown now' command. The graceful shutdown can...

@scg_chris Implementing STIR/SHAKEN might not be necessary for your use case if you can convince the call centers where you are terminating your calls to take your calls via SIP. If you transfer the calls via SIP, i.e...