The Reorigination feature is used as a way of handling triggers from roaming subscribers on networks that use CAPv1, or networks that use CAPv2 or CAPv3 but are otherwise determined to be unsupported for direct call control from the VPLMN.
Description
Feature name |
Reorigination |
---|---|
Applicable contexts |
SS7 service |
SAS Support |
No |
Prerequisite Features |
The reorigination capability is needed when:
-
Roaming partners are triggering calls with CAMELv1.
-
Roaming partners are triggering calls with CAPv2, and cannot send the ERB(disconnect) in the same TCAP message as the ACR)(see CAMEL2 issue).
-
The calling party number is lost in the ISUP signalling when traversing an international carrier. In this case Sentinel must store the calling party number and set it in the connect. As setting the calling party number is not supported in CAMEL, this capability requires INAP CS1, CS2, or a proprietary variant. See Noldus[1] section 3.6.3 Short Number Dialling with CLI Guarantee pp.82. Currently not supported in Sentinel.
In these cases, the call is reoriginated to the HPLMN using a pool of special routing numbers. The reoriginated call is re-triggered from the HPLMN MSC.
The Reorigination feature should run at one of the pre credit check feature execution points for both the original InitialDP
and the reoriginated InitialDP
. The Reorigination feature uses the reorigination-correlation-ra to choose the special routing number, and to store data from the original InitialDP
that should be correlated with the reoriginated InitialDP
.
See Correlation Resource Adaptor to understand how the reorigination-correlation-ra works and how it can be configured |
If the dialog should not be reoriginated, or represent a reoriginated dialog, then the Reorigination feature will silently end to allow subsequent features to process the InitialDP .
|
The two phases of roaming reorigination
-
Reoriginating a session. The Reorigination feature analyses the
InitialDP
stored in session state to decide if it should be reoriginated. If the dialog should be reoriginated, then it chooses a free special routing address and routes the call to this special routing address. The reoriginated call may then be re-triggered from the HPLMN MSC
Session state inputs and outputs
Inputs
Name | Type | Format | Description | Behaviour if null/invalid |
---|---|---|---|---|
SentinelSelectionKey |
com.opencloud.sentinel.common.SentinelSelectionKey |
selection key (for example, |
For selecting configuration data |
Report featureCannotStart, featureHasFinished |
InitialDPArg |
com.opencloud.slee.resources.cgin.cap_v1.CAP1InitialDPArg |
InitialDP which triggered this session — CalledPartyBCDNumber may be used in identifying reoriginated calls and may be modified |
Runtime exception to be handled by feature runner |
|
CallType |
com.opencloud.sentinel.common.CallType |
One of: MobileOriginating, MobileTerminating, MobileForwarded, NetworkInitiated, EmergencyCall |
Session type of this call |
Call will not be reoriginated or identified as reoriginated |
RoamingIndicator |
Boolean |
true or false |
Indicates whether this is a roaming call |
Reorigination will not be attempted |
Outputs
Name | Type | Format | Description |
---|---|---|---|
InitialDPArg |
com.opencloud.slee.resources.cgin.cap_v1.CAP1InitialDPArg |
CalledPartyBCDNumber be restored or replaced if the call has or will be reoriginated |
|
RoamingIndicator |
Boolean |
true or false |
Will be set to true if this call is a reoriginated request, otherwise unchanged |
CCConnectArg |
com.opencloud.slee.resources.cgin.cap_v2.CAP2ConnectArg |
The connect arg Sentinel will use if the call is to be reoriginated — not modified otherwise |
Error scenarios
Scenario | Handling |
---|---|
Sessionstate SentinelSelectionKey is null |
Report featureCannotStart |
Invoked for a non CAP dialog |
Report featureIssuedWarning |
No available correlation entries |
Report releaseCallAndCloseDialog |
Could not find a mapper to build the ConnectArg |
Report featureFailedToExecute |
Error retrieving the correlated data to restore InitialDP |
Report releaseCallAndCloseDialog |
Feature responses
Response | Reason |
---|---|
featureCannotStart SessionState |
SentinelSelectionKey is not set |
featureIssuedWarning |
non CAP dialog |
releaseCallAndCloseDialog |
Error while restoring the original Called Party Address address, error while reoriginating: unsupported network, could not find a mapper to build the ConnectArg |
connectAndCloseDialog |
Attempt to trigger reorigination |
featureHasFinished |
feature has finished |
Below are details of the two phases, followed by Call Flow, Configuration, Configuration Profile Naming, and Provisioning Interfaces.
Phase one: reoriginating a session
Reoriginating a session includes these steps:
Determining if a dialog should be reoriginated
The Reorigination feature analyses the InitialDP
to determine if the dialog should be reoriginated. The Reorigination feature checks:
-
if the dialog is for originating treatment. The first
InitialDP
will be triggered on DP2 (Collected Info). Terminating and forwarded dialogs are not reoriginated. -
if the application context is supported. Supported application contexts are:
-
cap_v1_gsmSSF_to_gsmSCF-AC
-
cap-v2-gsmSSF-to-gsmSCF-AC
-
capssf_scfGenericAC (CAP3).
-
-
if the
InitialDP VLR address
is for a roaming party for which reorigination is supported. Roaming partners that do not support theERB(Disconnect)
+ACH
guarantee are listed in a reorigination configuration table which includes the VLR addresses of the operator. The Reorigination service determines if the VLR address is present in the table, and if so triggers reorigination.
Processing a reoriginated session
If a session is to be reoriginated, the feature uses the Correlation RA to:
-
get an ID that is used to route the call to
-
associate some data with the correlation ID that can be used when the dialog is reoriginated.
The important steps are:
-
Create the address we will use to select an id-pool.
-
Create the data that we will associate with the correlation ID.
-
Get a new correlation entry (passing the address and correlation data).
-
Construct the outgoing connect arg.
Step one is achieved with a Mapper. The Reorigination feature looks for a mapper:
// a mapper that takes an {{InitialDP}} and generates a String. final Mapper mapper = mapperLibrary.findMapper(selectionKey, initialDpArg.getClass(), String.class);
Sentinel includes a Mapper for this purpose — CAPInitialDPToCorrelationIdPoolAddress
— that returns the MCC from location information in the InitialDP.
An alternative mapper that uses a different method for choosing an address to choose the id-pool can be written using the Sentinel SDK. |
Step two is achieved with a Mapper. The Reorigination feature looks for a mapper:
// a mapper that takes an {{InitialDP}} and generates a {{byte\[\]}}. final Mapper mapper = mapperLibrary.findMapper(selectionKey, cap1IdpArg.getClass(), byte[].class);
Sentinel includes a Mapper for this purpose, (CAPInitialDPArgToCorrelationData), that:
-
creates a new
CAP1InitialDPArg
object -
copies the called party bcd number to the new cap 1
InitialDP
-
copies the bearer capability (if present) to the new cap 1
InitialDP
-
copies the redirecting party ID (if present) to the new cap 1
InitialDP
-
copies the redirection information (if present) to the new cap 1
InitialDP
-
copies the location information (if present) to the new cap 1
InitialDP
-
copies the extensions (if present) to the new cap 1
InitialDP
-
uses CGIN persist factory to turn this
CAP1InitialDP → byte[]
.
An alternative mapper that uses a different method for building the correlated data to be associated with the correlation ID can be written using the Sentinel SDK.
Step four uses a configuration profile selected from the ReoriginationConfigProfileTable to construct a new DRA, and a Mapper from the trigger class (for example, Cap2InitialDPArg) to a ConnectArg, to map it to an outgoing connect arg.
|
Phase two: receiving a reoriginated trigger
Receiving a reoriginated trigger includes these steps:
Determining if a dialog has been reoriginated
The reorigination feature analyses the InitialDP
to determine whether the dialog is a reoriginated dialog; if:
-
The reoriginated InitialDP will be triggered on DP3 (Analyzed Info).
-
The application context is supported. Supported application contexts are:
-
cap-v2-gsmSSF-to-gsmSCF-AC
-
capssf_scfGenericAC (CAP3).
-
-
The called party is a special routing number.
See Correlation Resource Adaptor to understand how the Correlation resource adaptor works and how it can be queried to see if the called party is a special routing number. |
Processing a reoriginated trigger
If this session corresponds is a reoriginated trigger:
-
use the correlation ID (the called party number) to get the correlated data from the Correlation RA
-
restore fields from the original
InitialDP
(that is stored in the correlation data) into the reoriginated InitialDP.
This is achieved with a mapper. The reorigination feature looks for a mapper:
// a mapper that takes a {{byte\[\]}} and returns a {{CAP1InitialDPArg}} final Mapper mapper = mapperLibrary.findMapper(selectionKey, byte[].class, CAP1InitialDPArg.class);
Sentinel core bundles a mapper for this purpose (CorrelationDataToCAPInitialDP) that:
-
uses CGIN persist factory to turn this byte[] into a
CAP1InitialDPArg
object -
copies the cap 1
InitialDP
called party bcd number to the reoriginatedInitialDP
-
copies the cap 1
InitialDP
bearer capability (if present) to the reoriginatedInitialDP
-
copies the cap 1
InitialDP
redirecting party ID (if present) to the reoriginatedInitialDP
-
copies the cap 1
InitialDP
redirection information (if present) to the reoriginatedInitialDP
-
copies the cap 1
InitialDP
location information (if present) to the reoriginatedInitialDP
-
copies the cap 1
InitialDP
extensions (if present) to the reoriginatedInitialDP
-
sets the
InitialDP
session state field with the updated reoriginatedInitialDP
.
An alternative mapper that uses a different method for reconstructing the correlated data associated with the correlation ID can be written using the Sentinel SDK. |
The mapper used to reconstruct the correlated data and update the reoriginated InitialDP should be thought of as the mirror to the mapper used in step two for processing the original InitialDP. If a custom method for choosing the data to associate with the correlation ID is built with the Sentinel SDK, then two new mappers are needed that:
|
Determining service type in reoriginated dialogs
The Classify Call Scenario Feature may not be able to correctly determine that a reoriginated dialog is roaming. To ensure that the roaming indicator is set correctly, the Reorigination service must set the service type to isRoaming.
Configuration
Correlation RA configuration
See Correlation Resource Adaptor to understand how the correlation resource adaptor works and how it can be configured. |
Feature configuration
A configuration profile table is used to configure the parameters of the new DRA sent out in the first connect (Phase 1).
Parameter | Type | Description |
---|---|---|
Nature |
The address nature |
|
NumberingPlan |
The numbering plan of the address |
|
RoutingToInternalNetworkNumber |
either ALLOWED or NOT_ALLOWED |
Address list configuration
A VLR address list table is maintained, for the service to identify roaming partners requiring reorigination. A VLR address entry is an extension of the standard Address list entry, the addition being a listing of the set of supported application contexts:
Parameter | Type | Description |
---|---|---|
OriginatingContextNames |
String[] |
Array of context names: cap_v1_gsmSSF_to_gsmSCF_AC, cap_v2_gsmSSF_to_gsmSCF_AC, capssf_scfGenericAC |
Configuration profile naming
Configuration Profile Table Name | Description | Profile Naming |
---|---|---|
${PLATFORMOPERATOR}_Reorigination_AddressListConfigurationTable |
Address list configuration |
${SELECTIONKEY}:Reorigination:VLRAddressList |
${PLATFORMOPERATOR}_Reorigination_AddressListEntryProfileTable |
Feature specific Address List entry table |
${SELECTIONKEY}:Reorigination:VLRAddressList:${ADDRESS} |
ReoriginationConfigProfileTable |
new DRA parameters |
${SELECTIONKEY} (for example, |
ReoriginationCorrelationIdPools |
Sets of reorigination numbers |
Arbitrary eg Pool-1, however must include at least one profile named DEFAULT |
CorrelationConfigTable |
reorigination-correlation-ra configuration |
ReoriginationCorrelationConfigProfile — can be redefined in the reorigination-correlation-ra configuration properties |
Provisioning interfaces
The feature is provisioned using the web interface.