|
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.
|
For this feature’s fit into the overall flow, please see the Reorigination basic flow diagram. |
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 |
SipAccess_SessionAccept |
Yes |
No |
Stateless |
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 |
|---|---|---|
Reoriginated |
Boolean |
Set to |
Statistics
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… |
|---|---|
Complete |
The feature ran to completion |
MultipleHistoryInfoHeadersFound |
Multiple history-info headers found on the INVITE |
NoHistoryInfoHeaderFound |
No history-info header found on the INVITE |
OneHistoryInfoHeaderFoundAndRemoved |
One history-info header found on the INVITE and removed |
HSSLookupFailed |
HSS lookup failed |
HSSLookupSuccess |
HSS lookup succeeded |
HSSLookupSkipped |
HSS lookup was skipped due to SkipHSSLookup feature configuration flag |
CorrelationRaQueried |
Correlation RA was queried for the call information |
CorrelationRaQuerySuccess |
The Correlation RA query succeeded |
CorrelationRaQueryFailure |
The Correlation RA query failed |
FailedToDecodeCorrelationData |
Failed to decode the correlation data into an OriginationRequest or AnalyzedInformation object |
SetOCBillingIdHeader |
Added a OCBillingId header with the BillingID from the OriginationRequest or AnalyzedInformation |
CalledPartyNumberNotFound |
Failed to determine the called party from parameters of the OriginationRequest or AnalyzedInformation |
SCSCFAddressNotFound |
The SCSCF could not be found in configuration, or retrieved from the HSS |
CallingPartyAndPaiDoNotMatch |
The request is rejected because of a mismatch between calling party and P-Asserted-Identity |
Started |
The feature starts |
FailedToStart |
The feature failed to start due to an error |
IssuedWarning |
The feature raised a warning |
FailedDuringExecution |
The feature failed due to a major error |
TimedOut |
The feature timed out during execution |
Behaviour
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 |
|
If it is not present in the |
|
Set to |
|
A new route to the S-CSCF for the served user is added, if the feature was invoked on an originating trigger an |
|
The |
|
If such header exists in the |
|
|
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.
|
