Dialplan not detecting "Privacy" header in INVITE

Asterisk Asterisk Dialplan
#1

I am attempting to format a dialplan to detect if the privacy bit is set on inbound calls from one of our carriers, so we can adjust the CLI’s for the purposes of withholding the callers number.

I have tried a variety of things, but PJSIP just seems to be unable to read the privacy field within the header. Is this the case?

${EXISTS(${PJSIP_HEADER(read,Privacy)})} returns 0 and I also tried setting a variable to the result of ${PJSIP_HEADER(read,Privacy)}, hoping to get “id” but this also doesn’t return any values.

I have also tried a combination of the above 2 (stolen from another user on here - sorry!)

ExecIf($[${EXISTS(${PJSIP_HEADER(read,Privacy)})} & “${PJSIP_HEADER(read,Privacy)}” != “none”]?Goto(anon))

This also returns 0.

In my test, the privacy bit is always being set to ID, so I am unsure why the above is happening.

I am using Asterisk 16.22.0

Can anyone please advise?

#2

What is the actual SIP trace? Does the output show if you use NoOp to print the value? And is there a reason the native support for such things is not sufficient?

#3

Privacy is a header that is handled by Asterisk itself. You should be looking at ${CALLERID(priv*)}.

#4

Thanks for getting back to me.

I think I have figured out why the ${PJSIP_HEADER(read,Privacy)} wasn’t working. Our dial plans are a little convoluted, but we pass the calls through a macro, which invokes the Dial function. In parallel to this, we pass the call through a secondary dial plan to set outbound variables, using variables gathered from the initial stages of the call process, such as the PAI etc. The syntax of which is…

exten => s,n,Dial(${DIAL_STRING},,ob(si-test^addheader^1(${CALLERID(number)}^${CALLERID(number)}^${CALLERID(name)})))

It was within this secondary, “si-test” dial plan I was attempting to analyze the Privacy header + then do the adjustments, as historically that is where we have done it.

When I set the argument ${PJSIP_HEADER(read,Privacy)} as a NoOp when the call is first received, the “id” header is picked up fine, so I guess the issue is being caused because of the way we are handling the call as outlined above.

Incidentally, you mention the “native” support for this? Can you please advise on what this is?

#5

I believe he was referring to the CALLERID function that I mentioned.

#6

Indeed I was.

#7

hmm that has never worked for me on incoming calls I always get “allowed_not_screened”

same => n,NoOp(CALLERID(priv-num-pres)=${CALLERID(priv-num-pres)})
same => n,NoOp(CALLERID(priv-name-pres)=${CALLERID(priv-name-pres)})
same => n,NoOp(CALLERID(priv-tag)=${CALLERID(priv-tag)})
same => n,NoOp(CALLERID(priv-num-pres)=${CALLERID(priv-num-pres)})
same => n,NoOp(CALLERID(priv-all)=${CALLERID(priv-all)})
same => n,NoOp(SIP_HEADER(Privacy)=${SIP_HEADER(Privacy)})
same => n,NoOp(PJSIP_HEADER(read,Privacy)=${PJSIP_HEADER(read,Privacy)})

-- Executing [200@hpbx:30] NoOp("SIP/hpbx-00000107", "CALLERID(priv-num-pres)=allowed_not_screened") in new stack
-- Executing [200@hpbx:31] NoOp("SIP/hpbx-00000107", "CALLERID(priv-name-pres)=allowed_not_screened") in new stack
-- Executing [200@hpbx:32] NoOp("SIP/hpbx-00000107", "CALLERID(priv-tag)=") in new stack
-- Executing [200@hpbx:33] NoOp("SIP/hpbx-00000107", "CALLERID(priv-num-pres)=allowed_not_screened") in new stack
-- Executing [200@hpbx:34] NoOp("SIP/hpbx-00000107", "CALLERID(priv-all)="" <>") in new stack
-- Executing [200@hpbx:35] NoOp("SIP/hpbx-00000107", "SIP_HEADER(Privacy)=id") in new stack

-- Executing [200@Trunk:5] NoOp("PJSIP/KHSBG1-001f269a", "CALLERID(priv-num-pres)=allowed_not_screened") in new stack
-- Executing [200@Trunk:6] NoOp("PJSIP/KHSBG1-001f269a", "CALLERID(priv-name-pres)=allowed_not_screened") in new stack
-- Executing [200@Trunk:7] NoOp("PJSIP/KHSBG1-001f269a", "CALLERID(priv-tag)=") in new stack
-- Executing [200@Trunk:8] NoOp("PJSIP/KHSBG1-001f269a", "CALLERID(priv-num-pres)=allowed_not_screened") in new stack
-- Executing [200@Trunk:9] NoOp("PJSIP/KHSBG1-001f269a", "CALLERID(priv-all)="" <>") in new stack
-- Executing [200@Trunk:10] NoOp("PJSIP/KHSBG1-001f269a", "PJSIP_HEADER(read,Privacy)=id;user;header") in new stack

Asterisk 18.12.3

#8

And what is the actual SIP INVITE and endpoint configuration? (For PJSIP)

#9

my guess it is the trust_id_inbound, but we cant use that one as it will take the number i PAI and set it as CALLERID(num) and we are not allowed to do that as Danish Providers must uses that for identifying the original user (CLIP-SA)

[shared](!)
type=wizard
aor/qualify_frequency=30        ; Interval at which to qualify an AoR via OPTIONS requests. (default: "0")
aor/qualify_timeout=1.0         ; Qualify timeout in fractional seconds (default: "3.0")
endpoint/allow=!all,alaw,ulaw
endpoint/allow_overlap=no
endpoint/allow_transfer=no
endpoint/contact_user=uni-tel
endpoint/cos_audio=5
endpoint/direct_media=no
endpoint/direct_media_glare_mitigation=outgoing
endpoint/identify_by=ip
endpoint/rtp_timeout=60         ; hmm TDC uses 5 so we should change ???
endpoint/rtp_timeout_hold=3600
endpoint/sdp_session=uni-tel
endpoint/t38_udptl=yes
endpoint/t38_udptl_ec=redundancy
endpoint/tos_audio=ef
endpoint/trust_id_inbound=no    ; if yes asterisk wil move PAI to From
endpoint/trust_id_outbound=yes
endpoint/user_eq_phone=yes

[tdc-gw](!)
endpoint/context=tdc-gw
endpoint/direct_media_method=update

[TDC-SBC-CPH](shared,shared_public,tdc-gw)
remote_hosts=111.222.333.444
#10

That’s correct, that would be why it isn’t there for you. That option is what controls usage of PAI and the Privacy header.

#11

If you say they are misusing PAI, that would invalidate Privacy, as it is the privacy of the PAI that it refers to.

#12

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