Search results

So create two routes for the same dialplan with different gateways. Then for each of those routes, add a condition at the beginning that matches the extensions you want. The first condition will be something along the lines of sip_from_user ^200$ || ^201$

You do not appear to have outbound routes.

Well, immediately I see some of the filters are not enabled: [sip-auth-challenge] enabled = false <-------------------------------- port = 5060:5091 protocol = all filter = sip-auth-challenge logpath = /var/log/freeswitch/freeswitch.log #logpath = /usr/local/freeswitch/log/freeswitch.log...

CAn you provide a siptrace of an outbound INVITE from sngrep

Well to be blunt then what is ANI? Where is this set? According to the SIP specs, caller id is either set in in the FROM header or it is set in RPID, p-asserted-id etc. Some proveiders will use the from, some rpid, some pid (p-asserted-id) I know of no field in SIP for ANI, please enlighten me.

Its basically just experience. If you read through it, what you can actually see is that it is going through the dialplan as defined in the dialplan manager.

No, your outbound routes are likely to break everything, you are saying send anything over three digits, that will likely include ring groups, extensions, etc,etc, etc, Create separate outbound routes to match your emergency numbers etc.

I believe you problem is here: bridge(sofia/gateway/5719458e-8222-4631-b62e-d7c64d5fef69/7000 Why is it trying to use a gateway to send that call? I would guess that you have an outbound route that is catching that.

Paste a freeswitch log of one of these calls

In the advanced gateway settings try setting callerid type to pid, again, after the change, stop and restart the gateway. Also, can the provider not help you out with this? They should be able to tell you what the invite should looks like.

In your gateways advanced settings, do you have "Caller ID In From" set to true. If not can you set that then stop and restart the gateway.

Hi, I see the problem immediately: 2024-09-29 23:20:59.357307 98.63% [DEBUG] sofia.c:10582 IP 108.60.224.235 Approved by acl "providers[]". Access Granted. You have modified the ACL that should not have been done, the PBX is now treating you as a provider and it is using the public dialplan...

Hi Juca, at a guess, even without taken a look at the code, you need to flush the cache. This is what would be happening if you edit an extension in the gui. rm /var/cache/fusionpbx/*

No of what you have described above would have anything at all to do with sqlite. What you are descibing is more like your IP got blacklisted somehow. The lines showing sqlite busy are perfectly normal. 100% this has nothing to do with sqlite.

Nick, I have done this many times in the past but its so long ago that I can't remember. Why are you trying to do this? Just get sqlite into RAM and everything will be fine.

We do not normally replicate the freeswitch database, just leave it running in RAM using sqlite.

Also, if you do not get the required info in the log, in fs_cli do: sofia loglevel all 9 You should see the problem in there though it is very verbose.

What do you see in the logs when you try and restart the tls profile?

I did take a look at this. It is very pretty. If the intention is purely to make fusionpbx better then why not just work with Mark to actually integrate it within the project itself?

I could probably get a thousand concurrent calls on a raspberry pi 5 :)