Prerequisite Features

Session Input Variables

Variable name Type Description 
PreviousRegistrationData
 
List<RegistrationRecord>

The list of active registration records for the current subscriber and call ID.

Session Output Variables

Variable name Type Description 
CurrentATUSTI
 
String

ATU-STI to be stored in the third-party registrar database.

 
AtcfMgmtUri
 
String

ATCF Management URI to be stored in the third-party registrar database.

 
AtcfPathUri
 
String

ATCF Path URI to be stored in the third-party registrar database.

 
StnSr
 
String

STN-SR to be stored in the third-party registrar database.

Statistics

ESRVCCReregistration statistics are tracked by the sentinel.registrar SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.registrar service → sentinel.volte.sip SBB → feature → ESRVCCReregistration
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.registrar,vendor=OpenCloud,version=3.1.0].SbbID[name=sentinel.registrar,vendor=OpenCloud,version=3.1.0].feature.ESRVCCReregistration"

Name Incremented when…​

Started

The feature is invoked (initial invocation only, not subsequent event triggers).

FailedDuringExecution

The feature fails during execution due to an internal FeatureError.

IssuedWarning

The feature issues a warning message.

FailedToStart

A fatal error occurs before feature execution

TimedOut

Feature execution does not complete within a reasonable time frame

ATCFUpdateRequestSent

A MESSAGE request is sent to the ATCF.

ATCFUpdateFailed

The MESSAGE request fails.

ATCFUpdateSucceeded

The MESSAGE request succeeds.

Configuration

The ESRVCCReregistration feature does not have its own configuration, however it does depend on the Registrar Configuration Table to determine the currently configured value for the ATU-STI, and the length of time to wait for a response from the ATCF (AtcfUpdateTimeout).

Behaviour

The primary function of this feature is to ensure the ATCF will trigger the correct SCC-AS during ESRVCC access transfer. This is may be necessary if re-registrations are sent to an SCC-AS node with a different ATU-STI than the initial (or previous) registration’s ATU-STI.

REGISTER trigger

The feature is triggered when the registration session type is determined to be ESRVCCRegistration and the registration action type is determined to be re_register.

The feature first checks the previous registration data provided by the FetchPreviousRegistrationData feature, searching for a registration record that includes all required ESRVCC registration information. If a record is found, the feature will load the ESRVCC specific data from the record and compare the ATU-STI value in that data to the currently configured ATU-STI for the SCC AS. If no previous ESRVCC registration data can be found, or only partial information can be found, the feature terminates with a FeatureError, and no other action is taken.

If the currently configured ATU-STI matches the one in the previous registration record, the feature will have nothing left to do and will terminate normally. If there is a mismatch, the feature will begin the procedure for updating the ATU-STI in the ATCF to match the currently configured value.

The feature starts the update procedure by attempting to generate a SIP MESSAGE request towards the ATCF Management URI. The request will have an XML body containing the updated ATU-STI, the ATCF Path URI and the subscriber’s C-MSISDN:

<?xml version="1.0" encoding="UTF-8"?>
<SRVCC-infos>
    <SRVCC-info ATCF-Path-URI="<sip:atcf@atcf.example.net:5560>">
        <ATU-STI>sip:scc-as.example.net:5060</ATU-STI>
        <C-MSISDN>tel:+16505550425</C-MSISDN>
    </SRVCC-info>
</SRVCC-infos>
Tip the ATCF Path URI, the C-MSISDN and the ATCF Management URI will all be taken from the initial REGISTER request for the subscriber NOT the current re-REGISTER request (though in practice these values should be identical).

Once the MESSAGE request is ready the feature will trigger the request to be sent, and attach to the Activity Context Interface (ACI) for the resulting SIP session. The feature will then terminate and await a response.

Response Event Triggers

Any one of three events can trigger the feature at this point: a SIP success response, and SIP error response, or a SIP timeout.

Tip In all of these cases, when triggered the feature will check that the triggering ACI matches the ACI that was created when the MESSAGE request was sent. If there is a mismatch, the feature will log a warning and return to waiting for the correct trigger.

SIP Success Response

If the ATCF replies to the MESSAGE request with a SIP 200 OK response, then the update was successful and the feature will update the session data to reflect the new ATU-STI.

SIP Error Response

If the ATCF replies to the MESSAGE request with any SIP error response, the feature will consider the update procedure to have failed and will execute error handling procedures.

SIP Timeout

If the ATCF does not reply to the MESSAGE request within the configured time frame, the feature will consider the update procedure to have failed and will execute error handling procedures.

Tip A timeout will be triggered after a period of time determined by the AtcfUpdateTimeout field on the Registrar Configuration Table; by default this is much faster than a standard SIP timeout.

Error Handling

If the ATCF update procedure fails at any point (be it from an internal FeatureError, a SIP error response, or a SIP timeout) the feature will rewrite the ATU-STI stored in session data to match the ATU-STI of the previous registration. This ensures the third party registrar database contains an accurate representation of the ATU-STI currently in use for the registration in the ATCF.

Previous page Next page
Sentinel VoLTE Version 3.1.0