So I’m mucking with activating CIDblocking again, in a PJsip world.
Using ‘func-set-sipheader,s,1(key,value)’ I can set SIP header values, like:
Privacy: id
This works - I can see it happening via wireshark.
However if I also, in the FreePBX GUI, configure the trunk to send the ‘P-Asserted-ID’ header (i.e. via Trunks/PJsipSettings/Advanced I set field ‘Send RPID/PAI’ to be ‘Send PAI header’)… then my separate “Privacy:id” header is then no longer sent - it just get swallowed somwewhere…
(If I name the key as ‘Privacyy’, or ‘Privacie’, then activating PAI has no effect [and the misspelled key+value appear as a header as expected] - the problem is specific to using the header named “Privacy”.)
Anyone have an idea about what in tarnation is happening… or a sol’n or workaround for me to be able to send both PAI and ‘Privacy:id’ (which FWICT is what’s needed to properly mimic *67 when outdialing via SIP)?
Of interest, I tried toggling the neighbouring setting ‘SendPrivateCallerIDinformation’ to be yes but that assisted none.
Without any custom dialplan, if I set both ‘Send RPID/PAI’ to be ‘Send PAI header’ and turn on ‘SendPrivateCallerIDinformation’, then when I set the display name for the Outbound CID for my extension to “hidden”, then FreePBX:
Puts ‘anonymous’ in the From header user field (you could override this if your provider requires an account number, etc. there).
Adds a Privacy: id header
Sends PAI with the display name “hidden” but the number sent normally.
Isn’t this what you want (or at least acceptable)?
Privacy is a header which Asterisk controls. Like PAI it isn’t something that you should explicitly add. I wouldn’t consider it a bug for trying to explicitly add a header to interact badly with one that is managed by Asterisk itself.
Unfortunately, like a lot of the auto generated pages, the wiki page for the CALLERID function in Asterisk is woefully lacking in real detail, but that is where I’d expect you to control the Privacy header, within any limits that Asterisk might impose.
@Stewart1, I adjusted my setup to match the 3 things you set… and got fail.
(Had it worked it would have been sufficient, yes.)
The issue which arises is that the upstream provider, VoIP.ms, has recently enacted restrictions requiring that some sort of CID-esque things be correctly set (as a phonespam/fakeCID mitigation measure), so activating the fPBX setting “HideCallerID” breaks this.
It seems to me that fPBX is handling the mimicing of *67 in an outdated way?
Please post the outgoing INVITE that got the 503 reply. Redact as desired, but don’t destroy any formatting information. For example, replace the last 7 digits of calling and called numbers with xxxxxxx.
I’m not a VoIP.ms customer, but most providers will reject a call that doesn’t contain a valid (though marked as private) caller ID.
On my system, ‘hidden’ calls have normal PAI with e.g. Privacy: id P-Asserted-Identity: "hidden" <sip:[email protected]>
I don’t know why the calling number doesn’t appear in your case.
Regarding the format discrepancy, configure the trunk with: From User: (your sub account username)
I believe that this is required whether the call is hidden or not.
In my case, where I’m generating my PAI manually, my CIDnum is visible to upstream carriers (and the end subscriber, if appropriate) by way of the PAI:
VOIP.MS_SUBACCT <sip:myphnum@myipaddy>
Though I agree, all this use of my VoIP.MS_SubAcct stuff, in place of normally human-readable identifying info, is oddish. However it’s what I have from VoIP themselves, and I can make things work using it (no 503’s, etc)… Now I just need to get near an ole wireline to do a test to see if I’m properly blocking.
