[Solved] Keep Certain Extensions from Receiving Caller ID Completely?

I have been tasked to remove all Caller ID from our Front Desk phones for inbound calls.

This is for both internal and external incoming calls to these phones.
This will include Direct Calls, Ring Group Calls, Queue Based Calls, IVR transferred calls, etc.

However, other phones in the company should receive caller ID, as normal.

Is this possible?

I figured out how to remove the CID for internal inbound calls, but was not able to do a similar context for external inbound calls.

[from-internal-custom]
exten => 301,1,Set(CALLERID(all)="")
exten => 302,1,Set(CALLERID(all)="")
exten => 303,1,Set(CALLERID(all)="")

We use Yealink phones… so maybe someone knows of a setting on the phone instead of the PBX?

Thank you for any guidance you can provide

UPDATE - 2/1/2019

We implemented the below suggestion and it has been meeting our needs. It was tested in 2 locations for a week and is now being rolled out to more. The topic auto-closed so it did not allow a reply. Thank you to all who helped with this

About the only thing it looks like you could do is in the provisioning for that phone change the value in:
Account / Advanced / Caller ID source until it gets to Anonymous (You may need to experiment which one will present Anonymous) then you can lock that down in provisioning with new template for that user and basefile edit of:
CFG Configuration:
account.X.cid_source
Valid Value:
(0-FROM;1-PAI;2-PAI-FROM;3-PRID-PAI-FROM;4-PAI-RPID-FROM;5-RPID-FROM)
About the best you could do i think …

Hello @jgiebler,

You can write another custom context that would change the caller id to Anonymous for all your phone numbers. For example:

[from-pstn-custom]
exten => _X.,1,Set(CALLERID(all)=Anonymous) 
same => n,LOG(NOTICE, changing the caller id for external number: ${EXTEN})

If you want to change the caller id only for specific phone numbers you will need to remove the “any” pattern to a specific one. For example:

[from-pstn-custom]
exten => 17181234567,1,Set(CALLERID(all)=Anonymous) 
same => n,LOG(NOTICE,changing the caller id for external number: ${EXTEN})

Insert the lines to the extensions_custom.conf file and reload the Asterisk dialplan:
rasterisk -x'dialplan reload'

Thank you,

Daniel Friedman
Trixton LTD.

This is not going to work because the OP wants a certain set of phones (Front Desk) to not have CallerID displayed for any call, internal or external, while all other phones do. So setting the CallerID(all)=Anonymous at the start of the call will block CallerID for phones that should have it.

The question I have is what happens when a call comes into the Front Desk and they transfer the call somewhere else? Or they park the call. How do the other phones/users who are supposed to get CallerID still get it because at this point, once the calls go through the Front Desk you’re stripping the CallerID which can impact the call from that point forward for those who are expecting CallerID.

So what should happen if a call comes in and hits the Front Desk phones? Should they not see CallerID but any destination they send the call to should?! Or once it hits the Front Desk, CallerID is removed and not cared about?

You can easily do this with Yealink phones. You have 2 choices.

The easiest is to set this to null. This affects calls out from the operator also, and may have other side affects.

The other option only affects inbound caller ID, but I have no idea which setting would work (if any).

As I’ve written here before, I strongly recommend against EVER using this context for any purpose ever, for any reason. Every line a user puts in this context supersedes a FreePBX generated line, some of which are critical for security. If you need to pre-process a call from a trunk, you must create your own context that then goes a GoTo to the from-pstn context.

2 Likes

Hi @jgiebler, @sorvani, @BlazeStudios, @lgaetz

I just remembered that the Yealink phones honors the privacy sip header, so all you have to do is to insert the privacy header of id to the inbound and outbound calls of your pbx, and the Yealink phones would show them as Anoymous. The good thing is that it would not affect the CDR of the call (you will still see the original caller id).

I disagree with @lgaetz comment regarding the from-pstn-custom context, but just for a good will here is a working example for outgoing calls (add a privacy header to extensions 301, 302 and 303) and incoming calls (assuming you are using a SIP trunk):

[from-internal-custom]
extension => _X./_30[1-3],1,SipAddHeader(Privacy: id)

;Add this custom context for the incoming calls in your trunk settings:
;(context=from-trunk-masking)
[from-trunk-masking]
exten => _X.,1,SipAddheader(Privacy: id)
same => n,Goto(from-pstn,${EXTEN},1)

or for a PJSIP channel you can check @lgaetz’s answer here: https://community.freepbx.org/t/add-custom-sip-header-to-pjsip-trunk/37010/5

Thank you,

Daniel Friedman
Trixton LTD.

The OP wants to block CallerID TO the phones for those extensions not FROM. That basically says when 301, 302, 303 make a call to add the Privacy header.

Again, only three extensions are not to receive CallerID for any type of call. All other extensions should receive Caller ID as normal. You are now setting Privacy headers on each call that enters the system which could mess with things.

^^^ Those are VITAL questions. Because right now everyone is offering up shotgun, get’em all solutions that aren’t taking things into consideration.

Scenario #1:
Call from PSTN → 301 Answers [ CallerID is now blocked as 301 is not to receive it ] 301 transfers to 202 (who is supposed to get CallerID) but now may not because either CALLERID(all) was set to “Anonymous” or a Privacy header was injected and it blocks the CallerID from being displayed properly. So now an extension that should have CallerID doesn’t. That is now a new issue to solve.

Scenario #2:
Call from PSTN → 202 answers then transfers to 301 who then transfers to 305. CallerID would be present for 202, blocked for 301 and then a possible block to 305.

Those are just a couple scenarios in which a call can be bounced around the system and pass through multiple “call points” where the CallerID is checked and can be manipulated or even trigger certain actions to happen aka Privacy Manager/Screening.

While all the solutions offered up are correct, they will work, they account for a call path of A(start)-Z(end) but what if the call path is A-B-Z-F-E (with Z being 301/302/303). A call that passes through Z and could end up at F who has FollowMe enabled could end up sending a Private CallerID to the PSTN for the FM call instead of the CallerID of the caller.

So the answer is probably a mix of dialplan and configuring those three Yealinks but you have to consider all of the call flow and that those three extensions could not be the final destination of the call and CallerID will need to be restored for the continuation of the call.

How about sticking a bit of masking tape over the phone’s display?

5 Likes

@BlazeStudios,

The privacy header only masks the caller id on the Yealink phones or any other device that would honor the privacy header. The purpose of masking the caller id on the from-internal-custom context, is to avoid passing the called id if the call would be transferred to another application. You should really try this on your pbx.

If you would check the CDR you would notice that the from header is not changing.

As for the incoming calls, he can always change my dialplan to a specific phone number.

So, to conclude, the privacy header does not change the from field of the channel and my dialplan works as it should be.

Thank you,

Daniel Friedman
Trixton LTD.

You’re missing my point about that. Your dialplan will set the Privacy header when those extensions make a call not receive a call from another internal extension. So if 202 calls 301, the CallerID needs to be blocked on 301. Your from-internal-custom does not do that. It will set the Privacy header when 301 calls 202 or makes any outbound call.

Hello @BlazeStudios,

If you want to mask the caller id on the incoming calls as well to these extensions you can change my dialplan a little bit:

[from-internal-custom]
;Mask the caller id of outbound calls from extensions 301-303
extension => _X./_30[1-3],1,SipAddHeader(Privacy: id)

;Mask the caller id of incoming calls (internal or external) to extensions 301-303
extension => _30[1-3],1,SipAddHeader(Privacy: id)

;Add this custom context for the incoming calls in your trunk settings:
;(context=from-trunk-masking)

[from-trunk-masking]
;Mask the caller id on all the phone numbers of the pbx.
;If you want to mask only one phone number for example, you will need to change the first line. i.e.:
;exten => 17181234567,1,SipAddHeader(Privacy: id)

exten => _X.,1,SipAddheader(Privacy: id)
same => n,Goto(from-pstn,${EXTEN},1)

Thank you,

Daniel Friedman
Trixton LTD.

1 Like

I would suggest that instead of trying to set SIPHeaders twice, you call on the setsipheaders GoSub

extension => _30[1-3],1,GoSub(func-set-sipheader,s,1(Privacy,Id))

This way the headers are added regardless of what the SIP channel type is and you don’t have to have two separate methods for each sip driver.

While I suspect this will also attract disagreement, I’m going to recommend against anyone doing dialplan like this as well. The context [from-internal-custom] is fine for adding hard coded extension numbers, but the above pattern match will also supersede FreePBX generated dialplan and its usage will have unintended consequences. The correct way to do this is with dialplan hooks.

I will also note that using the SIPAddHeader application is slowly becoming useless as we move more and more to PJSIP. There are better ways of adding headers that are channel driver agnostic.

2 Likes

Thank you all for so many replies.

I wish I could just use @dicko 's approach of masking tape. However, they use multiple pages on the displays so the simplest solution is out.

We will start testing the option @sorvani suggested of setting the “Call Information Display Method” to “Null”. this seems like a simple way to start.

To answer the question @BlazeStudios also posed:

Honestly I hadn’t thought about AFTER the call leaves the Front Desk. Our leadership that commissioned this change is currently focused on the front desk no longer selectively answering phones. I will give my “best effort” to answer with what I believe may be acceptable.

For any call that leaves the Front Desk, it will have to be OK that these calls have had caller ID removed.

For calls that directly go to other extensions from IVR, Inbound Route, Ring Groups etc they will still get the CID.

One option I can think of would be for any transfer from the front desk to have the Caller ID Info updated to at least say “Front Desk Transfer” instead of showing as anonymous on the receiving end.

I’m not sure exactly how to do this, but I assume It can be done via a custom context that would check if the Caller ID Name is blank (from front desk phones) and then update to “Front Desk Transfer”. Anybody have experience with such a context?

@lgaetz do you have a good reference I could use to learn more about implementing dialplan hooks? We use the [from-internal-custom] for other things as well. If the better method is dialplan hooks, I would like to start pursuing that. We can then work to convert our custom things to hooks.

[reference is here - mod]

@jgiebler a technical solution to a managerial problem always causes more work than a simple enforcement of the rules in the first place.

4 Likes

Seriously @sorvani has the right concept, if you have a lazy/incompetent receptionist, have you management correct or fire her.

3 Likes

No. It’s not. It’s deprecated. If there are security issues no one will fix them. If there are performance problems no one will fix them. It’s open source so sure it will stay around for many years just like any ancient source code has. Probably for eternity. Does that mean you should use it. No. And notice that Lorne said “agnostic” that didn’t imply pjsip at all.

2 Likes

Also, this might escalate. Calls to or from the disliked people might be ‘accidentally’ disconnected, left on hold for long periods or otherwise mishandled.

OTOH, if she’s banging the boss, it could be a tough decision :slight_smile:

4 Likes