This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
↧
CDR's not working after Timezone change
↧
IVR Breakout in Queue Causes Newer Calls to Be Connected First
Thanks @PitzKey. Autofill is disabled. Did you ever find out what file that was? I grepped for it in /etc/asterisk and got nothing.
↧
↧
Grandstream GXP2170 *80 paging only rings
If anyone else stumbles acrossed this down the road…
It’s working now. I don’t know what changes I did since the post. I could have sworn all I have done is research since the post was made, and compare settings.
Though… When I found out the buttons work for the client, I went on site, and tested myself. That was the first time they buttons works. I don’t know if the user was misdialing, as in using # instead of *, as the single press of # is Redial.
↧
Siren 7 codec settings
I have just enabled SIP URI dialing on my FreePBX box, and trying to dial into a Cisco WebEx meeting via URI. All is working fine, other than the codec. I’m getting the following errors when trying to place that SIP URI call:
[2019-10-04 16:44:05] WARNING[12434]: res_format_attr_siren7.c:52 siren7_parse_sdp_fmtp: Got Siren7 offer at 24000 bps, but only 32000 bps supported; ignoring.
This is the error message whenever I try to SIP URI dial into my WebEx bridge. Any ideas on how to configure the Siren 7 codec to work with 24000 bps?
↧
IVR Breakout in Queue Causes Newer Calls to Be Connected First
I think this is mainly just how it works. In Asterisk Queues, the calls pick agents, rather than the agents picking calls. There is a little bit of logic to stop low priority queues overriding high priority ones, but, as many calls as there are free agents will be competing for the available agents, and if one is playing comfort messages, it will not be actively looking for an agent.
If by IVR, you really mean just playing “your call is important to us, please wait”, you can record a special musiconhold track that embeds those messages.
(I can’t remember what it does with two equal priority queues that share the same agents, but I suspect that it may not reduce the number of calls from the top of the queues that are actually looking for agents, so calls further down the queue may end up getting an agent. Normally this isn’t too much of an issue, unless multiple agents come free in the same second, as there will rarely be more than one agent free when queues are heavily loaded.)
↧
↧
‘all circuits are busy…’ On External Calls Using Google Voice Via OBiHAI200
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
↧
IVR Breakout in Queue Causes Newer Calls to Be Connected First
There needs to be more to the debug then a half dozen lines. We need to see the call that is in the queue and then the breakout IVR selection/options and the call behind this call. If the playback is causing the next caller to be sent to the agent there might be a problem.
↧
Failed To Send Security Notification Email
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
↧
IVR Breakout in Queue Causes Newer Calls to Be Connected First
No there doesn’t. This is simple enough for anyone to replicate/verify. Posting here is not posting a bug report.
The lines he posted shows it pulled call 398 out of the queue to play the periodic message and while 398 was still out, it sent call 399 to an agent.
But if a full debug is required, the app_queues.c has lots of debug to prove this is a bug.
core set debug 4 is enough verbosity to see all of the app_queue debug messages. FreePBX logs debug to full by default.
app_queues.c has two main loops. one for the “head caller” and one for callers 2+. Both loops call say_periodic_announcement. So with debug on, it should be simple to have the OP post something that will prove where the callers were.
↧
↧
Freepbx 13 upgrade to 15
Hi ,
I’m trying to upgrade my Fbpx 13 to 15.
when running the Restore using the backup restore and choose restore legacy CDR I get the following error :
In Process.php line 1335:
The process “zcat /tmp/backup/b3355818-6911-44d9-a57f-a7a4a22a0ee8/mysql-4.
sql.gz | mysql -u freepbxuser -pPassword asteriskcdrdb” exceeded the ti
meout of 300 seconds.
is this an issue of a CDR db being too big ?
can I adjust the timeout ?
Thank you .
↧
Siren 7 codec settings
have you tried any of this, although i don’t see the siren codecs in the examples
this guy had quite a bit of trouble, looks like it was unresolved. maybe it works now in 2019-2020
↧
Asterisk 16.5.0 + PHP7.1.32 + FreePBX 15.0.16
this mean Freepbx is still not working under PHP7 ?
↧
Fail to connect X-lite extension
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
↧
↧
Voicemail login incorrect
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
↧
GUI stops responding if left on dashboard - any browser
Current PBX Version:14.0.13.4
Current System Version:12.7.6-1904-1.sng7
If I leave the browser, Chrome, Firefox or Edge on the FreePBX dashboard for more than a few hours the Network widget quits updating. Then awhile later I cannot navigate to any tabs. I cannot refresh the browser.
Closing and reopening sometimes works but usually not. Can’t find webpage. If I change browsers it will work for awhile again. If I use the IP address instead of FQDN it will work until it times out again.
↧
Asterisk: a targeted VOIPspionage campaign
FYI, I would like to share these two articles hoping to encourage the community in keeping their system up to date.
In summary, attackers could use a vulnerability to access the FreePBX, steal data and install crypto mining scripts. It seems that the security hole has been patched, so it is recommended not to put off updates for long.
Source: https://www.virusbulletin.com/conference/vb2019/abstracts/asterisk-targeted-voipspionage-campaign/
↧
Dial Pattern Problems
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
↧
↧
Asterisk: a targeted VOIPspionage campaign - update PBX to patch the vulnerability
I love articles like these. The ones where they tell you have a huge vulnerability but then they don’t tell you what that vulnerability is, what version of Asterisk/FreePBX this impacts and what version has the patch to fix it.
Despite both articles coming from the same source, one claims Asterisk/FreePBX and the other just claims Asterisk. One claims there was a patch released for this vulnerability but the other has no mention of the patch.
Articles like these are click bait as far as I’m concerned because they do nothing but tell you that you could be exposed to being compromised but give you no actionable information on how to resolve or mitigate the issue. Very helpful.
↧
Asterisk: a targeted VOIPspionage campaign - update PBX to patch the vulnerability
The point is to encourage people to keep their systems up to date. When vulnerabilities are discovered the responsible parties are first to be informed before it is made public and they issue patches. So regardless of the affected Asterisk version, updating the software is important to mitigate any known or (publicly) unknown security risks.
↧
Asterisk: a targeted VOIPspionage campaign - update PBX to patch the vulnerability
Here is the thing about these articles. Asterisk, itself, doesn’t have a GUI. That means it doesn’t require or need Apache (or any web server) or PHP. So that would mean there are numerous Asterisk installs out in the world that would never be impacted by this, at all.
Conversely, FreePBX (which uses Asterisk) is GUI based and therefore uses Apache and PHP which would mean 100% of FreePBX boxes could be impacted by this. These articles fail to relate how this is being done. What attack vectors are being used? Is it a buffer overflow? Is it a SQL injection? What?!
Again, ZERO information provided. Right now FreePBX v13 and v14 are the “current” releases for FreePBX. The former uses PHP 5.3 while the latter uses PHP 5.6. What versions of FreePBX where these monitored systems running? Were they current boxes? Were they v13 or v14?
I mean come on, look at the first article. The report is based off of reporting from Feb - July of 2018! Over a year and a half ago. It even says a patch was released (but doesn’t tell you what update has the patch or what versions should be patched). So honestly, if you are a year and a half behind on your updates, you deserve a quick kick in the gonads to wake you up.
Articles like this are reckless because they promote a panic with no resolution.
↧