Network operator configuration

Network configuration data is stored in a JSLEE configuration profile table named SCCCamelToIMSReOriginationConfigProfileTable.

Attribute name Type Comments
UsePrefix

boolean

NetworkPrefix

string

RoutingToInternalNetworkNumber

Used by the IN feature when forwarding the call. For allowed values, see RoutingToInternalNetworkNumber

Nature

An enum. See Nature

Used by the IN feature when forwarding the call. For allowed values see Nature.

NumberingPlan

An enum. See NumberingPlan

Used by the IN feature when forwarding the call. For allowed values see NumberingPlan

OriginHost

string

The value to use for the OriginHost AVP when communicating to the HSS. Used by the SIP feature*

OriginRealm

string

The value to use for the OriginRealm AVP when communicating with the HSS. Used by the SIP feature* when retrieving the S-CSCF name for the subscriber

DestinationHost

string

The value to use for the DestinationHost AVP when communicating with the HSS. Used by the SIP feature* when retrieving the S-CSCF name for the subscriber

DestinationRealm

string

The value to use for the DestinationRealm AVP when communicating with the HSS. Used by the SIP feature* when retrieving the S-CSCF name for the subscriber

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 re-originated.

* Not currently used by the feature. Uses default Sh-Cache settings.

RoutingToInternalNetworkNumber

This value is part of the CAP and ETSI INAP CalledPartyNumber.

The allowed values are:

  • ALLOWED

  • NOT_ALLOWED

The values are as if the type were specified in ASN.1 as follows:

RoutingToInternalNetworkNumber ::= ENUMERATED {
     ALLOWED     (0),
     NOT_ALLOWED (1)
 }

For more information, please see OpenCloud’s CGIN.

Nature

This value is part of the CAP and ETSI INAP CalledPartyNumber. The allowed values are:

  • SUBSCRIBER

  • UNKNOWN

  • NATIONAL

  • INTERNATIONAL

  • NETWORK_SPECIFIC

  • NETWORK_ROUTING_NATIONAL

  • NETWORK_ROUTING_NETWORK_SPECIFIC

  • NETWORK_ROUTING_WITH_CALLED_DIRECTORY

The values are as if the type were specified in ASN.1 as follows:

Nature ::= ENUMERATED {
     ... ,
     SUBSCRIBER                            (1),
     UNKNOWN                               (2),
     NATIONAL                              (3),
     INTERNATIONAL                         (4),
     NETWORK_SPECIFIC                      (5),
     NETWORK_ROUTING_NATIONAL              (6),
     NETWORK_ROUTING_NETWORK_SPECIFIC      (7),
     NETWORK_ROUTING_WITH_CALLED_DIRECTORY (8),
     ...
 }

For more information, please see OpenCloud’s CGIN.

NumberingPlan

This value is part of the CAP and ETSI INAP CalledPartyNumber.

The allowed values are:

  • SPARE_0

  • ISDN

  • SPARE_2

  • DATA

  • TELEX

  • NATIONAL_5

  • NATIONAL_6

  • SPARE_7

The values are as if the type were specified in ASN.1 as follows:

NumberingPlan ::= ENUMERATED {
     SPARE_0      (0),
     ISDN         (1),
     SPARE_2      (2),
     DATA         (3),
     TELEX        (4),
     NATIONAL_5   (5),
     NATIONAL_6   (6),
     SPARE_7      (7)
 }

For more information, please see OpenCloud’s CGIN.

Visited Network ID Address List

Both the IN and SIP Reorigination features 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

Use of the Correlation RA

Both the IN feature and SIP feature share (and communicate) correlation information through the Correlation RA. The resource adaptor entity is specified using the resource-adaptor-entity-link name of sentinel-correlation-reorigination.

The re-origination 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.

Re-origination basic flow

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

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

  1. SkipHSSLookup flag set to true

  2. DirectRoutingURI set to the I-CSCF

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 2.7.0