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

[danielf]

Hello @tm1000,

@tm1000

And notice that Lorne said “agnostic” that didn’t imply pjsip at all.

I will take your words to a feature request of adding a privacy header to an extension or an inbound/outbound route: https://issues.freepbx.org/browse/FREEPBX-19004.

Thank you,

Daniel Friedman
Trixton LTD.

[BlazeStudios (Tom Ray)]

@danielf

@BlazeStudios,

Why should I use a macro that adds another 100 lines of code, instead adding only two lines to a simple and faster solution???

You shouldn’t. That is why I didn’t recommend a Macro(), I recommended a GoSub. The func-set-sipheader() GoSub to be more exact. How that is 100 lines? I’m not sure because it’s like three.

[func-set-sipheader]
include => func-set-sipheader-custom
exten => s,1,Noop(Sip Add Header function called. Adding ${ARG1} = ${ARG2})
exten => s,n,Set(HASH(_SIPHEADERS,${ARG1})=${ARG2})
exten => s,n,Return()

And then when calls are made and the pre-dial option of b(func-apply-sipheaders^s^1) will then take those headers in the hash and apply them.

[func-apply-sipheaders]
include => func-apply-sipheaders-custom
exten => s,1,Noop(Applying SIP Headers to channel)
exten => s,n,Set(SIPHEADERKEYS=${HASHKEYS(SIPHEADERS)})
exten => s,n,ExecIf($[“${HASH(SIPHEADERS,Alert-Info)}” = “unset”]?Set(Rheader=1))
exten => s,n,While($[“${SET(sipkey=${SHIFT(SIPHEADERKEYS)})}” != “”])
exten => s,n,Set(sipheader=${HASH(SIPHEADERS,${sipkey})})
exten => s,n,SIPAddHeader(${sipkey}: ${sipheader})
exten => s,n,Set(PJSIP_HEADER(add,${sipkey})=${sipheader})
exten => s,n,EndWhile
exten => s,n,ExecIf($[“${Rheader}” = “1”]?SIPRemoveHeader(Alert-Info:))
exten => s,n,ExecIf($[“${Rheader}” = “1”]?Set(PJSIP_HEADER(remove,Alert-Info)=))
exten => s,n,Return()

So yeah, not a Macro. Not 100 lines of code. It’s EXISTING code that comes with FreePBX that doesn’t require you to do individual “SIPAddHeader” commands followed with the advice of “To do PJSIP follow this separate method” since it handles both and it widely used through out the system already.

Just another little FYI, much like Chan_SIP the Macro() app is also deprecated and will be removed in future versions. GoSub replaced it years ago.

[BlazeStudios (Tom Ray)]

@danielf

You really think that I do not know how to read the Freepbx dialplan? I know it by heart.

I never said you didn’t know it. Look, this is simple I wasn’t really talking to you directly but in general on the topic at hand. I just quoted what you had posted for reference. You came back and asked why you should use a Macro that has 100’s lines of code when your version is simple and faster. Except, I never said that. I never suggested adding 100’s lines of code or even using a Macro. I suggested using a pre-existing GoSub that is already written and used in the system. How much more simple and faster can that get?

[jgiebler (Jameson G)]

@sorvani

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

@dicko

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

@Stewart1

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

Thank you for these responses. Unfortunately this is a multi-office, multi-staff issue. Our management team has committed to manage down on the challenge, however in the interim I have been commissioned to come up with the previously discussed option.

Following up on this question, does anyone have any custom context suggestions? Would the below option do it?

@jgiebler

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?

[from-internal-custom]
;Update Caller ID name for "Blank" Transfers from front Desk
exten => _X./_30[1-3],1,,GotoIf($[${LEN(${CALLERID(name)})} = 0]?setcid:end)
exten => _X./_30[1-3],n(setcid),NoOp(CUSTOM: from-internal-custom in /etc/asterisk/extension_custom.conf)
exten => _X./_30[1-3],n,NoOp(CUSTOM: Blank Front Desk Transfer: Updating Caller ID from ${CALLERID(all)})
exten => _X./_30[1-3],n,Set(CALLERID(name)="Front Desk Transfer")
exten => _X./_30[1-3],n,NoOp(CUSTOM: Caller ID changed to ${CALLERID(all)})
exten => _X./_30[1-3],n(end),NoOp()

[Stewart1 (Stewart)]

My ancient Yealink T26P sets have a per-account ‘Caller ID Source’ option of PAI. With no changes to any contexts or dialplan code, selecting this option and having sendrpid for the extension set to No, the phone displays Anonymous for both internal and external calls. Outbound caller ID, transferred calls, etc. are unaffected.

Try this and report results – if something leaks through, there may be an easy fix.

[sorvani (Jared Busch)]

@Stewart1

My ancient Yealink T26P sets have a per-account ‘Caller ID Source’ option of PAI. With no changes to any contexts or dialplan code, selecting this option and having sendrpid for the extension set to No, the phone displays Anonymous for both internal and external calls. Outbound caller ID, transferred calls, etc. are unaffected.

Try this and report results – if something leaks through, there may be an easy fix.

This is the solution in the second screenshot I posted above. Sounds like the perfect solution for @jgiebler

[sorvani (Jared Busch)]

If you use EPM to manage your Yealink phones, this setting is set to 4. And Send PID is already No.

You need to go into the basefile and change it.
You will want to duplicate you current template since you do not want to affect all extensions. Then change this to 1 and apply the template to your receptionist phone.