Nice! (It would be cool to be able to set the System Identifier instead of the hostname)
Sorting your FreePBX tabs
Sorting your FreePBX tabs
Sorting your FreePBX tabs
Well that ticket is already closed. CC: @kgupta1
What is the GPG issue?
Framework 15.0.16.38 does not correct this issue for me. @miken32’s original changes did (ignoring the 6.5 second vs 3.25 second mystery).
Unless the list of well-known keyservers is changed to the following, GUI reloads still take forever with Framework 15.0.16.38 unless module signature checking is disabled:
// List of well-known keyservers.
private $keyservers = array(
“hkps://keys.openpgp.org”, // Unpoisoned keyserver
“hkps://keyserver.ubuntu.com:443”, // This is in case port 11371 is blocked outbound
“pool.sks-keyservers.net” // Last resort
);
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
Framework 15.0.16.38 does not correct GUI reloads from taking forever for me. @miken32’s original changes did (ignoring the 6.5 second vs 3.25 second mystery).
Unless the list of well-known keyservers is changed to the following, GUI reloads still take forever with Framework 15.0.16.38 unless module signature checking is disabled:
// List of well-known keyservers.
private $keyservers = array(
“hkps://keys.openpgp.org”, // Unpoisoned keyserver
“hkps://keyserver.ubuntu.com:443”, // This is in case port 11371 is blocked outbound
“pool.sks-keyservers.net” // Last resort
);
Sorting your FreePBX tabs
Yeah, I’m saying that the hostname in the browser title is good enough for my needs, but if you want to pursue the System Name idea then reopen the request.
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
Once we’ve finished the other changes we have planned (early next week?), the timeouts should be much less of an issue.
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
Just to be clear…
With the current framework (15.0.16.38), GUI reloads are 3.25 seconds with signature checking disabled. With signature checking enabled, GUI reloads NEVER complete. CLI reloads are 3.25 seconds under all circumstances.
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
Care to elaborate on how to include a key in the module tarball?
CNAM in PAI but not coming across
I’m running inbound calls through a proxy (for call reputation scoring) before it hits FreePBX.
If a call is rated as being bad, it puts “SPAM” in the P-Asserted-Identity field.
I can see this in the FreePBX logs that it’s being received… but it’s not coming across as the callerID name.
I changed my inbound trunk context to be from-trunk-pai, and set trustrpid to yes… but that didn’t seem to do it.
Looks like the wrong part of PAI is being scrapped… not sure.
Any ideas?
Here is a redacted except from my logs:
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [+MYPHONENUM@from-trunk-pai:1] NoOp(“SIP/PROXYIN-000063d9”, “Attempting to extract Caller ID from PAI Header”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [+MYPHONENUM@from-trunk-pai:2] Gosub(“SIP/PROXYIN-000063d9”, “trust-pai-as-cid,s,1”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [s@trust-pai-as-cid:1] Set(“SIP/PROXYIN-000063d9”, “CHANTYPE=SIP”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [s@trust-pai-as-cid:2] GotoIf(“SIP/PROXYIN-000063d9”, “1?chansip,1”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx_builtins.c: Goto (trust-pai-as-cid,chansip,1)
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [chansip@trust-pai-as-cid:1] Set(“SIP/PROXYIN-000063d9”, “PAI=”" sip:CALLERNUM@192.168.x.x") in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [chansip@trust-pai-as-cid:2] Goto(“SIP/PROXYIN-000063d9”, “setcid,1”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx_builtins.c: Goto (trust-pai-as-cid,setcid,1)
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:1] ExecIf(“SIP/PROXYIN-000063d9”, “0?Return()”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:2] Set(“SIP/PROXYIN-000063d9”, “NAME=”") in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:3] Set(“SIP/PROXYIN-000063d9”, “CALLERID(name)=”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:4] NoOp(“SIP/PROXYIN-000063d9”, “”") in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:5] Set(“SIP/PROXYIN-000063d9”, “SIPURI=SPAM>” sip:CALLERNUM@192.168.x.x") in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:6] Set(“SIP/PROXYIN-000063d9”, “TYPE=SPAM>” <sip:CALLERNUM") in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:7] Set(“SIP/PROXYIN-000063d9”, “CALLERID(num)=CALLERNUM”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [setcid@trust-pai-as-cid:8] Return(“SIP/PROXYIN-000063d9”, “”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [+MYPHONENUM@from-trunk-pai:3] Goto(“SIP/PROXYIN-000063d9”, “from-trunk,+MYPHONENUM,1”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx_builtins.c: Goto (from-trunk,+MYPHONENUM,1)
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [+MYPHONENUM@from-trunk:1] Set(“SIP/PROXYIN-000063d9”, “__DIRECTION=INBOUND”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [+MYPHONENUM@from-trunk:2] Gosub(“SIP/PROXYIN-000063d9”, “sub-record-check,s,1(in,+MYPHONENUM,yes)”) in new stack
[2019-12-26 15:50:48] VERBOSE[30290][C-00001e78] pbx.c: Executing [s@sub-record-check:1] GotoIf(“SIP/PROXYIN-000063d9”, “0?initialized”) in new stack
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
You’re experiencing problems with a Debian/Ubuntu system which is not going to be fixed unless a) subkeys are added to the whitelist as in my pull request or b) the subkeys are updated on the keyservers. Those lookups are always going to timeout otherwise, regardless of which servers are configured. This is due to the changed output format of the newer version of gnupg, and the fact that the subkeys aren’t currently listed in the keyservers.
S505/s705: how to turn off the VM ring notification (and are there other similar audio notifications)?
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
Sangoma S505 disconnects while pausing during dialing?
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
Most incoming calls hang up when answered... but not all
Thank you for the feedback. I opened a ticket with our provider as well and they just responded that the call was “failing on an invite response” which jives with your re-invite hunch. They suspect it is the extension CID responding with internal info and not the DID so I’m exploring that now.
I did see that I can post links now. I’ll use the pastebin in the future but the links I provided where wide open with no authentication needed (cause I hate that stuff too!)
As for the pfsense… I’m more than confident that it is configured properly as it is the same setup as most of my other clients have and they have no issues, even with the same provider.
Most incoming calls hang up when answered... but not all
Try with setting the parameter fromuser
EPM with S505 phone no APPS
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Most incoming calls hang up when answered... but not all
Where would I set this? Phone? Extension? Trunk?
Most incoming calls hang up when answered... but not all
Trunk, but the value must be provided by your provider, in case they require it they should be able to tell you how to configure the trunk.
Most incoming calls hang up when answered... but not all
Their documentation didn’t have anything in there about that. I’ve got them setup on several other clients with same config and don’t have this issue.
Also, I’m using PJSIP so not sure where you set the fromuser setting in freepbx (if you even can)
SEC-2019-000 - Ticket #00000 - Framework Vulnerability
It’s not clear to me what changes are being made to GPG.class.php and who’s making them.
Until I can get a working a framework module from Module Admin, I’m patching GPG.class.php to add the following to $fskeys:
‘593E5D6A7107C285E698CB563C355822CCEBF9CB’
‘C5C26167A09555DB29DA4ECF06C57CED5C2FE148’
‘EB312FC936875A7BC236DE6A36992456A6869B39’
and changing $keyservers to just:
“hkps://keys.openpgp.org”
and disabling module signature checking.
That gets a reload that completes in 3.25 seconds whether from the GUI or the CLI.