DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
Overview
The SBC Core supports caller privacy dynamically based on privacy header.
The special URI anonymous@host; user=phone in From header field denotes an anonymous user whose presentation is restricted. Microsoft Lync 2010 Mediation Server uses the alias name of the user in the FROM header (instead of phone number) and without user=phone parameter, to hide a phone number. The SBC identifies these two cases as presentation restriction. When the presentation is restricted, if the SIP trunk has a default number configured, the SBC uses that number in the user part of FROM header while sending the egress message.
The SBC Core supports caller privacy for incoming and outgoing calls as described below:
- For incoming calls from the SIP Trunk that the Enterprise SBC is to present to the Mediation Server, if the Calling Party Number/ANI indicates restricted presentation, the From URI in the SIP INVITE sent to the Mediation Server denotes an anonymous user.
- For outgoing calls from the Mediation Server, if the From URI in the SIP INVITE sent to the Enterprise SBC denotes an anonymous user or is a SIP URI with an alias name, the SBC excludes or sets the default value to Calling Party Number sent to the SIP Trunk.
Privacy Info for User and ID
Prior to 7.1.0 release, the SBC supported limited privacy header handling. The SBC supports the privacy handling on the "From" header when "privacy: user" or 'privacy: id' are received in the request.
From 7.1.0 release onwards, the SBC supports:
- The privacy handling on the "P-Asserted-Id (PAI)" header when the "privacy: id" is received and applies this privacy handling on the "From" header when "privacy: user" is received.
- The new privacy profile configuration to apply privacy services independently on each leg.
Remove any non-essential headers that are added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To, and In-Reply-To.
To configure this feature, the privacyProfile is added to the services.
The following flags are added to the privacyProfile:
applyPrivacyIdapplyPrivacyUserpassThruPrivacyInfosupportPrivacyIdsupportPrivacyUser
Note
The parameters applyPrivacyId and applyPrivacyUser is applicable to the ingress Trunk Group and supportPrivacyId and supportPrivacyId is applicable to the egress Trunk Group.
Note
The P-Asserted-Id (PAI) header is sent to egress only when the flag includePrivacy enabled and privacyInformation is configured as pAssertedId.
% set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy flags includePrivacy enable % set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy privacyInformation pAssertedId
Note
- When transparency is enabled for From/PAI/Privacy header, it takes highest precedence.
- The SBC does not apply any privacy logic in out of dialog messages (SUBSCRIBE, REFER, REGISTER).
- The anonymization for From and Contact headers occurs automatically for Re-INVITE and in-dialog UPDATE requests.
- The SBC does not add PAI header for re-INVITE and in-dialog UPDATE requests.
Apply Privacy ID and User
The following table describes the behavior of the applyPrivacyId and applyPrivacyUser flags at the ingress side:
Table 1: Apple Privacy ID and User
| Ingress | Ingress PP Flags | Egress |
|---|---|---|
| Privacy: user | ApplyPrivacyUser= false | No AF |
| Privacy: user | ApplyPrivacyUser= true | AF |
| Privacy: id | ApplyPrivacyUser = True | No AF, No AP |
| Privacy: id | ApplyPrivacyUser = false | No AF, No AP |
| Privacy: id | ApplyPrivacyId = false | No AP |
| Privacy: id | ApplyPrivacyId = true | AP |
| Privacy:user | ApplyPrivacyId = false | No AF, No AP |
| Privacy: user | ApplyPrivacyId = True | No AF, No AP |
AF - Anonymize FROM header, which includes From, Contact, Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To headers, Remove Privacy: user from ingress.
AP - Removing PAI header, Remove Privacy: id from egress.
Supported Privacy ID and User
The following table describes the behavior of the supportPrivacyId and supportPrivacyUser flags at the egress side:
Table 2: Supported Privacy ID and User
| Ingress | Egress PP Flags | Egress |
|---|---|---|
| Privacy: user | SupportPrivacyUser= false | No AF |
| Privacy: user | SupportPrivacyUser = true | AF |
| Privacy: id | SupportPrivacyUser= false | No AF, No AP |
| Privacy: id | SupportPrivacyUser= true | No AP, AF |
| Privacy: id | SupportPrivacyId = false | No AP |
| Privacy: id | SupportPrivacyId = true | AP |
| Privacy:user | SupportPrivacyId= false | No AF, No AP |
| Privacy: user | SupportPrivacyId = true | No AF, AP |
AF - Anonymize FROM header, which includes From, Contact, Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To headers, Remove Privacy: user from ingress.
AP - Removing PAI header, Remove Privacy: id from egress.
Pass-through Privacy Info
If the flag passThruPrivacyInfo is enabled on ingress and egress, the outgoing message contains the PAI/From/Privacy headers as received from the ingress. This flag is applicable when the privacyProfile is associated with both ingress and egress Trunk Group.
Overview
Content Tools