SCCCamelToIMSReOriginationSIP

Common network configuration data is stored in a profile table named SCCCommonReOriginationConfigProfileTable.

For more information, see the shared configuration between the SCCCamelToIMSReOriginationSIP feature and the SCCCamelToIMSReOriginationIN feature.

For information about use of the Correlation RA, please see the shared Correlation RA..

SCCCamelToIMSReOriginationSIP statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → SCCCamelToIMSReOriginationSIP

The feature is triggered on receipt of a SIP INVITE from the I-CSCF.

It checks for network operator data. If not present, the feature informs Sentinel that it failed to execute due to invalid configuration.

It looks at the received INVITE Request URI, and checks that it represents a phone number.

If the network configuration indicates a prefix is in use, it checks that the request URI’s digits start with that prefix. If not, the feature finishes execution without modifying any state. In other words, this is treated as an INVITE that is not for this feature.

The feature then attempts to retrieve the correlation data that was stored by the IN feature. This data is looked up using the request URI’s digits as the key for the correlation data.

If correlation data is not found, the feature finishes execution without modifying any state.

If correlation data is found, the feature tries to extract the Mobile Country Code and the Mobile Network Code from the Cell Global Id or Location Area Id present in the Location Information section of the Initial IDP. If a MCC and MNC is found, a Visited Network Id is created using the GeneratedPVNITemplate in the common configuration. It is recommended that this is set according to IR.65, section 6.2.1 i.e. that the format for this is epc.ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org if the version followed is 12 or less, or ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org if a later version is used.

In the case of originating Initial DP arguments, if a MCC and MNC is found, and the Initial DP includes a Cell Global ID with a Location Area Code, the P-Access-Network-Info header is set to the form 3GPP-GERAN;cgi=3gpp=<mcc><mnc><location area code><cellId>.

If MCC or MNC is not present, the feature uses the Visited Network ID Address List to find the Visited Network ID for the VLR address in the data. If a matching Visited Network ID is found, it is included in a header in the outgoing SIP request. If no matching ID is found then reorigination will be aborted. In practice this should never happen, as the IN reorigination feature performs this check as well and will terminate reorigination before any SIP signalling occurs if no Visited Network ID is found.

If a P-Asserted-Identity header is present on the incoming INVITE, and a phone number can be extracted from it, it is normalised and compared to the (normalised) calling party number from the InitialDP. If they are different, the request is rejected with a 403 response. This functionally can be disabled using the PoliceOriginatingRequests configuration flag.

Next, the feature then retrieves the S-CSCF name for the calling party from either of two places based on the SkipHSSLookup flag:

The feature then adjusts or sets various headers in the outgoing INVITE.

Finally, the SIP Sentinel instance hosting this feature acts as a B2BUA between the I-CSCF and the S-CSCF.