WO2009124439A1

WO2009124439A1 - A serving call session control function failure recovery processing method

Info

Publication number: WO2009124439A1
Application number: PCT/CN2008/072518
Authority: WO
Inventors: 李志军
Original assignee: 中兴通讯股份有限公司
Priority date: 2008-04-11
Filing date: 2008-09-25
Publication date: 2009-10-15
Also published as: CN101448319A; CN101448319B

Abstract

A serving call session control function S-CSCF failure recovery processing method, comprises: after a failure of the S-CSCF which is assigned to a subscriber occurs, the network receives a subscriber related call request, and firstly determines a S-CSCF which is used for performing the failure recovery, namely failure recovery S-CSCF; the failure recovery S-CSCF performs a failure recovery flow, and sends a service assignment request to a home subscriber server HSS; after the HSS receives the service assignment request, it indicates the subscriber's current register status to said failure recovery S-CSCF according to a service assignment response at the time of no subscriber's S-CSCF info information packets existing locally; the failure recovery S-CSCF carries out analysis after receiving the service assignment request, obtains the subscriber's current register status, and triggers the corresponding services according to said register status in the subsequent call processing. The method avoids the service processing chaos resulted from a subscriber's register status misjudgment.

Description

Method for recovering service call session control function failure recovery

Technical field

The present invention relates to the field of communications, and in particular, to a method for improving the fault handling capability of an S-CSCF (Serving-CSCF, Serving Call Session Control Function) in an IP (Internet Protocol) multimedia subsystem. Background technique

The IP Multimedia Core Network Subsystem (IMS) is the core of a new generation of communication networks. Figure 1 depicts the network element entities associated with the present invention in the IMS architecture and their connections. The user equipment (User Equipment, UE for short) 101 represents the terminal device used by the user; the Call Session Control Function (CSCF) is the core network element for controlling the session process, including: proxy call session control function (Proxy) -CSCF, abbreviated as P-CSCF) 102, Interrogating-CSCF (I-CSCF for short) 103, Serving-CSCF (S-CSCF for short) 104; Home Subscriber (Home Subscriber) Server (referred to as HSS) 105 is the main storage server for all data related to users and servers in the IMS; Application Server (AS) 106 is a network element that provides value-added multimedia services.

Between the various network elements shown in FIG. 1, the UE is connected to the P-CSCF through the Gm interface; the P-CSCF,

The I-CSCF and the S-CSCF are interconnected through the Mw interface. The HSS is connected to the I-CSCF and the S-CSCF through the Cx interface, and is connected to the AS through the Sh interface. The S-CSCF passes the ISC (IMS service control). The interface is connected to the AS.

The P-CSCF is used as the ingress network element for the user to access the IMS system. All Session Initiation Protocol (SIP) signaling must pass through the P-CSCF whether it is from the UE or the UE. After the UE is successfully registered in the IMS network, the P-CSCF locally stores the contact address of the UE, the Public User Identity (PUI) of the UE, and the Private User Identity (PVI) of the UE.

The S-CSCF is the core network element of the IMS, located in the home network, and performs session control and registration for the UE. Service. When the UE is in a session, the S-CSCF handles the session state in the network. After the UE successfully registers with the IMS network, the S-CSCF locally saves the network ID of the P-CSCF used by the UE to register with the IMS network, the IP address of the P-CSCF, the contact address of the UE, the public user identity of the UE, the PUI, and the UE. The private user identifier PVI, the user configuration data corresponding to the public user identifier of the UE, and the HSS address or name of the UE registration state are saved.

The HSS is the storage core for all user and server related data in the IMS system. It not only saves user and server related static data, but also saves some dynamic data. After the UE successfully registers with the IMS network, the HSS saves the S-CSCF address or name assigned to the UE.

After the UE is successfully registered, the P-CSCF, the S-CSCF, and the corresponding HSS allocated by the IMS network for the UE constitute a communication link used by the UE for subsequent communication. After the registration is successful, the UE initiates the call process, the UE is called, and the network will use the communication link already allocated for the UE.

In the normal case, after the UE is successfully registered, the communication link allocated by the network to the UE remains unchanged in the subsequent process. This means that once a problem occurs on a link on the link, it will affect the subsequent call and termination procedures of the UE, making the communication not work properly.

Due to the importance of the S-CSCF in the IMS signaling control process, if the S-CSCF fails, the service will not be implemented directly, which seriously affects the user's service experience.

For any UE initiated call or a call directed to the UE, the call control signaling will reach the S-CSCF, and the S-CSCF determines the control flow according to the service configuration; at the same time, the S-CSCF may also receive the call initiated by the AS instead of the UE. In these cases, if the S-CSCF fails, the call flow will be interrupted. Only after waiting for the UE to actively discover the network error and restart the initial registration process can the solution be resolved. The process of the UE actively discovering the network error depends on the time when the UE initiates periodic re-registration. Usually, the time interval will be from several minutes to several tens of minutes. During this period, if another user calls the UE, the call will not be executed normally. And the UE itself will fail if it initiates a call.

In order to solve the above-mentioned service interruption caused by the core network element failure problem and improve the user experience,

The 3GPP (3rd Generation Partnership Project) organized an IMS failure recovery research project to find solutions to failures of core network elements.

Among them, for the S-CSCF failure, the following research results: (A) If the network receives a UE-initiated call, in order to continue the call flow, the S-CSCF in the failure recovery process may be recovered after the previous S-CSCF failure, but the service data is lost; Because the original S-CSCF fails to respond, a new S-CSCF that the network reselects for fault recovery must obtain the user's service configuration data, registration status, P-CSCF allocated to the UE, and UE. IP address and port. In this process, since the call request is initiated by the UE and sent to the S-CSCF through the P-CSCF, the S-CSCF can extract the P-CSCF address information, the address and port information of the UE from the call request for subsequent use.

(B) If the network receives a call directed to the UE, in order to continue the call flow, the S-CSCF in the fault recovery process (same as (A), there are two cases) must also obtain the user's service configuration data, Registration status, P-CSCF assigned to the UE, IP address and port of the UE. However, unlike the case of (A), since the call is sent to the UE by a third party, the S-CSCF cannot obtain the P-CSCF address information, the IP address and the port information of the UE from the call request, and the S-CSCF needs Use this information to send the call to the P-CSCF.

In addition, there is also a case where the AS initiates a call in place of the UE, and the processing situation is similar to (A). In the above (A) and (B), the service configuration data of the user is used to trigger the service logic to determine which network element the next hop of the call flow should be processed; the registration status is used to determine whether the UE is registered or not. Therefore, the normal business process is triggered for the registered user, and the unregistered service flow is triggered for the unregistered user; when the P-CSCF address is for the call to the UE, the S-CSCF needs to know the address, so as to send signaling to the P- CSCF.

In order to solve the problems faced by (A) and (B) above, the existing research uses a backup and recovery solution, as shown in Figure 2, including the following steps:

S201. When the UE performs IMS registration, the S-CSCF backs up the key information stored in the S-CSCF to the HSS.

During the registration process, after the authentication succeeds, the S-CSCF sends a Service Assignment Request (SAR) to the HSS, updates the S-CSCF name, obtains the user's service configuration, and the S-CSCF stores it on itself. Information about the UE registration (including: the network ID of the P-CSCF, the IP address of the P-CSCF, the contact address of the UE, the public user identity of the UE, the private user identity of the UE, etc.) is packaged into an S-CSCF Info The information package is saved to the HSS. S202a, the UE initiates a call; or

S202b, the third party initiates a terminal call of the UE, and the call is sent to the S-CSCF through the I-CSCF;

S203, the network (which may be a network device such as an I-CSCF or a P-CSCF), if an S-CSCF failure is detected, such as a failure of the downtime or an error of the S-CSCF, an error is returned for the S-CSCF, and the S-CSCF may be determined to be faulty. If there is no user data after recovery, the S-CSCF can continue to be used; if the S-CSCF is not responding, then an S-CSCF needs to be reselected, and the S-CSCF can be reselected to perform S-CSCF query to the HSS through the I-CSCF. If the S-CSCF is reselected as the S-CSCF performing the fault recovery, the network forwards the call request to the S-CSCF;

S204: The S-CSCF needs to send the SAR request to the HSS, and the S-CSCF needs to send the SAR request to the HSS, and the S-CSCF Info packet is requested to be backed up by the S-CSCF because it is recovered after the fault or is reselected. - CSCF information packet). After receiving the SAR request, the HSS returns the S-CSCF Info packet of the user service configuration and backup to the S-CSCF through the Service Assignment Answer (SAA) command;

S205: The S-CSCF locally saves the data returned by the HSS, and determines the current registration status of the user.

According to the current regulations, in the foregoing step S204, if the HSS does not return the S-CSCF Info packet in the SAA response, the S-CSCF considers that the current user is unregistered. The S-CSCF needs to determine the current registration status of the user based on the information contained in the SAA response.

S206a, S206b, and the S-CSCF perform a subsequent call processing process according to the acquired user data. In the process, the S-CSCF determines whether to trigger the registration service or trigger the unregistered service according to the determined current registration status of the user. .

The flow shown in Figure 2 describes a fault recovery solution for S-CSCF failures under prior art conditions. In this solution, the existing S-CSCF needs to be extended to enable the S-CSCF to have failover support. In reality, the S-CSCF deployed in a network may have different support for fault recovery. That is to say, there are some cases: Some S-CSCFs do not support fault recovery, others S- CSCF supports failback.

In some cases, there is a backup recovery mechanism currently used for S-CSCF failures. The fixed defect may cause the S-CSCF to incorrectly judge the registration status of the user, thereby erroneously triggering the unregistered service, resulting in confusion of the business process. Summary of the invention

The technical problem to be solved by the present invention is to provide a S-CSCF fault recovery processing method, which can avoid the business processing confusion caused by the user registration state judgment error.

The applicant found through analysis that when the S-CSCF that does not support fault recovery and supports fault recovery works together, the following problems may occur: When the UE performs IMS registration, it is assigned an S- that does not support fault recovery. CSCF1, since the S-CSCF1 does not support failback, the S-CSCF1 does not back up the S-CSCF Info packet to the HSS during the registration process. When a fault occurs, a call is reached, and the network selects an S-CSCF2 that supports fault recovery for the UE. When the S-CSCF2 sends a SAR request to the HSS, the HSS does not return the S-CSCF Info packet, so S- CSCF2 considers the user to be an unregistered user, thereby erroneously triggering an unregistered service.

In order to solve the above technical problem, the present invention provides a service call session control function S-CSCF fault recovery processing method, which includes the following steps:

After the S-CSCF allocated to the user fails, the network receives the call request related to the user, and first determines an S-CSCF for performing fault recovery, which is called a fault recovery S-CSCF;

The fault recovery S-CSCF performs a fault recovery process, and sends a service allocation request to the home subscriber server HSS;

After receiving the service allocation request, the HSS not indicates the S-CSCF info packet of the S-CSCF information of the user locally, and indicates the user to the fault recovery S-CSCF by using a service allocation response. Current registration status;

After the fault recovery S-CSCF receives the service allocation response, the S-CSCF obtains the current registration status of the user, and triggers the corresponding service in the subsequent call processing according to the registration status.

Further, the above method may also have the following features:

When the HSS does not have the S-CSCF info packet of the user locally, the HSS locally checks whether the user has been registered, and returns to the fault recovery S-CSCF through the service allocation response. Information indicating the current registration status of the user;

The failure recovery S-CSCF determines the current registration status of the user according to the information indicating the current registration status of the user according to the service allocation response when there is no S-CSCF info packet in the service allocation response.

Further, the above method may also have the following features:

The HSS returns information indicating the current registration status of the user through the service allocation response; the failure recovery S-CSCF can directly determine the current registration status of the user according to the information.

Further, the above method may also have the following features:

The information indicating the current registration status of the user returned by the HSS is a new parameter dedicated to indicating the current registration status of the user in the service allocation response or a new response value in the existing parameter, and the fault recovery S-CSCF According to the information, the current registration status of the user can be determined; or

The information indicating the current registration status of the user returned by the HSS includes a plurality of parameter values in the service allocation response, and the fault recovery S-CSCF derives the current registration status of the user according to the plurality of parameter values.

Further, the above method may also have the following features:

The HSS does not have the S-CSCF info packet of the user locally, and locally detects that the user is currently registered, and returns information indicating the current registration status of the user through the service allocation response, and the information is Information indicating that the user has registered;

When the failure recovery S-CSCF does not have the S-CSCF info packet in the service allocation response, if it is detected that the service allocation response includes the information indicating that the user is currently registered, it is determined that the user is currently registered. Otherwise it is judged that the user is not currently registered.

Further, the above method may also have the following features:

The HSS returns a message dedicated to indicating that the user is currently registered through the service allocation response; the failure recovery S-CSCF determines that the user is currently registered when the information is included in the service allocation response, and otherwise determines the user. Currently not registered.

Further, the above method may also have the following features: The information that is returned by the HSS indicating that the user is currently registered is a new parameter added in the service allocation response to indicate that the user is currently registered or a new response value in the existing parameter; the fault recovery S-CSCF is directly based on Whether the new parameter or the newly added response value is included in the service allocation response to determine whether the user is currently registered; or

The information returned by the HSS indicating that the user is currently registered includes a plurality of parameter values in the service allocation response; the failure recovery S-CSCF determines the user according to whether the plurality of parameter values are included in the service allocation response. Is it currently registered?

Further, the above method may also have the following features:

The information dedicated to indicating that the user is currently registered is a new processing response value DIAMETER_SUCCESS_USER_ALREADY_ REGISTERED in the service allocation response.

Further, the above method may also have the following features:

After receiving the service allocation request, the HSS indicates the current registration of the user to the fault recovery S-CSCF in the same manner regardless of whether the S-CSCF info packet of the user exists locally or not. status.

Further, the above method may also have the following features:

The fault recovery S-CSCF performs a fault recovery process, and the service allocation request sent to the HSS includes information requesting the HSS to return the current registration status of the user.

Further, the above method may also have the following features:

When the fault recovery S-CSCF continues the subsequent call processing, if the current registration status of the user is the status, the registration service is triggered, and if the current registration status of the user is unregistered, the unregistered service is triggered. The present invention has the following technical effects: In the fault processing flow after the S-CSCF fails, the HSS is judged and returned to the registration state of the user, thereby preventing the S-CSCF from performing the user registration state judgment according to the information in the response result returned by the HSS. The resulting errors can effectively avoid business triggering confusion caused by incorrect registration status. BRIEF abstract 1 is a schematic diagram of a core network element and its connection relationship in an IMS system of the prior art;

2 is a flowchart of a backup recovery scheme used in the prior art to solve the S-CSCF failure; FIG. 3 is a method for determining a user registration state in the S-CSCF failure recovery process according to the first embodiment of the present invention; flow chart.

Preferred embodiment of the invention

After the user successfully registers with the IMS network, the IMS network assigns an S-CSCF to the user (UE). If the S-CSCF fails, no response or loss of user data will directly result in the call not being able to proceed. In the prior art, the information stored in the S-CSCF is packaged into an S-CSCF Info packet and stored in the HSS during the process of the user registering with the IMS. After the S-CSCF fails, the network is terminated. Determining an S-CSCF that can perform a fault recovery process, and the S-CSCF requests the user service configuration data and the S-CSCF Info packet from the HSS to restore the S-CSCF environment previously served for the UE, so that the call process can be successful. carried out.

However, for some reason, the S-CSCF Info packet representing the service environment of the S-CSCF serving the UE is not saved to the HSS when the UE performs the IMS registration, and therefore, the network after the subsequent failure occurs. The specified S-CSCF for performing fault recovery cannot obtain the S-CSCF Info packet, and the method for judging the state of the user according to the existing fault recovery process will cause a mistake in judging the state of the user, that is, the registered judgment is Unregistered, which may trigger unregistered services, causing confusion in business execution.

In response to this drawback, the present invention provides a method for explicitly determining the registration status of a user and returning it to the S-CSCF to avoid possible errors in judgment errors.

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

First embodiment

Figure 3 is an embodiment of the present invention for describing the flow of explicitly detecting the registration status of a user during a failure recovery process.

S301. After the S-CSCF fault occurs, the network receives the call, where the call may be initiated by the UE (that is, initiated by the user), the AS is initiated by the UE, or the third party initiates the UE. The network determines the fault condition of the S-CSCF according to the response condition of the S-CSCF, and determines an S-CSCF that can perform the fault recovery process according to the fault condition;

Here, the S-CSCF that can perform the fault recovery process may be the S-CSCF that was originally allocated to the UE, has no user data after the fault recovery, or may be a new one because the previous S-CSCF is not responding, and then the network is reselected. S-CSCF. If an S-CSCF is reselected as the S-CSCF for failover, the network forwards the call request to the S-CSCF.

5302. The S-CSCF that is used to perform the fault recovery process sends a SAR request to the HSS, requesting to obtain the service configuration of the user and the previously backed up S-CSCF Info packet.

5303. After receiving the SAR request, if the HSS determines that the S-CSCF Info packet of the user exists locally, the HSS returns the service configuration and the S-CSCF Info packet of the user by using the SAA response, if the S-CSCF Info packet does not exist. Returning the user's service configuration information through the SAA response, and explicitly returning the current registration status information of the user;

In this step, since the registration information of the user is stored in the HSS, the HSS can directly check the current registration status of the user and check whether the S-CSCF Info packet associated with the user exists. In addition, the so-called "explicit return" means that there is information in the response that is specific to indicate whether the user is currently registered (ie, its current registration status) (such as a new parameter dedicated to indicating the current registration status of the user or Based on the information, the S-CSCF can determine the registration status of the user. It does not need to be judged by information containing other uses, or it is not necessary to further judge according to other conditions.

S304: After receiving the SAA response, the S-CSCF obtains the service configuration information of the user. If it is determined that there is no S-CSCF Info packet in the SAA response, the S-CSCF detects the current registration status information of the user returned in the SAA response, that is, the foregoing is dedicated to Information indicating the current registration status of the user, and obtaining the current registration status of the UE;

If there is an S-CSCF Info packet in the SAA response, the S-CSCF may further determine whether the user is currently registered according to the error response or other information included in the SAA, such as passing the error information (Experiment-Result) field in the SAA. The error response value is used to judge, for example, when the return value is DIAMETER_ERROR_IN_ASSIGNMENT_TYPE or DIAMETER_SUCCESS, the S-CSCF considers that the current user is registered, and if the return value is other values, the current user is considered to be Registered. S305. The S-CSCF uses the obtained data to continue the corresponding subsequent call processing process. In the process, the S-CSCF determines whether to trigger the registration service or trigger the unregistered service according to the current registration status of the user. That is, if the user is already registered, the registration service is triggered, and if the user is not registered, the unregistered service is triggered.

There is a significant variation in this embodiment. In this variant, the HSS determines that the S-CSCF Info packet of the requested user does not exist locally and the current registration status of the user is the registered state, and then returns the SAA response. The user's service configuration information and explicitly returns the status information registered by the user (ie, returning information indicating that the user has registered); if not, the service configuration information of the user may be returned only (default is not Registration status); After receiving the S-CSCF, it is determined whether the user has registered according to whether or not the registered status information exists (i.e., information dedicated to indicating that the user has registered). As a change, it is also possible to explicitly return status information that the user has not registered when the status is unregistered.

The other embodiments of the present invention are described below. The embodiments mainly indicate that the current registration status information of the user is different. The following mainly describes the content related to the indication mode. For other content, refer to the embodiment shown in FIG. 3.

Second embodiment

In this embodiment, regardless of whether the user's S-CSCF Info packet exists locally, the HSS returns the current registration status of the user in the SAA response.

After receiving the SAR request sent by the S-CSCF that performs the fault recovery process, the HSS unconditionally returns the current registration status information of the user in the SAA response regardless of whether the S-CSCF Info packet of the requested user exists locally; After receiving the SAA response, the CSCF determines the registration status of the user from the current registration status information of the user. Preferably, when there is and does not exist the S-CSCF Info packet of the user, the user uses the same manner as the first embodiment to indicate the current registration status of the user when the S-CSCF Info packet of the user does not exist. .

In this embodiment, the current registration status information of the user returned by the HSS may be included in the S-CSCF Info packet (when the S-CSCF Info packet exists), or may be included in other locations in the SAA response. The registration status information may be information dedicated to indicating whether the user is currently registered. It can also be through a combination of multiple information such as parameter values. That is, the information may be returned in a display or may be returned non-explicitly. When the display returns, the S-CSCF directly obtains the current registration status of the user according to the current registration status information of the explicit user in the SAA response, and does not need to further determine according to other conditions.

Third embodiment

When the HSS in this embodiment returns a SAA response to the S-CSCF, the current registration status of the user is indicated by the parameter value of the existing parameter such as the successful response of the SAA response or the abnormal cause.

After receiving the SAR request sent by the S-CSCF that performs the fault recovery process, if the S-CSCF Info packet of the user does not exist locally and the current registration status of the user is already registered, the HSS returns a S-CSCF response through the SAA response. The specific response value added by the existing parameter, otherwise the specific response value is not returned; when the S-CSCF does not have the user's S-CSCF Info packet in the received SAA response, the user is judged according to whether the specific response value is included or not. Current registration status. The specific response value is used to indicate that the user is currently registered, and may be a dedicated response value, that is, the user's current registration status may be determined without additional information.

The HSS may also return the specific response value in the SAA response when the user's current registration status is already registered, regardless of whether the user's current S-CSCF Info packet is present, and does not return the specific response when the user's current registration status is unregistered. Response. This processing may be performed by the HSS unconditionally, or when the HSS receives a request from the S-CSCF to return to the registration state. In addition, for the case of unregistered, it is also possible to use another specific response value to indicate that the registered condition can be indicated in a manner that does not include the specific response value.

For example, the specific response value may be a new Result Code value (processing response value) in the SAA, corresponding to a new return type, such as the value can be set to: DIAMETER_ SUCCESS_ USER_ ALREADY – REGISTERED, This value indicates that the HSS successfully executed the SAR request for the S-CSCF and told the S-CSCF that the current user is already registered. If the S-CSCF detects this value in the SAA response, it can be determined that the user has registered, otherwise it can be determined that the user is not registered.

In a variation of this embodiment, the HSS may jointly indicate the current user by a plurality of parameter values. The registration status, correspondingly, the S-CSCF needs to determine whether the user has registered based on the values of the several parameters. For example, if the S-CSCF Info information is not included in the SAA response, but the HSS successfully performs the SAR request of the S-CSCF, the Result Code value is DIAMETER_SUCCESS. If the user is already registered, the abnormal cause is added. A specific response value: DIAMETER - ERROR - USER - ALREADY - REGISTERED , although there is no S-CSCF Info information in the SAA, but the S-CSCF judges that the Result Code value is DIAMETER_SUCCESS, if it is further determined that the abnormal cause contains the specific The response value can be used to determine that the user is registered on the HSS. If DIAMETER_ERROR_USER_ALREADY_ REGISTERED is not included in the cause of the exception, the S-CSCF still considers the user unregistered.

In addition, the fault recovery S-CSCF performs a fault recovery process, and the service allocation request sent to the home subscriber server HSS may include information that requires the HSS to return the current registration status of the user.

In summary, the method for processing the S-CSCF fault in the present invention avoids the response returned by the S-CSCF according to the HSS by letting the HSS determine and return the registration status information of the user in the fault handling process after the S-CSCF fails. The error caused by the information in the result judgment can effectively avoid the business triggering confusion caused by the registration state judgment error.

Claims

Claim

A service call session control function S-CSCF fault recovery processing method, comprising: after a fault occurs in an S-CSCF allocated to a user, the network receives a call request related to the user, and first determines a fault recovery function. S-CSCF, called fault recovery S-CSCF;

2. The method of claim 1 wherein:

When the HSS does not have the S-CSCF info packet of the user locally, the HSS locally checks whether the user is registered, and returns a service registration response to the fault recovery S-CSCF to indicate the current registration status of the user. Information;

3. The method of claim 2, wherein:

4. The method of claim 2, wherein:

5. The method of claim 1 wherein:

6. The method of claim 5 wherein:

7. The method of claim 5 wherein:

The information that is returned by the HSS indicating that the user is currently registered is a new parameter added in the service allocation response to indicate that the user is currently registered or a new response value in the existing parameter; the fault recovery S-CSCF is directly based on Whether the new parameter or the newly added response value is included in the service allocation response to determine whether the user is currently registered; or

8. The method of claim 7 wherein:

The method according to any one of claims 2 to 7, wherein: after the HSS receives the service allocation request, the S-CSCF info packet of the user exists locally or does not exist. And indicating to the fault recovery S-CSCF the current registration status of the user in the same manner.

The method according to any one of claims 1 to 7, wherein: the failure recovery S-CSCF performs a failure recovery process, and the service allocation request sent to the HSS includes requesting the HSS Returns information about the user's current registration status.

11. The method of claim 1 wherein:

The fault recovery S-CSCF triggers the registration service if the current registration status of the user is the status, and triggers the unregistered service if the current registration status of the user is unregistered.