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

Compare with Current View Page History

« Previous Version 3 Current »

In this section:

Related articles:

Introduction

A wildcarded Public User Identity (PUI) represents a collection of Public User Identities 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 top-most entry in the P-Associated-URI cannot be a wildcarded PUI.

The format of a wildcarded Public User Identity is the same as for the 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 as the boundaries for the wildcarded part of the PUI. The exclamation mark is not allowed to be present 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.

The
Unable to show "metadata-from": No such page "_space_variables"
supports the following P-Associated-URI characters: "a-z A-Z 0-9 - . $ % * _ + ~ ` ' ! [ ] ^ { } \ ( ) ? | < > &" .

Registration Support

During registration of any of the 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, and 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.

High Level Call flow

Registration Admission Control

The

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

Registration Implementation Details

Message Received CriteriaSBC Response

REGISTER request

 

  • A limit is provisioned on the egress leg for the maximum number of registrations
  • The registration limit on the egress IP TG is already reached
SBC replies with 403 "Forbidden" response code on the ingress leg.

REGISTER request

 

The number of estimated child registrations on the ingress IP TG does not exceed remaining registration quota on the ingress leg.SBC egresses the REGISTER request.

REGISTER request

 

The number of estimated child registrations on the ingress IP TG exceeds remaining registration quota on the ingress leg.SBC does not egress the REGISTER request and replies with 403 "Forbidden" on the ingress leg.

A 200 response for REGISTER request

  • The number of P-Associated-URI headers in the message is more than the estimated child registrations on the ingress IPTG.
  • The difference between these values is less than or equal the remaining quota for registrations on the ingress IP TG.
 		SBC forwards 200 response for REGISTER request.

A 200 response for REGISTER request

  • The number of P-Associated-URI headers in the message is more than the estimated child registrations on the ingress IP TG.
  • The difference between these values is more than the remaining quota for registrations on the ingress IP TG.
SBC sends 403 "Forbidden" response on the ingress leg and de-registration request on the egress leg.

 

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

show addressContext <name> zone <name> sipTrunkGroup <name> cac registrationLimit The total number of concurrent SIP registrations allowed on this trunk group.
show addressContext <name> zone <name> sipTrunkGroup <name> cac estimatedChildRegistrationsThe estimated number of child registrations per registration expected on this trunk group.

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 which is within the range of the previously registered wild-carded PUI, the

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

Unable to show "metadata-from": No such page "_space_variables"
 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
Unable to show "metadata-from": No such page "_space_variables"
 identifies and uses the correct registration. When sending out 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 is applicable for INVITE, other Out-of-Dialog 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

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

Unable to show "metadata-from": No such page "_space_variables"
 compares the received P-Preferred-Identity with the wildcarded PUI as well. The
Unable to show "metadata-from": No such page "_space_variables"
 does not support the identification of a privileged user.

The

Unable to show "metadata-from": No such page "_space_variables"
 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
    Unable to show "metadata-from": No such page "_space_variables"
     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
    Unable to show "metadata-from": No such page "_space_variables"
      adds a maximum of 2 P-Asserted-Id headers in the outgoing message.
  • If a match does not occur, the
    Unable to show "metadata-from": No such page "_space_variables"
     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 there are two P-Preferred-Identity headers present, both the headers result in 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

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

Transparency Support

The

Unable to show "metadata-from": No such page "_space_variables"
, 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
Unable to show "metadata-from": No such page "_space_variables"
 acting as IBCF can transparently pass it on without acting upon it.

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

 

  • No labels