You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Overview

The

Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
 identifies these two cases as presentation restriction. When the presentation is restricted, if the SIP trunk has a default number configured, the
Unable to show "metadata-from": No such page "_space_variables"
 uses that number in the user part of FROM header while sending the egress message.

The 

Unable to show "metadata-from": No such page "_space_variables"
supports caller privacy for incoming and outgoing calls as described below:

  • For incoming calls from the SIP Trunk that the Enterprise
    Unable to show "metadata-from": No such page "_space_variables"
     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
    Unable to show "metadata-from": No such page "_space_variables"
     denotes an anonymous user or is a SIP URI with an alias name, the
    Unable to show "metadata-from": No such page "_space_variables"
     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 SBCsupportedlimitedfunctionalityof the 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:

  • applyPrivacyId
  • applyPrivacyUser
  • passThruPrivacyInfo
  • supportPrivacyId
  • supportPrivacyUser
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:

Apply Privacy ID and User

IngressIngress PP FlagsEgress
Privacy: userApplyPrivacyUser= falseNo AF
Privacy: userApplyPrivacyUser= trueAF
Privacy: idApplyPrivacyUser = True

No AF, 

No AP

Privacy: idApplyPrivacyUser = false

No AF, 

No AP

Privacy: idApplyPrivacyId = falseNo AP
Privacy: idApplyPrivacyId = trueNo AP
Privacy:userApplyPrivacyId = false

No AF, 

No AP

Privacy: userApplyPrivacyId = 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 applyPrivacyId and applyPrivacyUser flags at the ingress side:

Supported Privacy ID and User

IngressEgress PP FlagsEgress
Privacy: userSupportPrivacyUser= falseNo AF
Privacy: userSupportPrivacyUser = trueAF
Privacy: idSupportPrivacyUser= false

No AF, 

No AP

Privacy: idSupportPrivacyUser= true

No AP,

AF
Privacy: idSupportPrivacyId = falseNo AP
Privacy: idSupportPrivacyId = trueAP
Privacy:userSupportPrivacyId= false

No AF, 

No AP

Privacy: userSupportPrivacyId = 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.

  • No labels