SOLVED Need to remove Privacy header

Status
Not open for further replies.
P

pbxgeek

Active Member
Jan 19, 2021
281
108
43
38
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:
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.
 
@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.
 
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...
 
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.
 
What does your sip invite contain when you unset sip_h_Privacy?
 
It doesn't seem to unset the privacy header. It always has
Code: 
Privacy: none
and the door bell doesn't like it
 
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:
@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.
 
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.
 
pbxgeek said:
@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.
Click to expand...
Which doorbells do not play well with others?
 
pbxgeek said:
the header is set after it hits the Freeswitch box. It's not coming from the PSTN.
Click to expand...
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.
 
@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.
 
What is in the header when using a different make and model device?
 
@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.
 
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.
 
Status
Not open for further replies.
Top Bottom