Tip This feature is for CDMA networks.

This feature is triggered from the I-CSCF and retrieves reorigination information. It retrieves the subscriber’s assigned S-CSCF either from an HSS or from a profile from network configuration and then acts as a B2BUA between the I-CSCF and the subscriber’s assigned S-CSCF .

It is one of two components that enable circuit switched originating calls to be processed in the SCC-AS. The related component is the CDMA ReOrigination Service. These components are part of service centralization in the IMS for CDMA networks.

Note For this feature’s fit into the overall flow, please see the Reorigination basic flow diagram.

Relevant specifications

  • 3GPP2 X.S0042-D v1.0

  • GSMA IR.64.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

SCC signalling anchor B2BUA

From SIP triggering perspective, neither. Mobile Originating and Mobile Terminating determined from saved CDMA OriginationRequest or CDMA AnalyzedInformation





Triggered by the I-CSCF

Network operator data

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

For more information, see the shared configuration between the SCCCDMAReOrigination feature and the CDMA reorigination service.

Use of Correlation resource adaptor

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

Session output variables

Variable name Type Comment


Set to true if the feature finds reorigination data


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

Statistic Incremented when…​


The feature ran to completion


Multiple history-info headers found on the INVITE


No history-info header found on the INVITE


One history-info header found on the INVITE and removed


HSS lookup failed


HSS lookup succeeded


HSS lookup was skipped due to SkipHSSLookup feature configuration flag


Correlation RA was queried for the call information


The Correlation RA query succeeded


The Correlation RA query failed


Failed to decode the correlation data into an OriginationRequest or AnalyzedInformation object


Added a OCBillingId header with the BillingID from the OriginationRequest or AnalyzedInformation


Failed to determine the called party from parameters of the OriginationRequest or AnalyzedInformation


The SCSCF could not be found in configuration, or retrieved from the HSS


The request is rejected because of a mismatch between calling party and P-Asserted-Identity


The feature starts


The feature failed to start due to an error


The feature raised a warning


The feature failed due to a major error


The feature timed out during execution


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 CDMA reorigination service. 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 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 extracted from the ORREQ or ANLYZD. 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:

Flag Value Effect


Use the value in DirectRoutingURI from network configuration.


Do a lookup from the HSS through the Sh Cache Microservice RA and the Sh Cache Microservice.

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

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

SIP headers in the outgoing INVITE

The feature sets or adjusts the following headers in the outgoing INVITE:

Header Name Change


Set to a tel URI with the digits being the original IDP’s called party number digit string (non-BCD encoded).


Set to the original IDP’s called party number digit string (non-BCD encoded).


If only one such header exists on the INVITE, it is removed.


If it is not present in the INVITE it is set to a tel URI using the calling party number from the original IDP.


Set to ONLY_IDENTITY if the original IDP has presentation RESTRICTED or NETWORK_RESTRICTED.


A new route to the S-CSCF for the served user is added, if the feature was invoked on an originating trigger an orig parameter will be included.


The BillingID from the OriginationRequest or AnalyzedInformation.


If such header exists in the INVITE, it is removed.

Note The OC-Billing-ID is a proprietary header created by OpenCloud. The OC-Billing-ID header is added so the original CDMA request can be correlated with the ongoing SIP session when it reaches MMTel.
Previous page Next page
Sentinel VoLTE Version 3.1.0