This page describes the information shared by components that implement reorigination for GSM and CDMA networks .
For GSM networks:
For CDMA networks:
-
CDMA Reorigination service and SCCCDMAReOrigination feature
These components use:
-
shared network operation configuration, and
-
a shared Correlation RA entity for reorigination information.
Network operator configuration
Network configuration data is stored in a JSLEE configuration profile table named SCCCommonReOriginationConfigProfileTable.
| Attribute name | Type | Comments |
|---|---|---|
UsePrefix |
boolean |
If set to true, prepends |
NetworkPrefix |
String |
See |
SkipHSSLookup |
boolean |
This decides whether the SIP feature will do a query to the HSS for the S-CSCF address or not |
DirectRoutingURI |
String |
The value to use for the address to add to the route header that will be added to the INVITE after it has been reoriginated. |
GeneratedPVNITemplate |
String |
A template string for the P-Visited-Network-Information header generated in the reorigination, where |
PoliceOriginatingRequests |
boolean |
Police incoming originating requests, and reject attempts to hijack the call. Enabled by default. |
(CAMEL Only) Visited Network ID Address List
Both the IN and SIP Reorigination features, in a GSM deployment, make use of an address list for mapping a given VLR address to a Visited Network ID. This is used as a fallback if the InitialDP does not contain suitable location information.
The SIP feature uses this address list in order to populate headers on the outgoing INVITE message. The IN feature uses the address list purely as an early failure measure. It checks that there exists a matching Visited Network ID for the VLR address; this prevents network resources from being wasted establishing a SIP dialog that will ultimately fail at the SIP Reorigination feature anyway.
|
Currently, we require that the VLR address’s nature is International and its numbering plan is ISDN.
|
There are two profile tables associated with this address list:
-
<PlatformOperatorName>_SCCReorigination_AddressListConfigurationTable
-
<PlatformOperatorName>_SCCReorigination_AddressListEntryTable
The configuration table is a standard address list configuration table, see Address List Configuration Profile
for more information. The list entry table is an extended version of the standard address list entry table (details
here: Address List Entry Profile)
with one additional field, a String called VisitedNetworkId. Profiles in this table must use a standard format for their
names, made up of three fields: the Sentinel Selection Key,
a fixed String VisitedNetworks, and the VLR address prefix to be matched when searching for a Visited Network ID.
The name should be formatted like this:
-
<SelectionKey>:VisitedNetworks:<AddressPrefix>
Here’s an example:
-
OpenCloud:OpenCloud::::VisitedNetworks:6421
See the respective behaviour sections of the IN and SIP Reorigination feature pages for details on how each feature uses the address list.
For an overview of how address lists work in general, see: Address Lists.
|
|
We recommend that the visited network is formatted according to GSMA IR.65 section 6.2.1. I.e. is of the format epc.ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org or ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org, depending on the version used |
Use of the Correlation RA
The IN feature/CDMA reorigination service and their SIP counterparts share (and communicate) correlation information through
the Correlation RA. The resource adaptor entity used has the resource-adaptor-entity-link name sentinel-correlation-reorigination.
|
|
See Correlation Resource Adaptor for more information about the correlation RA. |
The reorigination addresses allocated by the Correlation RA must route through to the IMS, and allow the I-CSCF to trigger the SCC-AS. Typically this is done by configuring a range of numbers that correspond to one or more IMS public service identifiers.
The sentinel-correlation-reorigination RA entity has one or more correlation ID pools.
-
a default ID pool (optional)
-
a set of named ID pools.
Choosing the Correlation ID Pool
Each named ID pool is identified by the NodeID and a set of prefixes for choosing/selecting the ID pool. From the Correlation RA standpoint, the prefixes can be any address string. The client to the RA provides an address that the RA uses:
In GSM Volte, the IN reorigination feature uses the MobileCountryCode extracted from LocationInformation in the triggering InitialDP
In CDMA Volte, the CDMA reorigination service uses the LocationAreaID extracted from the OriginationRequest or AnalyzedInformation
The Correlation RA performs a longestPrefix match address list search on pools with a matching NodeID for the current node. If no pool is matched by the search or no address is provided by the client to the RA, then the default pool is selected. If multiple pools match the longestPrefix address list search, the first pool in the result set is selected.
Reorigination basic flow
The following diagrams cover some basic reorigination scenarios for GSM and CDMA networks.
GSM Reorigination Scenario 1
In the following diagram:
-
Sentinel VoLTE acts as the SCC-AS.
-
The “IN feature” is the SCCCamelToIMSReOriginationIN feature.
-
The “SIP feature” is the SCCCamelToIMSReOriginationSIP feature.
-
The User-Data-Request and Answer will not occur if the SkipHSSLookup flag is set to true and instead the value in the DirectRoutingURI will be used.
This flow diagram shows a configuration where the SkipHSSLookup flag is set to false, so that the SCC-AS looks up the HSS and acts as a B2BUA between the I-CSCF and the S-CSCF after B number restoration.
GSM Reorigination Scenario 2
As a variation to the above diagram, the following shows the effect of configuring:
-
SkipHSSLookup flag set to true
-
DirectRoutingURI set to the I-CSCF
CDMA Reorigination Scenario
In the following diagram:
-
Sentinel VoLTE acts as the SCC-AS.
-
The “CDMA Service” is the CDMA ReOrigination service.
-
The “SIP feature” is the SCCCDMAReOrigination feature.
-
The User-Data-Request and Answer will not occur if the SkipHSSLookup flag is set to true and instead the value in the DirectRoutingURI will be used.
This flow diagram shows a configuration where:
-
SkipHSSLookup flag set to true
-
DirectRoutingURI set to the I-CSCF
For further information related to headers set in the outgoing SIP INVITE, please refer to SIP headers in the outgoing INVITE.
