This feature implements the re-registration procedures for ESRVCC.
Related Features
-
ESRVCCRegistration handles the initial registration procedures for ESRVCC.
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
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 |
IssuedWarning |
The feature issues a warning message. |
ATCFUpdateRequestSent |
A |
ATCFUpdateFailed |
The |
ATCFUpdateSucceeded |
The |
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>
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.
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.
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.