[Bug?] SIPheader WARS: P-Asserted-ID 'kills' Privacy:id ?!?!?!

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:

  1. Puts ‘anonymous’ in the From header user field (you could override this if your provider requires an account number, etc. there).
  2. Adds a Privacy: id header
  3. Sends PAI with the display name “hidden” but the number sent normally.

Isn’t this what you want (or at least acceptable)?

1 Like

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.

1 Like

@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?

Sorry, to be more specific, the fail which I got was a “503, Service Unavailable” err from my provider.

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.

Does voip.ms have any documentation explaining their requirements?

Attached pic, a capture of my packet which triggered the 503.

Of note/interest @Stewart, this is is that same INVITE, marked up with feedback from VoIP.ms tech support (feedback made indirecty).

They provided no opinion on what PAI ought contain (but I think that its uninformative contents are what caused the 503… not the From header).

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:[email protected]>

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.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.