SOLVED Need to remove Privacy header

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
Hello,
I'm dealing with a doorbell that rejects a call because of Privacy: none header. Here is the the full INVITE.


Code:
INVITE sip:600@192.168.12.12:37310;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 149.28.xx.xx;rport;branch=z9hG4bKF4ZSHpc2vrcKj
Route: <sip:600@69.112.xx.xx:60980>;transport=TCP
Max-Forwards: 68
From: "CALLER ID" <sip:+1310xxxxxxx@m302w>;tag=t0rDmp1j9pFKD
To: <sip:600@192.168.12.12:37310;transport=TCP>
Call-ID: f0a045cc-c99e-123d-6f9d-3cecefb9f556
CSeq: 86647714 INVITE
Contact: <sip:mod_sofia@149.28.46.101:5060;transport=tcp>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Session-Expires: 120;refresher=uac
Min-SE: 120
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 461
X-FS-Support: update_display,send_info
P-Asserted-Identity: "CALLER ID" <sip:+1310xxxxxxx@m302w>

Support asked me to remove it, and I've tried many ways to do it, but so far, nothing.
For example, this doesn't work.

Code:
<action application="unset" data="sip_h_Privacy"/>
 
Last edited:

voipBull

Member
Dec 3, 2023
66
11
8
I really thought you can do this using the unset action in your dialplan. Maybe not. I'll try it today, will let you know if I get any success.
 

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
@Adrian Fretwell
I tried sip_cid_type=none and <action application="privacy" data="yes"/> In different combinations. Something is still not working. Perhaps I didn't try a proper combination or something.
It's not coming from the provider. Freeswitch assigns it on the B-leg to the doorbell. Also, this only happens when an external number is called. When I dial locally, there is no privacy header, and the doorbell answers the call.
 

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,489
411
83
I have just tried, various combinations of calls on two of our PBXs and I never see that Privacy header. I agree that Freeswitch must be generating it, but I wonder what the trigger is. As you say it only happens on inbound from an external number, I wonder if it could be a setting in the external SIP profile or the Gateway record. I notice that on all of our gateways we have caller-id_in_from set.
It's an interesting one...
 

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
caller-id_in_from is also set on this gateway. It's definitely a setting that controls it, but I can't find any information on what it is. I was hoping someone had come across this issue before. I spent all day yesterday trying to figure it out.
 

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
It doesn't seem to unset the privacy header. It always has
Code:
Privacy: none
and the door bell doesn't like it
 

whut

Member
Dec 23, 2022
207
19
18
review and try the actions in the call_privacy dialplan.

Code:
<action application="privacy" data="full"/>
<action application="set" data="sip_h_Privacy=id"/>
<action application="set" data="privacy=yes"/>



Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function

header Request that privacy services modify [RFC3323]
headers that cannot be set arbitrarily
by the user (Contact/Via).

session Request that privacy services provide [RFC3323]
privacy for session media

none Privacy services must not perform any [RFC3323]
privacy function

critical Privacy service must perform the [RFC3323]
specified services or fail the request

id Privacy requsted for Third-Party [RFC3325]
Asserted Identity

history Privacy requested for [RFC4244]
History-Info header(s)
 
Last edited:

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
@whut I had it set up similarly to your example, but not exactly the same. Using your example, I was able to adjust it to
Code:
Privacy: id
However, the doorbell system still rejects the call unless the header is completely removed, and I can't figure out how to remove it. When it's a local call from another extension, the header is not there. But when it's an external call the header gets populated.
 

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,489
411
83
I think by now I would be thinking either:
1. Change the door bell.
2. If you have an (and I hate the term) SBC anywhere in the link, such as an OpenSIPS proxy, then get that to rip out the header.
 

whut

Member
Dec 23, 2022
207
19
18
@whut I had it set up similarly to your example, but not exactly the same. Using your example, I was able to adjust it to
Code:
Privacy: id
However, the doorbell system still rejects the call unless the header is completely removed, and I can't figure out how to remove it. When it's a local call from another extension, the header is not there. But when it's an external call the header gets populated.
Which doorbells do not play well with others?
 

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,489
411
83
the header is set after it hits the Freeswitch box. It's not coming from the PSTN.
I get that.
I just can't see (at the moment) how or why FreeSWITCH is setting it. It does not get set in any of my tests. Just wondering if there is something else going on with the INVITE from the PSTN that is causing it to get set.
 

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
@Adrian Fretwell It's possible that my device has certain settings that are causing this behavior. However, I can't seem to figure out what the issue is. A Lua script didn't help either. The header is not there until the INVITE is sent.
 

pbxgeek

Active Member
Jan 19, 2021
117
51
28
37
@whut It doesn't matter what device. The header is added for all external calls. Other devices ignore it, but this doorbell is a pain.
 

whut

Member
Dec 23, 2022
207
19
18
Where and how are you trying to overwrite privacy: none? I would try to do it in a dialplan. The inbound route dialplan before the transfer is a logical location and order to me. Perhaps a custom sip profile for this case. I would explore dialplans and the foremost method.

I would review cdr call log application and watch the call in sngrep to try to better understand and hopefully identify when and where.