IMPORTANT

Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.

Refer to the SBC SIP Transparency Implementation Guide for additional information.

 

Default PUI procedures enable the SBC Core acting as P-CSCF to create an asserted-identity (contained in the P-Asserted-Identity header field) within IP Multimedia Core Network Subsystem for any UE originated initial request for a dialog or request for a stand-alone transaction.

The UE can indicate privacy of the P-Asserted-Identity generated by the P-CSCF as part of Default PUI procedures. P-CSCF is expected to generate P-Asserted-Identity in the requests towards core, and transparently passes any privacy information indicated by UE.

When the P-CSCF receives an initial request for a dialog or a request for a stand-alone transaction from a UE that is not considered a privileged sender, one of the following actions are taken:

No P-Preferred-Identity header—If the request does not include any P-Preferred-Identity header field or none of the P-Preferred-Identity header fields included in the request matches any of the registered public user identities or any of the registered wild-carded public user identities, the P-CSCF identifies the originator and the served user of the request by the default public user identity.

  • The SBC inserts P-Asserted-Identity in the forwarded SIP message with the contents of the default public user identity.

One or two P-Preferred-Identity headers—If the request includes one or two P-Preferred-Identity header field(s), each of which matches one of the registered public user identity or a registered wildcarded public user identity, the P-CSCF identifies the originator and the served user of the request by the public user identity from the first such P-Preferred-Identity header field. SBC also removes all P-Preferred-Identity headers in the forwarded request.

  • The SBC inserts P-Asserted-Identity in the forwarded SIP message with the contents of matching P-Associated-URI.

 

Info
The SBC include an alternative identity for all request types, including emergency requests. To generate the alternative address, the first two P-Preferred-Identity headers are examined. If both of these headers match a stored P-Associated-Id, the SBC generates two P-Asserted-Id headers in the outgoing request. If an alternative Id for an emergency request is not identified, and if the first P-Asserted-Id header added contains a SIP URI, the first Tel URI from the list of implicitly registered public user identities is used to create the alternative identity, and vice versa.
Note
Procedures related to supporting a privileged sender presenting a custom calling identity not linked to P-Associated-URI sent by the S-CSCF are not supported in the current release.

Since S-CSCF uses the P-Asserted-Identity header field when checking whether the UE originating request matches the initial filter criteria, the P-Preferred-Identity header field inserted by the UE determines which services and applications are invoked.

Default PUI behavior is configurable with enableDefaultPUIProcedures flag from the IP Signaling Profile. Default value is “disabled”. For an SBC acting as a P-CSCF, this flag should be enabled in the IP Signaling Profile assigned to the egress trunk group (towards IMS core).

When SBC acting as P-CSCF receives a 200 OK to REGISTER a SIP message, it stores the P-Associated-URIs, including any associated display names, and any parameters associated with either the user or the identities of the user, present in the response in AOR RCB list. When this value is anything other than zero, the SBC launches the following procedure:

  • Stores any PUIs and wildcarded PUIs found in the P-Associated-URI header field value, including any associated display names and any parameters associated with either the user or the identities of the user, and applies them to the registered PUI (i.e. the registered PUI and its associated set of implicitly registered PUIs). Implicitly registered wildcarded PUIs are bound to the contact address and security association or TLS session over which the REGISTER request was received.
  • Stores default PUI, including associated display name and any parameters associated with either the user or the identities of the user, if provided, for procedures for P-Asserted-Identity header field for requests received from the UE over the respective security association or TLS session. The default PUI is the first on the list of URIs present in the P-Associated-URI header field.

P-CSCF supports a total of 20 P-Associated-URIs in the 200 OK response to REGISTER message.

For each contact address and its security association or TLS session, SBC maintains a list of registered PUIs and associated default PUIs to populate the P-Asserted Identity header. More than one default public user identity can be stored on the SBC to support multiple PUI registrations.

Future SIP requests from the registered users which contain P-Preferred-Identity values are compared with the stored list of URIs in the AoR RCB list (internally stored registration info). If the P-Preferred-Identity is present in the list, the egress SIP request is added with the P-Asserted-Identity with the URI present (including any associated display names, and any parameters associated with either the user or the identities of the user). If the ingress SIP request does not contain the P-Preferred-Identity or the P-Preferred-Identity values are not matching with the AOR RCB list, the default public user identity picked from the top of the AOR list is added as P-Asserted-Identity.

When configuring Default PUI procedures, the following conditions apply:

  • When enabledDefaultPUIProcedures flag is enabled conjointly with privacy flags, this flag takes precedence.
  • The Privacy header transparency flag must be disabled to allow Default PUI procedures.
  • In IBCF mode, the enableDefaultPUIProcedures flag is disabled.

Example:

In the following example, default PUI procedures are enabled for IP signaling profile "DFL_PCSCF_CORE_TG_PROF", and then the profile is associated with the core trunk group "TG_PCSCF_EXT_IP".

% set profiles signaling ipSignalingProfile DFL_PCSCF_CORE_TG_PROF commonIpAttributes flags enableDefaultPUIProcedures enabled
% set addressContext default zone ZONE_AS sipTrunkGroup TG_PCSCF_EXT_IP policy signaling ipSignalingProfile DFL_PCSCF_CORE_TG_PROF
% commit
Info

For configuration details, refer to:

  • No labels