Wildcard Public User Identity (PUI)

The Oracle Communications Session Border Controller supports wildcard Public User Identies (PUI). This capability is most often used to streamline processing of REGISTER and INVITE messages between a PBX and an IMS core.

The HSS (Home Subscriber Server, an IMS network-wide database) is pre-provisioned with the extension numbers associated with the PBX’s base telephone number. When the PBX registers its own base telephone number with the S-CSCF, that server downloads a wildcarded PUI -- a regular expression that describes all extension numbers associated with the registering PBX

The S-CSCF returns the wildcarded PUI in the 200 OK response to the REGISTER message. Upon receiving the 200 OK, the SBC (acing in the P-CSCF role) uses the wildcarded PUI to construct a registration cache entry to implicitly treat subsequent INVITEs from PBXs extensions that match the wildcard as registered endpoints.

A wildcarded PUI consists of a delimited regular expression located either in the user info portion of the SIP URI or in the telephone-subscriber portion of the Tel URI. The regular expression takes the form of an Extended Regular Expressions (ERE) as defined in chapter 9 of The Single UNIX Specification (IEEE 1003.1-2004 Part 1). The exclamation mark (!) serves as the delimiter.

For example, the following PUIs will match to the wildcard ERE "sip:chatlist!.*!@example.com".

sip:chatlist1@example.com
sip:chatlist2@example.com
sip:chatlist42@example.com
sip:chatlistAbC@example.com
sip:chatlist!1@example.com

In addition to the ability of the P-CSCF to recognize and parse a wildcarded PUI, The P-CSCF must also support the PATH and P-Profile-Key SIP headers.

Path Header

The Path header is defined in RFC 3327, Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts. The Path header enables the accumulation and transfer of a list of proxies between a SIP UA and a REGISTER. Its operation is very similar to the Record-Route header in dialog initiating request. Within the context of support for wildcarded PUIs, the Path header is used to ensure that REGISTER responses containing an wildcard ERE transit the P-CSCF, thus enabling the implicit registration of PBX extensions.

P-Profile-Key Header

The P-Profile-Key header is defined in RFC 5002, The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header).If the identity of the server user of the request was via a wildcarded PUI, that wildcarded PUI is included in the P-Profile-Key header in the outgoing request to the core. This Header will be included for requests like INVITE, SUBSCRIBE, and so on that match the registered wildcarded PUI. The header will occur in all subsequent requests to the core as well.

For this header to be present, the request needs to be going from access to core and the ims-feature must be enabled on both the access and core SIP interfaces.

Registration Event Package

If subscription to the Registration Event package (defined in RFC 3680, A Session Initiation Protocol (SIP) Event Package for Registrations) is enabled, the P-CSCF receives asynchronous NOTIFYs from the core reporting registration state changes. Each NOTIFY provides a </reg-info> XML element that reports state changes. A sample XML report is shown below.

   <registration aor="sip:user1_public1@home1.net" id="as10" state="active">

          <contact id="86" state="active" event="created">
               <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
          </contact>

   </registration>



   <registration aor="sip:ep_user1@home1.net" id="as11" state="active">

          <contact id="86" state="active" event="created">
               <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
          </contact>


          <ere:wildcardedIdentity>sip:ep_user!.*!@home1.net</ere:wildcardedIdentity>

   </registration>

</reginfo>

If a </wildcardedIdentity> sub-element is included in the <registration> element (as in the second </registration>, the wildcarded PUI is taken from the </wildcardedIdentity> sub-element, and that wildcarded PUI replaces any previously stored wildcarded PUIs in the registration.

In the absence of </wildcardedIdentity> sub-element(as in the first registration), the PUI is taken from the ‘aor’ attribute of the registration element, and the registration cache is left unchanged.

Message Flows

A basic registration exchange with support for PUIs enabled.

From UA to P-CSCF

REGISTER sip:192.168.1.232:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.231:5060;branch=z9hG4bK-13794-1-0
From: <sip:7818888@hxu.com;tag=1
To: sut <sip:7818888@hxu.com>
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888@192.168.1.231:5060>;expires=3600
Content-Length: 0

From P-CSCF to Registrar

If reg-cache-route is enabled on egress sip-interface, P-CSCF provides Path support with a value of P-CSCF-contact, so INVITE from core will have route header with value of this path per RFC 3327.

REGISTER sip:192.168.200.231:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.232:5060;branch=z9hG4bK0g6tnu200o10tfgl0641.1
From: <sip:7818888@hxu.com;tag=1
To: sut <sip:7818888@hxu.com>
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888-rrbgth3ot667c@192.168.200.232:5060;transport=udp>;expires=3600
Content-Length: 0
Supported: path
Path: <sip:7818888-rrbgth3ot667c@192.168.200.232:5060; lr>
Max-Forwards: 70

From Registrar to P-CSCF

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.200.232:5060;branch=z9hG4bK0g6tnu200o10tfgl0641.1
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888-rrbgth3ot667c@192.168.200.232:5060;transport=udp>;expires=3600
P-Associated-URI: <sip:781!.*!@hxu.com>  -- wildcard regex
Content-Length: 0

From P-CSCF to UA

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.231:5060;branch=z9hG4bK-13794-1-0
From: <sip:7818888@hxu.com;tag=1
To: sut <sip:7818888@hxu.com>;tag=1
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888@192.168.1.231:5060>;expires=3600
P-Associated-URI: <sip:781!.*!@hxu.com>
Content-Length: 0

Incoming Request INVITE from core

For the incoming request from the core to the P-CSCF, if reg-cache-route is enabled on ingress SIP Interface, P-CSCF checks the registered P-CSCF-contact-URI in the top Route P-CSCF-contact-URI, instead of with request-URI.

INVITE sip:7816666@192.168.200.232:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.231:5060;branch=z9hG4bK-13800-1-0
From: sipp <sip:3054252165@192.168.200.231:5060;user=phone>;tag=1
To: sut <sip:7816666@hxu.com>
Call-ID: 1-13800@192.168.200.231
Supported: 100rel,timer,resource-priority,replaces
CSeq: 1 INVITE
Contact: sip:7816666@192.168.200.231:5060
Max-Forwards: 70
Route: <sip:7818888-rrbgth3ot667c@192.168.200.232:5060;lr>
Content-Type: application/sdp
Content-Length:  141

v=0^M
o=user1 53655765 2353687637 IN IP4 192.168.200.231
s=-
c=IN IP4 192.168.200.231
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

outgoing Request INVITE

For outgoing Request from access side, the Register Cache entry will be found by reg-via-key, when options ‘reg-via-key’ and ‘reg-via-match’ are set, P-CSCF will have wildcarded PAU checking for allow-anonymous (or registered) verification if option wildcard-puid-match is set.

INVITE sip:service@192.168.1.232:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.231:5060;branch=z9hG4bK-11911-1-0
From: sipp <sip:7816666@hxu.com>;tag=1
To: sut <sip:service@192.168.1.232:5060>
Call-ID: 1-11911@192.168.1.231
Supported: 100rel,timer,resource-priority,replaces
CSeq: 1 INVITE
Contact: sip:781666@192.168.1.231:5060
Max-Forwards: 70
Content-Type: application/sdp
Content-Length:  137

v=0
o=user1 53655765 2353687637 IN IP4 192.168.1.231
s=-
c=IN IP4 192.168.1.231
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

HA Configurations

Support for wildcarded PUIs requires checkpointing two new data points that need to be replicated in HA configurations.

the P-Profile-Key in the sip session so that subsequent requests in a session can take the cached value and include that value in egress requests to core
Upon SUB-NOT-200OK, the active P-CSCF replicates the subscribe session to the standby. This information is required to replicate the new PAU list of the associated SIP User if the </wildcardedIdentity> element arrives in the NOTIFY XML and has wildcarded entities.