Versions Compared

Old Version 1

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel

In this section:

Table of Contents
maxLevel3

Info

Related articles:

Overview

...

borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

...

The

Spacevars
0series4
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

Spacevars
0product
 identifies these two cases as presentation restriction. When the presentation is restricted, if the SIP trunk has a default number configured,

...

the

Spacevars
0product
 uses that number in the user part of FROM header while sending the egress message.

The 

Spacevars
0series4
supports caller privacy for incoming and outgoing calls as described below:

  • For incoming calls from the SIP Trunk that the Enterprise

...

  • Spacevars
    0product
     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

...

  • Spacevars
    0product
     denotes an anonymous user or is a SIP URI with an alias name, the

...

  • Spacevars
    0product
     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:

  • applyPrivacyId
  • applyPrivacyUser
  • passThruPrivacyInfo
  • supportPrivacyId
  • supportPrivacyUser
Info
titleNote

The parameters applyPrivacyId and applyPrivacyUser is applicable to the ingress Trunk Group and supportPrivacyId and supportPrivacyId is applicable to the egress Trunk Group.

Info
titleNote

The P-Asserted-Id (PAI) header is sent to egress only when the flag includePrivacy enabled and privacyInformation is configured as pAssertedId.

Code Block
% set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy flags includePrivacy enable
% set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy privacyInformation pAssertedId
Info
titleNote
  • 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:

Caption
0Table
1Apply 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 = trueAP
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 supportPrivacyId and supportPrivacyUser flags at the egress side:

Caption
0Table
1Supported 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.

Pagebreak