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.

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

Relevant specifications

  • 3GPP TS 23.292 and 24.292

  • GSMA IR.64.

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 InitialDP (IDP)

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..

Session output variables

Variable name Type Comment
Reoriginated

Boolean

Set to true if the feature finds reorigination data

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

AccessNetworkInfoFound

AccessNetworkInfo was found in the original InitialDP

AccessNetworkInfoNotFound

AccessNetworkInfo could not be found in the original InitialDP

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 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:

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>. 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 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:

Flag Value Effect

TRUE

Use the value in DirectRoutingURI from network configuration.

FALSE

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

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.

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

Request-URI

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

To

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

History-Info

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

P-Asserted-Identity

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

Privacy

Set to id if the original IDP CallingPartyNumber presentation parameter value is RESTRICTED or NETWORK_RESTRICTED.

Route

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.

P-Access-Network-Info

In case of originating Initial DP argument containing suitable location information, the feature sets this header in the form of 3GPP-GERAN;cgi=3gpp=<mcc><mnc><location area code><cellId>

P-Visited-Network-Info

Set to a Visited Network ID if the feature was invoked on an originating trigger.

OC-Term-P-Visited-Network

Set to a Visited Network ID if the feature was invoked on an terminating trigger.

OC-VLR-Number

Set to the VLR address from the correlation data as a VLR Number address in a string.

P-Profile-Key

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

Note 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', which states:

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).

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

Formatting of the OC-Term-P-Visited-Network header

This header has the same format as a P-Visited-Network-Info header.

Previous page Next page
Sentinel VoLTE Version 3.0.0