Handling Barred PUIDs

The Oracle Communications Unified Session Manager supports PUID barring functionality per 3GPP specification TS 24.229. As such, the system does not service any request method other than REGISTERs for SIP or Tel-URI PUIDs designated as barred by the HSS. The Oracle Communications Unified Session Manager also complies with the requirement that it allow Push Profile Requests (PPRs) to change a PUID from barred to non-barred (and vice versa) and issues a NOTIFY of the event to subscribers. No configuration is required.

A common use case for barring information is a cell phone registering with a temporary PUID (that is barred), along with a set of non-barred PUIDs in the P-Associated User (PAU) header. After registration, the cell phone should use only the non-barred PUIDs for all ensuing methods and its contacts.

An HSS should be configured with barring information for all PUIDs. During registration procedures, the HSS provides this information to the S-CSCF. PUID information in the User Data AVP of the Diameter SAA includes a tag indicating whether the PUID is barred. The Oracle Communications Unified Session Manager retains this information in the registration cache. To complete the registration, the Oracle Communications Unified Session Manager replies to the UE with a list of all non-barred PUIDs in the 200OK. For all the further procedures, the UE should use a PUID from the non-barred P-Associated-URI list. If the HSS does not identify a PUID's barring status, the Oracle Communications Unified Session Manager assumes it is not barred.

Typical Oracle Communications Unified Session Manager behaviors related to barring include:

Responds to ensuing requests from barred PUIDs with (403) Forbidden.
Responds to requests that have no PSU, but include barred PUIDs in their PAI header list with 403 (Forbidden).
Responds to requests to or from wildcarded PUIDs that match barred PUIDs with 403 (Forbidden).
Responds to registration attempts that have all barred implicit identities with 403 (Forbidden).
Responds to requests for termination services wherein the served user (PSU/RURI) is barred with (404) Not Found.
Recognizes barring status during third party registration procedures and does not attempt to register a barred PUID to an AS.
Handles related subscription scenarios as follows:
- When receiving a subscription from a barred subscriber, responds with 403 (Forbidden).
- When receiving a subscription for a barred user, allows the SUBSCRIBE to proceed.
- Does not include a barred identity in any NOTIFY.
  - When receiving a subscription for a user that has barred identities in its implicit set, issues NOTIFYs that only include non-barred identities.
  - Includes only non-barred PUIDs in NOTIFY messages generated by network-initiated re-registration and authorization requests.

Note:

The Oracle Communications Unified Session Manager does not support any PUID barring within the context of GRUU.

The user can verify PUID barring status using the show reg sipd by-user <user> detailed command. Example output is shown below.

ORACLE# show reg sipd by-user user detailed
Registration Cache (Detailed View)    Thu Jul 09 2015  15:16:08
User: sip:user_1@acme-ims.com
  Registered at:  2015-07-09-15:16:04    Surrogate User: false
  Emergency Registration? No                                  
  ContactsPerAor Rejects 0                                    
  ContactsPerAor OverWrites 0                                 

  Contact Information:
    Contact:          
      Name: sip:user_1@acme-ims.com
      Valid: true                    
  
...

    Associated URI(s):
      URI: sip:user_1@acme-ims.com
      Status: Barred

...

Note:

The Oracle Communications Unified Session Manager replicates barred status for PUIDs to standby systems.