Modifying CALLERPRES Arbitrarily

Tags: #<Tag:0x00007f70241338c8>

(Australia) #1

Preface: This may be a fringe case.

When receiving an incoming call with full ‘Remote-Party-ID’ headers from a carrier trunk, the ‘privacy=full’ component is not observed and the Caller-ID is displayed.

I have traced this back to the presence of the following item which is added/generated into the dialplan as a part of, where inbound routes are created and privacy manager is not used.

exten => (exten),(priority),Set(CALLERPRES()=allowed_not_screened).

From what i can tell, FreePBX seems to be setting this option arbitrarily and it doesn’t appear to be unset further down in the dialplan (by a macro or another function).

The presence of Set(CALLERPRES()=allowed_not_screened) doesn’t have any effect on the Remote-Party-ID header.

I have not observed any adverse effects as a result of this change.


  1. Is the Set(CALLERPRES()=allowed_not_screened statement a necessity?
  2. What (if anything) will removing it break?


Interesting question, because most members of this forum want to do the opposite, e.g. match a blocked caller ID to a CRM record, or use a blocked caller ID as input to a spam filter, VIP priority, etc.

Assuming that your carrier normally provides the calling number in the From header, but anonymous calls have it only in RPID, I would guess that turning off Trust RPID for the trunk and/or Send RPID for the extension might do what you want.

If not, there are some subtle issues that might determine how you would fix it. For example, should private numbers appear in CDR records, Asterisk logs, call recording metadata, etc?

(Australia) #3

Hi Stewart1, thanks for your response.

To add more ‘fringeness’, we are the direct carrier in this scenario. We have a call termination service further upstream to which we are passed all relevant headers (Remote-Party-ID) from a tier 1 carrier.

I (selectively) forward the Remote-Party-ID headers from our trunking system to ‘some’ of our FreePBX instances. Some being the systems managed by us/me.

Strictly speaking, the call detail records are logged on the trunking system and in so far as the PBX’s are concerned, they don’t require this level of detail.

The main reasons for passing the RPID header inbound is mainly due to CID pattern matching (e.g. matching on international sources) and call diversion from anonymous sources tends to completely fail without it (e.g. when an anonymous source initiates a call to our numbers and a diversion were to take place [be it a ring group or sip 301-302] the CID of anonymous is preserved but the call fails because of an absence of RPID).

Of course, with the RPID present, the call succeeds as i am forwarding it (with headers) back out via the trunk and then to the tier 1 carrier.

As for adding the blocked caller ID to a CRM record, or feed a blocked caller ID through a filter, i could achieve this with the presence of the privacy flag (or through the original CALLERPRES variable which shows as ‘prohib_not_screened’).

I have ‘fixed’ the issue in my own case by editing the file under the core module and commenting out the code responsible for re-setting the CALLERPRES variable (danger notwithstanding).

I haven’t observed any adverse effects after the change.

This is now well documented internally (my systems), keeping in mind that upgrades / updates to the core module will break this, however having an option to selectively disable/enable this option in Advanced Settings would be fantastic.

I both welcome and appreciate any feedback.