This feature is triggered from the I-CSCF and retrieves re-origination information; optionally it can retrieve the subscriber’s assigned S-CSCF either from a HSS or from a profile from network configuration, then acts as a B2BUA between the I-CSCF and the subscriber’s assigned S-CSCF .
It is one of two features that enable circuit switched originating calls to be processed in the SCC-AS. The related feature is SCCCamelToIMSReOriginationIN. These features are part of service centralization in the IMS.
|
For this feature’s fit into the overall flow, please see the Re-origination 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 CAMEL IDP |
SipAccess_SessionAccept |
Yes |
No |
Stateless |
Triggered by the I-CSCF |
Network operator data
Network configuration data is stored in a JSLEE configuration profile table named: SCCCamelToIMSReOriginationConfigProfileTable.
The SIP feature shares network operator configuration with the SCCCamelToIMSReOriginationIN feature.
This data is scoped by Sentinel selection key. In other words, each network operator will have one entry in this table.
For more information, please see shared configuration between the IN and SIP feature.
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
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
| 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 |
IdpVlrNumberPresent |
The VLR number is present in the initial IDP |
IdpVlrNumberNotPresent |
The VLR number is not present in the initial IDP |
VisitedNetworkIdFound |
The feature could set the Visited Network Id based on the Location information or on the VLR address |
VisitedNetworkIdNotFound |
The feature could set the Visited Network Id |
IdpCalledPartyNumberPresent |
The initial IDP has a called party number or called party BCD number |
IdpCalledPartyNumberNotPresent |
The initial IDP does not have a called party number or called party BCD number |
SCSCFAddressNotFound |
The SCSCF could not be found in configuration, or retrieved from the HSS |
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 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 in the format epc.ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org, according to IR65 section 6.2.1.
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.
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 RA. |
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.
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 |
|
In case of originating Initial DP argument containing suitable location information, the feature sets this header in the form of |
|
If the feature was invoked on an originating trigger, this is set to the Visited Network ID found in the corresponding to MCC and MNC or from Address List based on the VLR address. |
|
If the feature was invoked on an terminating trigger, this is set to the Visited Network ID found in the corresponding to MCC and MNC or from Address List based on the VLR address. |
|
Set to the VLR address from the correlation data as a VLR Number address in a string. |
|
If such header exists in the |
|
|
The OC-Term-P-Visited-Network and OC-VLR-Number are proprietary headers created by OpenCloud.
|
Formatting of the OC-VLR-Number header
The OC-VLR-Number header value is built by:
-
retrieving the VLR address in the original InitialDP
-
converting the SCCP address into an ascii string, formatted according to SS7’s AddressStringParser
-
setting resulting the string into the SIP header value
The resulting complete header will be
OC-VLR-Number: address=651232343,nature=INTERNATIONAL,numberingPlan=ISDN
