In this section:
Use this screen to configure privacy profiles that govern how the SBC applies privacy services. Profiles are assigned to ingress or egress SIP trunk groups and therefore allow handling privacy independently on each call leg. Options in this profile determine how privacy:id and privacy:user are handled. Using this screen you can also remove non-essential headers that are added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To, and In-Reply-To headers. The SBC supports privacy profile over GW-GW calls (SBC-SBC GW calls).
The SBC gives precedence to SIP Privacy handling when the SIP Adaptive Transparency Profile is enabled. For example, if the incoming SIP message contains "privacy: Id" and the flag applyPrivacyId
under profiles services privacyProfile
is set to enable
, the SBC does not include P-ASSERTED-ID
header in the egress message.
The SBC supports privacy profile over GW-GW calls (SBC-SBC GW calls).
For information on SIP Adaptive Transparency Profile, refer to SIP Adaptive Transparency Profile - CLI.
% set profiles services privacyProfile <privacyProfile> anonymizationValueforHostpart <anonymization string> anonymizationValueforUserpart <anonymization string> anonymizationValueforDispName <anonymization string> applyPrivacyId <disabled | enabled> applyPrivacyUser <disabled | enabled | <ifRcvdPrivacyUserOrIdOrBoth> passThruPrivacyInfo <disabled | enabled> supportPrivacyId <disabled | enabled | ifRcvdPrivacyId> supportPrivacyUser <disabled | enabled | ifRcvdPrivacyUser | ifRcvdPrivacyUserOrIdOrBoth>
The Privacy Profile parameters are defined below:
Parameter | Length/Range | Description |
---|---|---|
anonymizationValueforHostpart | UCHAR (0..64) | Values to use for anonymization Hostpart in from" and contact headers while applying privacy semantics. |
anonymizationValueforUserpart | UCHAR (0..64) | Values to use for anonymization Userpart in from and contact headers while applying privacy semantics. |
anonymizationValueforDispName | UCHAR (0..64) | Values to use for anonymization Display Name in from and contact headers while applying privacy semantics. |
| 1-23 characters |
NOTE: To attach this Privacy Profile to a trunk group, refer to SIP Trunk Group - Services - CLI. |
applyPrivacyId | N/A | If the incoming SIP message contains "privacy: Id" and this flag is enabled, the Unable to show "metadata-from": No such page "_space_variables" does not include P-Asserted-Id header in the egress message.
|
| N/A | If the incoming SIP message contains "privacy: user" and this flag is enabled, the Unable to show "metadata-from": No such page "_space_variables" anonymizes FROM and Contact headers.
|
| N/A | NOTE: This flag overrides the other If this flag is enabled, the Privacy header is passed transparently to the outgoing message and the Unable to show "metadata-from": No such page "_space_variables" sends P-Asserted-Id or FROM header as received.
|
| N/A | If this flag is enabled, the outgoing SIP message from the Unable to show "metadata-from": No such page "_space_variables" does not include the P-Asserted-Id (PAI) header even though the incoming message does not contain "privacy: id" header. When set to the option "ifRcvdPrivacyId", the Unable to show "metadata-from": No such page "_space_variables" removes PAI/Privacy: id only if the ingress INVITE includes the "privacy: id" header.
|
| N/A | If this flag is enabled, the outgoing SIP message from the Unable to show "metadata-from": No such page "_space_variables" includes anonymized FROM and Contact headers even though the incoming message does not contain "privacy: user" header.
|
useReceivedValues | N/A | Send the From and PAI headers transparently in conjunction with parameters above. |
When privacy profile and privacyParamRestricted is set, then privacy profile gets higher precedence.
When an Invite is received with the Privacy:id
, even though the Privacy Profile is not configured to Anonymize From /Contact Header
due to Ingress Leg properties, the SBC sends From Header anonymized. Ribbon recommends to configure useReceivedValues < sipFromHeader/ telFromHeader>
to avoid this scenario.
The following example configures a Privacy Profile and attaches it to a trunk group:
set profiles services privacyProfile Test applyPrivacyId enabled applyPrivacyUser enabled passThruPrivacyInfo disabled supportPrivacyId enabled supportPrivacyUser enabled set addressContext default zone defaultSigZone sipTrunkGroup TG1 services privacyProfile Test commit show profiles services privacyProfile privacyProfile Test { applyPrivacyId enabled; applyPrivacyUser enabled; supportPrivacyId enabled; supportPrivacyUser enabled; passThruPrivacyInfo disabled; } [ok]
The following examples configure a Privacy Profile using the fields anonymizationValueforUserpart, anonymizationValueforHostpart, and anonymizationValueforDispName in the privacy profile.
set profiles services privacyProfile <EGR_PRIV> anonymizationValueforHostpart <Anonymous.invalid > set profiles services privacyProfile <EGR_PRIV> anonymizationValueforUserpart <Anonymous > set profiles services privacyProfile <EGR_PRIV> anonymizationValueforDispName <Anonymous> set profiles services privacyProfile EGR_PRIV supportPrivacyId <disabled/enabled/ifRcvdPrivacyId > set profiles services privacyProfile EGR_PRIV supportPrivacyUser<disabled/enabled/ ifRcvdPrivacyUser>
% set profiles services privacyProfile <EGRPRIVACYPROFILE> useReceivedValues sipFromHeader displayName,fqdnHostPart,ipHostPart,params,userPart % set profiles services privacyProfile <EGRPRIVACYPROFILE> useReceivedValues sipPaiHeaderr displayName,fqdnHostPart,ipHostPart,params,userPart % set profiles services privacyProfile <EGRPRIVACYPROFILE> useReceivedValues TelPaiHeader displayName,userPart,params % set profiles services privacyProfile <EGRPRIVACYPROFILE> useReceivedValues TelFromHeader displayName,userPart,params