Wilcarded PUI Support

Introduction

A wildcarded Public User Identity (PUI) represents a collection of PUIs that share the same service profile and are included in the same implicit registration set. The wildcarded PUI is received only in the P-Associated-URI of the 200 OK response for REGISTER (no other headers apply).

The format of a wildcarded Public User Identity is the same as that of a wildcarded PSI. An example of a wildcarded PUI is as follows: "sip:chatlist!.*!@example.com".

Please note that the exclamation mark “!” is used to identify the start and end of the wild card part of PUI. If there are more than two exclamation marks in a PUI, the outermost two marks are considered the boundaries for the wildcarded part of the PUI. The exclamation mark is not allowed in the static part of PUI. This matches sip:chatlist1@example.com, sip:chatlist2@example.com, sip:chatlist42@example.com, sip:chatlistAbC@example.com etc.

Registration Support

When registering any distinct PUI that matches a wildcarded PUI, S-CSCF includes it in the P-Associated-URI in the 200 OK response to the register message. When a P-CSCF receives the 200 OK response with the Wildcarded PUI, it stores the public user identities and Wildcarded public user identities found in the P-Associated-URI header field value, including any associated display names, plus any parameters associated with either the user or the identities of the user. It associates them to the registered public user identity, i.e. the registered public user identity and its associated set of implicitly registered public user identities and implicitly registered wildcarded public user identities bound to the contact address and security association or TLS session over which the REGISTER request was received.

Figure 1: High Level Call flow

Registration Admission Control

The SBC supports registration admission control on both ingress and egress legs. From a CAC perspective, a single Wildcarded entry in a P-Associated-URI of 200 OK is considered as a single registration.

The following table defines the implementation details (In P-CSCF context, this relates to ingress functionality).

Table 1: Registration Implementation Details

The following configurations are supported on a per-Trunk Group basis.

Table 2: Supported configurations

Handling of Calls and Other OOD Requests From UE

When an incoming call is received from an endpoint, the endpoint can use any of the PUIs matching the wild-carded PUI as the AoR in the INVITE request that it sends. On receiving an INVITE with a distinct PUI that is within the range of the previously registered wild-carded PUI, the SBC identifies the correct registration context and processes the call accordingly. This also applies to any Out-of-Dialog Requests received from the endpoint.

Handling of Requests From Core

When the SBC receives P-Called-Party-Id in any request it receives from the core where the PUI received falls within the range of a previously registered wild-carded PUI, the SBC identifies and uses the correct registration. When sending out a provisional or final response for the request, the display name previously stored during registration is used if not received in the P-Called-Party-Id header.

This behavior applies to INVITE, other out-of-Dialogue requests like SUBSCRIBE and standalone transactions such as OOD, INFO, etc., received from the network towards the UE.

Default PUI Procedures

Default PUI procedures enable the SBC acting as P-CSCF to create an Asserted-identity within the IMS network for any UE originated initial request for a dialog or a stand-alone transaction. The SBC identifies the originator and served user of the request by comparing the received P-Preferred-Identify from the UE against the distinct PUIs received in the P-Associated-URI during the registration procedures. When a match is found, the SBC inserts a P-Asserted-id header in the forwarded SIP message, with the contents of the matching P-Associated-URI. It will also remove the P-Preferred-Identity in the forwarded request.  If there are two or more P-Preferred-Identify headers present, the top two PPI headers are considered.

The SBC compares the received P-Preferred-Identity with the wildcarded PUI as well. The SBC does not support the identification of a privileged user.

The SBC validates the P-Preferred-Identity header if received in the SIP request message received from UE against the stored list of the P-Associated-URI header (for this association), including any wildcarded PUI, before forwarding header towards IMS core network.

• If a match occurs, the SBC inserts P-Asserted-Identity in the forwarded SIP message with the contents received in the P-Preferred-Id. It also removes P-Preferred-Identity in the forwarded request.
• If there are two or more P-Preferred-Identity headers present, the two top most P-Preferred-Identify headers are considered. Based on the match for these top 2 PPI headers, The SBC  adds a maximum of 2 P-Asserted-Id headers in the outgoing message.
• If a match does not occur, the SBC inserts P-Asserted-Identity in the forwarded SIP message with the default public user identity (of the association, stored at the time of registration). It also removes P-Preferred-Identity in the forwarded request. If two P-Preferred-Identity headers are present, both headers result in a mismatch for this condition to occur.

This is applicable for INVITE, other Out-of-Dialog requests like SUBSCRIBE and standalone transactions like OOD – MESSAGE, INFO, PUBLISH etc.

When a received P-Preferred-Identity matches both a distinct PUI and a wildcarded PUI, the distinct PUI takes precedence and be used for the default PUI procedure mentioned above.

When a received P-Preferred-Identity is matched with a wildcarded PUI and not with any distinct PUI, The SBC adds a P-Profile-key header field with the wildcarded PUI value (including any received display name and parameters). This applies to responses to INVITE and other OOD requests as well.

The SBC (acting as PCSCF) permits 200 PUI (Public User Identity) either in Tel-URI or SIP-URI format. These PUI’s can be wildcarded or non-wildcarded.

P-Associated-Uri: 
<sip:test1!.*!@172.19.52.42>, 
<sip:test2!.*!@172.19.52.42>, ……., 
<sip:testexample200!.*!@172.19.52.42>

P-Associated-Uri: 
<sip:test1!.*!@172.19.52.42>, 
<sip:test2!.*!@172.19.52.42>
P-Associated-Uri: 
<sip:test3!.*!@172.19.52.42>, 
<sip:test4!.*!@172.19.52.42>,……,
<testexample200!.*!@172.19.52.42>

Transparency Support

The SBC, acting as IBCF, is capable of transparently passing any wildcarded PUI that it receives in the P-Associated-URI of the 200 OK response to the REGISTER. Also when a P-CSCF sends a P-Profile-Key header with the wildcarded PUI, The SBC acting as IBCF can transparently pass it on without acting upon it.

set profiles services transparencyProfile <profile> sipHeader <SIP Header>