Temporary Public User Identities and Multi-SIM Scenarios
The Oracle Communications Session Border Controller’s SIP interface supports multiple registered users for the same P-Asserted-Uri (PAU), a useful ability for multi-SIM scenarios. The call flow for this type of scenario differs depending on whether or not you configure the SIP interface facing the UE with the reg-via-key and reg-via-match options.
In a multi-SIM scenario, the UE derives a temporary IMS public identity (IMPU); that UE then registers with the Oracle Communications Session Border Controller using the IMPU as the address of record (AoR) from a unique IP. The S-CSCF returns a PAU in the 200 OK, which the Oracle Communications Session Border Controller caches. The UE then derives another IMPU; it registers with the Oracle Communications Session Border Controller using that IMPU as the AoR from another unique IP. The S-CSCF again returns the same PAU in the 200OK.
Old Behavior
Before the introduction of this change, the Oracle Communications Session Border Controller (SBC) associated the PAU only with the first IMPU request. The SBC considered any request made from that PAU to be a request from the first user, regardless of the request’s originating IP.
![Depicts a PAU assigned to first user instead of originating IP. Depicts a PAU assigned to first user instead of originating IP.](img/1874_oldbehavior1a.gif)
When the SIP interface facing the UE had the reg-via-key and reg-via-match options configured, the SBC rejected the request from the second user with the PAU as the From or the PPI. Because it only associates the PAU with the first user, the SBC issued a 403 message.
![Depicts a PAU assigned to first user instead of originating IP and the call failing due to OCSBC configuration. Depicts a PAU assigned to first user instead of originating IP and the call failing due to OCSBC configuration.](img/1874_oldbehavior2a.gif)
New Behavior
Your Oracle Communications Session Border Controller (SBC) now associates the PAU with both the first and second IMPU. The SBC considers any request made from that PAU to be a request from the user at the top of its registration cache table irrespective of where the request originated (the IP).
![Depicts a PAU assigned to first user instead of originating IP. Depicts a PAU assigned to first user instead of originating IP.](img/1874_newbehavior1a.gif)
When the SIP interface facing the UE has the reg-via-key and reg-via-match options configured, and the request from the user with the PAU as the From or with PPI, the Oracle Communications Session Border Controllermatches to the proper user based on the source IP.
![Depicts a PAU assigned to user based on source IP and the call succeeding due to OCSBC configuration. Depicts a PAU assigned to user based on source IP and the call succeeding due to OCSBC configuration.](img/1874_newbehavior2a.gif)
Configuring SIP Interface with reg-via-key and reg-via-match
If you do not want the use the call scenario associated with the SIP interface options in the New Behavior section, you do not need to make any change to your configuration.
If you want your call scenarios to resemble the one associated with the SIP interface options in the New Behavior section, then you need to configure reg-via-key and reg-via-match options on the SIP interface facing the UE.
To configure a SIP interface with the reg-via-key and reg-via-match options: