This feature is triggered from the I-CSCF and retrieves reorigination 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.
|
Refer to Reorigination basic flow diagram to understand the role of SCCCamelToIMSReOriginationSIP in reorigination.
|
Feature cheat sheet
| B2BUA Instance | SAS Support | Originating / Terminating | Point in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature |
|---|---|---|---|---|---|---|---|
SCC signalling anchor B2BUA |
Yes |
From SIP triggering perspective, neither. Mobile Originating and Mobile Terminating determined from saved CAMEL |
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 SCCCamelToIMSReOriginationSIP feature and the SCCCamelToIMSReOriginationIN feature.
Use of Correlation resource adaptor
For information about use of the Correlation RA, please see the shared Correlation RA..
Use of Cassandra-CQL resource adaptor
For information about use of the Cassandra-CQL RA, please see storing Call Information in Cassandra.
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 |
NoHistoryInfoHeaderFound |
no history-info header found on the |
OneHistoryInfoHeaderFoundAndRemoved |
One history-info header found on the |
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 |
IdpVlrNumberNotPresent |
The VLR number is not present in the |
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 |
IdpCalledPartyNumberNotPresent |
The |
SCSCFAddressNotFound |
The SCSCF could not be found in configuration, or retrieved from the HSS |
AccessNetworkInfoFound |
AccessNetworkInfo was found in the original |
AccessNetworkInfoNotFound |
AccessNetworkInfo could not be found in the original |
CallingPartyAndPaiDoNotMatch |
The request is rejected because of a mismatch between calling party and P-Asserted-Identity |
CassandraQueried |
Cassandra is queried for call information related to a correlation ID |
CassandraQueryFailed |
There is a failure to execute a cassandra query |
CassandraQueryResultReceived |
A CassandraQueryResult event is received with the result of the Cassandra query for call information |
CassandraQueryErrorReceived |
A CassandraQueryError event is received due to a failure |
CassandraQueryResultMissingData |
A CassandraQueryResult event is received with no call information associated for a correlation ID |
CassandraQueryResultExpired |
A CassandraQueryResult event is received with call information that has expired |
ReleasingCorrelationIdOnRemoteNode |
A SIP MESSAGE has been sent to a remote SCC-AS node to release a correlation ID |
FailedToReleaseCorrelationIdOnRemoteNode |
There was a failure to release a correlation ID on a remote SCC-AS node by sending a SIP MESSAGE |
ReleasedCorrelationIdUsedOnRemoteNode |
A correlation ID has been released in response to a SIP MESSAGE received from a remote SCC-AS node |
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 SCCCamelToIMSReOriginationSIP feature is triggered on receipt of a SIP INVITE, or a SIP UPDATE from the I-CSCF.
The majority of this feature’s functionality is reserved for the INVITE request.
It checks for network operator data. If not present, the feature informs Sentinel that it failed to execute due to invalid configuration.
For a received INVITE request, the following is executed:
The SCCCamelToIMSReOriginationSIP feature checks that the received INVITE Request URI 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 SCCCamelToIMSReOriginationSIP feature then attempts to retrieve the call information data that was stored by the SCCCamelToIMSReOriginationIN feature.
The correlation RA is queried by using the request URI’s digits as the key for the call information data.
The correlation RA query result includes the call information data if it is available on this SCC-AS node.
If the call information is not available on this SCC-AS node, then the SCCCamelToIMSReOriginationSIP feature queries cassandra, using the request URI’s digits as the correlation ID.
|
|
The cassandra query result may return:
|
If valid call information data is not found, the feature finishes execution without modifying any state.
If valid call information data is found, the feature tries to extract the Mobile Country Code (MCC) and the Mobile Network Code (MNC) from the
Cell Global Id or Location Area Id present in the Location Information parameter of the InitialDP.
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. The format is:
|
In the case of originating InitialDP arguments, if an MCC and MNC is found, and the InitialDP 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>.
This header is saved in the session state to correct future outgoing UPDATE requests in the session.
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 SCCCamelToIMSReOriginationIN feature performs this check and terminates reorigination before any SIP signalling occurs if there is no Visited Network ID.
|
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 SCCCamelToIMSReOriginationSIP feature 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 by using the Sh Cache Microservice. |
The feature then sets or adjusts 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.
Releasing a Correlation ID
If the InitialDP and the reoriginated SIP INVITE are received on the same SCC-AS node, then the allocated correlation ID is released
when the call information data is returned by the correlation RA.
If the reoriginated SIP INVITE is received on a different SCC-AS node then the correlation ID is released by sending a SIP MESSAGE to
the SCC-AS node that received the InitialDP, which releases the correlation ID via the correlation RA on that node.
For a received UPDATE request, the following is executed:
The P-Access-Network-Info header that was generated by the INVITE request is set on the UPDATE request.
The other headers on the outgoing UPDATE request are unchanged.
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 `InitialDP’s called party number digit string (non-BCD encoded). |
|
Set to the original `InitialDP’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 |
|
Set to a Visited Network ID if the feature was invoked on an originating trigger. |
|
Set to a Visited Network ID if the feature was invoked on an terminating trigger. |
|
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 P-Access-Network-Info header
The encoding follows 3GPP TS 24.229, in particular section '7.2A.4.3 Additional coding rules for P-Access-Network-Info header'.
The Cell Global Identity is a concatenation of MCC, MNC, LAC and CI … The value of "cgi-3gpp" parameter is therefore coded as a text string as follows: Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and CI (fixed length code of 16 bits using a full hexadecimal representation).
section 7.2A.4.3: 'Additional coding rules for P-Access-Network-Info header'
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
