This page describes the information shared by components that implement reorigination for GSM and CDMA networks .

For GSM networks:

For CDMA networks:

These components use:

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 to the correlation IDs returned by the Correlation RA.

NetworkPrefix

String

See UsePrefix.

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 {mnc} and {mcc} are replaced with the MNC and MCC respectively. IR 65 versions 12 or earlier define this to be epc.ims.mnc{mnc}.mcc{mcc}.3gppnetwork.org, while later versions define this as ims.mnc{mnc}.mcc{mcc}.3gppnetwork.org.

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.

Note 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.

Note 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.

Note 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.

  1. a default ID pool (optional)

  2. 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.

reorig-roaming-detection-use-hss-lookup

GSM Reorigination Scenario 2

As a variation to the above diagram, the following shows the effect of configuring:

  1. SkipHSSLookup flag set to true

  2. DirectRoutingURI set to the I-CSCF

reorig-roaming-detection-skip-hss-lookup

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:

  1. SkipHSSLookup flag set to true

  2. DirectRoutingURI set to the I-CSCF

cdma-reorig-roaming-detection-skip-hss-lookup

For further information related to headers set in the outgoing SIP INVITE, please refer to SIP headers in the outgoing INVITE.

Previous page Next page
Sentinel VoLTE Version 3.1.0