A fault recovery method, device, and equipment of a service access service and a medium

Abstract

The application relates to the technical field of fault recovery of service access services, and discloses a fault recovery method, device and equipment of service access services and a medium, wherein the method is characterized in that when a target service is in a fault state, the keepalived mode is used in the system layer to switch from a backup node to a main node, and a virtual IP is bound on the target service; based on the target service, UA data lists, Session data lists and Dialog data lists of the target service are respectively acquired from an etcd database; after the UA data lists, Session data lists and Dialog data lists corresponding to the application layer and the national standard protocol stack layer are recovered layer by layer, the SIP protocol stack layer is recovered, so that the target service is recovered to a normal state. The application can finally realize no perception of the fault state of the equipment to which the target service belongs, realizes uninterrupted monitoring of equipment code stream data, is compatible with equipment of various manufacturers in actual access service projects, and thus realizes seamless high availability of all the equipment.

Description

Technical Field

[0001] This invention relates to the field of fault recovery technology for service access services, and specifically to a fault recovery method, apparatus, equipment, and medium for service access services. Background Technology

[0002] High availability refers to the ability of a system or service to provide continuous and stable operation, meaning it can maintain normal operation and avoid interruption or data loss in the face of hardware failures, software problems, or other unexpected situations. High availability is typically achieved through the use of techniques such as redundancy, backup, and automatic failover.

[0003] Current high-availability solutions cannot fully restore the state of the GB28181 protocol stack. Although services can be quickly restored after a switchover, the protocol stack state, current session, and business context in the event of a backend service failure cannot be fully recovered, requiring re-registration and re-initiating of business requests. This is not transparent to terminals or clients accessing the GB28281 standard, making it impossible to achieve completely uninterrupted service. Monitoring systems have extremely high requirements for the integrity of recordings at key locations, as service failures leading to the loss of recordings from a large number of devices can cause significant losses.

[0004] In related technologies, to ensure no video recording is lost, one approach is through Automatic Network Replenishment Technology (ANR). During access service failures, terminal devices activate local recording to supplement the recording, and then transmit the supplemented recording to server storage after the failure is resolved. Another approach, to ensure uninterrupted streaming services, is the stream keep-alive scheme. During a failure, even if the monitoring terminal fails to maintain its national standard keep-alive or other signaling, it can continue sending the stream as long as it detects the RTCP keep-alive packet from the streaming media service. All of these rely on the cooperation of the terminal devices. However, because terminal devices from different manufacturers vary widely, it is difficult to achieve simultaneous compatibility with devices from different manufacturers in actual access service projects, making seamless high availability for all terminal devices impossible. Summary of the Invention

[0005] In view of this, the present invention provides a fault recovery method, apparatus, device and medium for service access services, in order to solve the problem that in actual access service projects, the bitstream is easily interrupted and it is difficult to achieve simultaneous compatibility with equipment from different manufacturers, resulting in the inability to achieve seamless high availability of all terminal devices.

[0006] According to a first aspect, the present invention provides a fault recovery method for a service access service, used in a service access service system, the system including an etcd database and an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer deployed from top to bottom; the method includes: Obtain the target business service of the currently accessed application layer; When the target business service is in a faulty state, keepalived is used at the system level to switch from the backup node to the master node, and the virtual IP is bound to the target business service; Based on the target business service, retrieve the UA data list, Session data list, and Dialog data list of the target business service from the etcd database respectively. After restoring the UA data list, Session data list, and Dialog data list corresponding to the application layer and the national standard protocol stack layer, the SIP protocol stack layer is then restored to enable the target business service to switch from a fault state to a normal state.

[0007] By implementing the above methods, based on the target service, the application layer, national standard protocol stack layer, and corresponding UA data list, session data list, and dialog data list are restored layer by layer within the service access service system. Then, the SIP protocol stack layer is restored so that the target service can switch from a fault state to a normal state. Ultimately, it is possible to achieve a state of no awareness of the fault status of the device to which the target service belongs. This not only ensures uninterrupted monitoring of device data streams but also enables compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0008] In one alternative implementation, restoring the SIP protocol stack includes: After restoring the Dialog data list corresponding to the national standard protocol stack layer, pass in the Dialog session identifier of the target business service; Based on the Dialog session identifier, retrieve the Dialog data list corresponding to the restored application layer and national standard protocol stack layer from the etcd database; Based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer, a Dialog session channel is created by the local protocol stack and the temporary protocol stack to actively or passively restore the SIP protocol stack layer.

[0009] By implementing the above methods, a Dialog session channel is created based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer. This channel is built by the local protocol stack and the temporary protocol stack to actively or passively restore the SIP protocol stack layer. The two parties communicating are the local protocol stack and the temporary protocol stack. The target service device is unaware of this, which not only ensures uninterrupted monitoring of the device's bitstream data, but also enables compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0010] In one optional implementation, based on the recovered application layer and national standard protocol stack corresponding to the Dialog data list, a Dialog session channel built from the local protocol stack and the temporary protocol stack is created, including: Use the SIP protocol stack as the local protocol stack; A temporary protocol stack is created based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer. Create a Dialog session channel consisting of a local protocol stack and a temporary protocol stack; Based on the Dialog session channel, the local protocol stack and the temporary protocol stack communicate with each other to perform active or passive recovery of the SIP protocol stack layer.

[0011] By implementing the above methods, a Dialog session channel is created based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer. This channel is built by the local protocol stack and the temporary protocol stack to actively or passively restore the SIP protocol stack layer. The two parties communicating are the local protocol stack and the temporary protocol stack. The target service device is unaware of this, which not only ensures uninterrupted monitoring of the device's bitstream data, but also enables compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0012] In one optional implementation, based on a Dialog session channel, the local protocol stack and the temporary protocol stack communicate with each other to actively restore the SIP protocol stack layer, including: Send a request command to the temporary protocol stack via the local protocol stack; The temporary protocol stack sends a response command back to the local protocol stack. If the session command data is Invite Dialog, then an ACK command is sent back to the local protocol stack via the temporary protocol stack; If the session command data is Subscribe Dialog, there is no need to reply with an ACK command to the local protocol stack via the temporary protocol stack; Actively restore the SIP protocol stack layer; After actively restoring the SIP protocol stack, the temporary protocol stack is destroyed.

[0013] By implementing the above-described method, the active recovery of the SIP protocol stack layer is achieved. The two communicating parties are the local protocol stack and the temporary protocol stack, which is unaware of the target service's end device. This not only ensures uninterrupted monitoring of device data streams but also enables compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0014] In one optional implementation, based on a Dialog session channel, the local protocol stack and the temporary protocol stack communicate with each other to passively restore the SIP protocol stack layer, including: Send request commands to the local protocol stack via the temporary protocol stack; The local protocol stack sends a response command to the temporary protocol stack. If the session command data is Invite Dialog, then an ACK command is sent back to the local protocol stack via the temporary protocol stack; If the session command data is Subscribe Dialog, there is no need to reply with an ACK command to the local protocol stack via the temporary protocol stack; Passive recovery of the SIP protocol stack layer; After passive recovery at the SIP protocol stack layer, the temporary protocol stack is destroyed.

[0015] By implementing the above methods, passive recovery of the SIP protocol stack can be achieved. The two parties communicating are the local protocol stack and the temporary protocol stack. The target service device is unaware of the data. This not only ensures uninterrupted monitoring of the device's bitstream data, but also enables compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0016] In one optional implementation, the Dialog session identifier of the target business service is passed through the recoverDialog call interface and the recover call interface of the national standard protocol stack layer.

[0017] By implementing the above method, a Dialog session identifier can be passed in.

[0018] In one optional implementation, based on the Dialog session identifier, a list of Dialog data corresponding to the recovered application layer and the national standard protocol stack layer is obtained from the etcd database, including: Based on the Dialog session identifier, retrieve the Dialog instance data corresponding to the target business service from the etcd database.

[0019] By implementing the above methods, the Dialog instance data corresponding to the target business service can be obtained.

[0020] According to the second aspect, this embodiment provides a fault recovery device for a service access service, used in a service access service system. The system includes an etcd database and, in a top-down configuration, an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer. The device includes: The business service acquisition module is used to acquire the target business service of the currently accessed application layer; The virtual network binding module is used to switch from the backup node to the primary node at the system layer using keepalived when the target business service is in a faulty state, and bind the virtual IP to the target business service. The data list acquisition module is used to retrieve the UA data list, Session data list, and Dialog data list of the target business service from the etcd database, respectively, based on the target business service. The data fault recovery module is used to restore the UA data list, Session data list and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer, and then restore the SIP protocol stack layer so that the target business service can switch from the fault state to the normal state.

[0021] According to a third aspect, this embodiment provides a computer device, including: The memory and the processor are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the fault recovery method for the service access service in the first aspect or any embodiment of the first aspect.

[0022] According to the fourth aspect, this embodiment also provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the fault recovery method for the service access service in the first aspect or any embodiment of the first aspect. Attached Figure Description

[0023] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the business access service system structure according to an embodiment of the present invention; Figure 2This is a flowchart illustrating a fault recovery method for service access services according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating another fault recovery method for a service access service according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating another fault recovery method for a service access service according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating a fault recovery method for a secondary service access service according to an embodiment of the present invention. Figure 6 This is a flowchart illustrating a fault recovery method for a secondary service access service according to an embodiment of the present invention. Figure 7 This is a schematic diagram of active recovery performed by the SIP protocol stack according to an embodiment of the present invention; Figure 8 This is a schematic diagram of passive recovery of the SIP protocol stack according to an embodiment of the present invention; Figure 9 This is a structural block diagram of a fault recovery device for service access according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] According to an embodiment of the present invention, a fault recovery method for a service access service is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0027] This embodiment provides a fault recovery method for service access services, such as... Figure 1 As shown, this is used for a business access service system. This system can be considered as a software system within a computer device. The system employs a layered design, such as... Figure 1 As shown, the system includes an etcd database and an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer, deployed layer by layer from top to bottom. Figure 1 In this context, the application layer corresponds to the application layer, the national standard protocol stack layer corresponds to the national standard, the protocol stack corresponds to the SIP protocol stack layer, and the system layer corresponds to the system layer.

[0028] exist Figure 1 In this system, the business access service system connects the etcd database to the application layer, the national standard protocol stack layer, and the SIP protocol stack layer. The application layer is used to access the target business service, which in practice can contain one or more service instance data. The national standard protocol stack layer is used to parse national standard protocol signaling, and the SIP protocol stack layer is used to parse SIP protocol signaling. The system layer is used to detect when the target business service fails after accessing the application layer. It uses keepalived, configuring one master node and at least one backup node, based on the same virtual network environment, and combined with hardware to restore the data of the application layer, national standard protocol stack layer, and SIP protocol stack layer layer by layer, so that the target business service can recover from the fault state to the normal state. The etcd database is used to store the data of the target business service, the national standard protocol stack layer, and the protocol stack layer. The application layer, national standard protocol stack layer, and SIP protocol stack layer also contain the UA layer, the Session layer, and the Dialog layer, respectively. The UA layer contains the Session layer, and the Session layer contains the Dialog layer.

[0029] User Agent (UA) is a logical entity that interfaces with the national standard access service. It may be a national standard terminal, a national standard platform, or a gateway. Session corresponds to a national standard session. In national standards, there are subordinate and superior levels. A terminal registers with the platform to form a session. Dialog corresponds to the dialog dialogue under the national standard session. UA contains one or more sessions. For example, a national standard surveillance camera generally registers with the system in this embodiment with only one national standard ID as the target business service access application layer. However, a national standard platform can use the national standard IDs of multiple devices to register with the system in this embodiment as the target business service access application.

[0030] Specifically, in the layered system design and multi-machine cluster deployment, keepalived is used for fault detection and failover. One master node and one or more backup nodes are configured, all using the same virtual IP. Upon detecting a failure in the access service, the keepalived backup node quickly takes over the master node's functionality and binds its virtual IP to itself. For database deployment, etcd is preferred due to its high availability, which improves the high availability of the devices supporting the target business service during fault recovery.

[0031] Furthermore, when the target business service accesses the application layer, the etcd database mentioned above stores key protocol stack data (data in the UA data list, Session data list, and Dialog data list) and target business data in the etcd database during system runtime. In the operation of storing the data in the etcd database, a set of related data needs to be stored simultaneously and assembled into a single transaction to ensure data consistency. The data mentioned above is stored in the etcd database in a tree-like data structure, with the root directory of the tree corresponding to a service instance, identified by its service ID. The etcd database stores the UA data list, Session data list, and Dialog data list corresponding to the application layer and national standard protocol stack layer of the target business service. See Tables 1-6 below for details.

[0032] After the failover, the target service reads the protocol stack data and target service data from the etcd database and restores it to the state before the failure.

[0033] In the application scenario of the service access service system in this embodiment, it can be used on mobile terminals such as mobile phones and tablets (the execution subject is described in conjunction with the actual situation). Figure 2 This is a flowchart of a fault recovery method for service access services according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the target business service of the currently accessed application layer.

[0034] Specifically, the target service can be a target service accessed by a national standard device or a national standard platform. For example, a national standard surveillance camera typically registers with the system in this embodiment using only one national standard ID to access the application layer as a target service. A national standard platform, on the other hand, can register with the system in this embodiment using the national standard IDs of multiple devices to access the application as target services. This target service can correspond to one service instance or multiple service instances, and the service instance is identified by an ID.

[0035] Step S202: When the target business service is in a fault state, use keepalived at the system layer to switch from the backup node to the master node and bind the virtual IP to the target business service.

[0036] Specifically, in this embodiment, fault recovery is triggered by Keepalived, starting from the application layer and recursively recovering the UA / Session / Dialog at each layer. For example, Keepalived achieves high availability through VIP migration. After the master host fails, a backup host is selected as the new master host, and the VIP is modified and assigned to the new master host. Recovery begins through the application on the new master host. When the target service is restarted, it first checks if the current system IP is the same as the configured virtual IP. If so, it occupies the virtual IP and becomes the master host, allowing recovery to begin. Otherwise, it indicates that the current service is a backup host and should remain dormant.

[0037] Step S203: Based on the target business service, obtain the UA data list, Session data list, and Dialog data list of the target business service from the etcd database respectively.

[0038] Specifically, this involves retrieving complete lists of User Agent (UA), Session, and Dialog data from the etcd database for the application layer, GB / T 2425 protocol stack, and SIP protocol stack. In a specific example, the corresponding UA, Session, and Dialog data lists can be retrieved from the etcd database using the ID information of the instance corresponding to the target business service.

[0039] Step S204: After restoring the UA data list, Session data list, and Dialog data list corresponding to the application layer and the national standard protocol stack layer, the SIP protocol stack layer is restored so that the target business service can switch from the fault state to the normal state.

[0040] In one example, based on the target business service, the system retrieves a list of all User Agent (UA) data for the target business service from the root directory of the etcd database using the service instance ID information within that service service, and then begins UA recovery. Table 1 below shows the application-layer UA data list; the application-layer UA data list is then recovered using Table 1.

[0041] Table 1

[0042] Furthermore, based on the target business service, the session list of the User Agent (UA) is queried from the root directory of the etcd database using the ID information of the service instance within that target business service. The application layer session data list is then restored using Table 2 below. UA / Session / Dialog has a hierarchical relationship; restoring Session is part of restoring UA, and restoring Dialog is part of restoring Session.

[0043] Table 2

[0044] Furthermore, based on the target business service, various session services, including browsing, recording, calling, and alarm subscription, are recovered by querying the dialogs in the Session from the root directory of the etcd database using the service instance ID information within that target business service. The information to be recovered at the business layer differs for each service. The application layer dialog data list is shown in Table 3 below.

[0045] Table 3

[0046] In another example, based on the target business service, the system queries the root directory of the etcd database for a list of all User Agent (UA) data for the target business service using the service instance ID information, and then begins UA recovery. Table 4 below shows the UA data list for the GBP protocol stack layer. The GBP protocol stack layer UA data list is recovered using Table 4. Recovery of the GBP protocol stack layer is triggered by the system layer and is also performed layer by layer. The data recovered at this layer includes the UA data list, Session data list, and Dialog data list.

[0047] Table 4

[0048] In another example, based on the target business service, the Session list of the UA of the target business service is queried from the root directory of the etcd database using the ID information of the service instance in the target business service. The Session data list of the national standard protocol stack layer is then restored using Table 5 below. UA / Session / Dialog has a hierarchical relationship; restoring Session is part of restoring UA, and restoring Dialog is part of restoring Session.

[0049] Table 5

[0050] In another example, based on the target business service, the system queries the root directory of the etcd database for a list of all User Agent (UA) data for the target business service using the service instance ID information, and then begins UA recovery. Table 6 below shows the UA data list for the GBP protocol stack layer. The UA data list for the GBP protocol stack layer is recovered using Table 6. The recovery of the GBP protocol stack layer is triggered by the system layer, which recovers data from the UA data list, Session data list, and Dialog data list.

[0051] Table 6

[0052] In another specific example, after restoring the application layer and the national standard protocol stack layer, the SIP protocol stack layer is then restored.

[0053] Specifically, in this embodiment, the SIP protocol stack is attached to and serves the service. Therefore, during recovery, the recovery of the SIP protocol stack should be led by the program serving the target service.

[0054] In the SIP protocol stack, the UA layer is stateless, and the Session layer is also stateless within the SIP protocol stack. Therefore, it is only necessary to restore the UA data list and Session data list in the application layer and national standard layer to the program. It is not necessary to restore the UA data list and Session data list of the SIP protocol stack itself. However, the Dialog layer is stateful within the SIP protocol stack, so it is necessary to restore the Dialog session within the SIP protocol stack. After the SIP protocol stack layer recovers from the fault, the protocol stack data and target service data are read from the etcd database based on the target service, and the data is restored to the state before the fault occurred.

[0055] The fault recovery method for the service access service in this embodiment involves the following steps: When the target service is in a fault state, keepalived is used at the system layer to switch from the backup node to the primary node, and the virtual IP is bound to the target service. Based on the target service, the UA data list, Session data list, and Dialog data list of the target service are retrieved from the etcd database. After restoring the UA data list, Session data list, and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer, the SIP protocol stack layer is then restored to switch the target service from a fault state to a normal state. By restoring the UA data list, Session data list, and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer within the service access service system based on the target service, and then restoring the SIP protocol stack layer to switch the target service from a fault state to a normal state, this invention ultimately achieves seamless high availability of all devices, enabling the system to be unaware of the fault state of the device to which the target service belongs. This not only ensures uninterrupted monitoring of device data streams but also allows for compatibility with devices from different manufacturers in actual access service projects.

[0056] This embodiment provides a fault recovery method for service access, which can be used on mobile terminals such as mobile phones and tablets. Figure 3 This is a flowchart of a fault recovery method for service access services according to an embodiment of the present invention, such as... Figure 3 As shown, step S204, restoring the SIP protocol stack layer, includes: Step S301: After restoring the Dialog data list corresponding to the national standard protocol stack layer, pass in the Dialog session identifier of the target business service.

[0057] Specifically, after restoring the corresponding Dialog data list, the GB / T protocol stack layer needs to reply with a Dialog session to the SIP protocol stack layer based on the records.

[0058] In one optional implementation, the Dialog session identifier of the target service is passed through the recoverDialog call interface and the recover call interface of the national standard protocol stack layer. This Dialog session identifier can be identified by DialogID. First, the recoverDialog call interface of the Session layer of the national standard protocol stack layer is used, and then the Dialog session identifier of the target service is passed through the recover call interface. That is, the DialogID identifier is passed through the recoverDialog call interface and the recover call interface in sequence.

[0059] Step S302: Based on the Dialog session identifier, obtain the Dialog data list corresponding to the restored application layer and national standard protocol stack layer from the etcd database.

[0060] In an optional implementation, step S302, based on the Dialog session identifier, retrieves the Dialog data list corresponding to the application layer and the national standard protocol stack layer after recovery from the etcd database, including: Based on the Dialog session identifier, retrieve the instance data corresponding to the restored application layer and national standard protocol stack layer from the etcd database.

[0061] Specifically, because the data in the etcd database is stored in a tree-like data structure, each piece of data can be accessed through a file path. For example, when restoring the Session data list and Dialog data list at the national standard protocol stack layer, a Dialog instance based on the target business service is first created, and the data path of this Dialog in the etcd database is passed to the identifier corresponding to the Dialog instance, identified by the DialogID. During a specific query, the persistent data of itself is retrieved from the etcd database through the file path using this session identifier.

[0062] For example, a data path instance for a Dialog is: “gbinterface / 192.16.88.84-8080 / uas / client-31000000002000000000 / sessions / 31000000002000000001 / dialogs / 70b96e85f163ea55e6bcbc9abf022547@127.0.0.1 / ”.

[0063] Step S303: Based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer, create a Dialog session channel built by the local protocol stack and the temporary protocol stack to actively or passively restore the SIP protocol stack layer.

[0064] Specifically, the restored application layer and national standard protocol stack layer corresponding Dialog data lists are used by the Dialog to recover data stored in its own memory as member variables. These include: "request", "response", "ack", "realRemoteAddr", and "realRemotePort", which are the data from Table 6 above. Figure 7 As shown, restoring the system's own Dialog data is equivalent to restoring the Dialog data lists corresponding to the application layer and the national standard protocol stack layer.

[0065] Specifically, after restoring the Dialog data lists corresponding to the application layer and the national standard protocol stack layer, a new temporary SIP protocol stack layer is created in order to restore the local protocol stack, simulating the SIP service of the peer to complete the protocol stack reconstruction process.

[0066] The local SIP protocol stack is rebuilt by sending persistently saved Request / Response / Ack messages between the local and temporary protocol stacks. This process is achieved by modifying the address and port in the RequestLine or Via field of the message to specify that the message is sent to the temporary SIP protocol stack instead of the actual peer address. The only difference between ActiveDialogs created locally and Passive Dialogs created peer-to-peer during restoration is the order of signaling interactions with the temporary protocol stack; there is no fundamental difference between them.

[0067] In this embodiment, the active or passive recovery of the SIP protocol stack is basically the same. In active recovery, the local protocol stack is the initiator, and in passive recovery, the temporary protocol stack is the initiator.

[0068] This embodiment creates a Dialog session channel built by the local protocol stack and the temporary protocol stack based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer. This allows for active or passive recovery of the SIP protocol stack layer. The two parties communicating are the local protocol stack and the temporary protocol stack. This is unaware of the target service's end device. It not only ensures uninterrupted monitoring of the device's bitstream data but also ensures compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0069] This embodiment provides a fault recovery method for service access, which can be used on mobile terminals such as mobile phones and tablets. Figure 4 As shown, step S303 involves creating a Dialog session channel built from the local protocol stack and the temporary protocol stack, based on the Dialog data list corresponding to the restored application layer and national standard protocol stack. This includes: Step S401: Use the SIP protocol stack as the local protocol stack.

[0070] exist Figure 7 and Figure 8 In this context, the SIP protocol stack is used as the local protocol stack, that is... Figure 7 and Figure 8 The Dialog section in the code represents the local protocol stack layer.

[0071] Step S402: Create a temporary protocol stack based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer.

[0072] Specifically, Dialog -create->Temporary Protocol Stack creates a temporary protocol stack for recovery, simulating the peer device that was communicating before the failure. The data from the aforementioned national standard protocol stack layer is passed in when creating the temporary protocol stack, ensuring that the temporary protocol stack also contains complete Dialog information.

[0073] Step S403: Create a Dialog session channel built from the local protocol stack and the temporary protocol stack.

[0074] Step S404: Based on the Dialog session channel, control the communication between the local protocol stack and the temporary protocol stack to perform active or passive recovery of the SIP protocol stack layer.

[0075] like Figure 7 and Figure 8 As shown, the SIP protocol stack layer in this embodiment performs active or passive recovery in essentially the same way. In the Dialog session channel, the local protocol stack acts as the initiator during active recovery, while the temporary protocol stack acts as the initiator during passive recovery.

[0076] This embodiment creates a Dialog session channel built by the local protocol stack and the temporary protocol stack based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer. This allows for active or passive recovery of the SIP protocol stack layer. The two parties communicating are the local protocol stack and the temporary protocol stack. This is unaware of the target service's end device. It not only ensures uninterrupted monitoring of the device's bitstream data but also ensures compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0077] This embodiment provides a fault recovery method for service access, which can be used on mobile terminals such as mobile phones and tablets. Figure 5 This is a flowchart of a fault recovery method for service access services according to an embodiment of the present invention, such as... Figure 5 As shown, step S404, based on the Dialog session channel, controls the communication between the local protocol stack and the temporary protocol stack to actively restore the SIP protocol stack layer, including: Step S501: Send a request command to the temporary protocol stack through the local protocol stack.

[0078] exist Figure 7 and Figure 8 In the middle, the Dialog section can be regarded as the local protocol stack, which sends a request command to the temporary protocol stack; the request command is the invite command.

[0079] Step S502: Respond with a response command to the local protocol stack via the temporary protocol stack.

[0080] exist Figure 7 and Figure 8 In the process, a response command is sent back to the local protocol stack via a temporary protocol stack. This response command is called the Response command.

[0081] In step S503, if the session instruction data is Invite Dialog, then reply with an ACK instruction to the local protocol stack through the temporary protocol stack.

[0082] In this embodiment, the session commands include Invite Dialog and Subscribe Dialog. The session command data originates from the national standard protocol stack layer, and the recovery process for both is identical. The only difference is that Subscribe Dialog does not have an Ack command, therefore it does not need to send an Ack command. The ACK command is an acknowledgment command.

[0083] In step S504, if the session instruction data is Subscribe Dialog, then there is no need to reply with an ACK instruction to the local protocol stack through the temporary protocol stack.

[0084] Step S505: Actively restore the SIP protocol stack layer; Step S506: After actively restoring the SIP protocol stack layer, destroy the temporary protocol stack.

[0085] This embodiment can achieve proactive recovery of the SIP protocol stack layer. The two parties communicating are the local protocol stack and the temporary protocol stack. It is unaware of the terminal device to which the target service belongs. Not only does it achieve uninterrupted monitoring of device data streams, but it can also be compatible with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability of all devices.

[0086] This embodiment provides a fault recovery method for service access, which can be used on mobile terminals such as mobile phones and tablets. Figure 6 This is a flowchart of a fault recovery method for service access services according to an embodiment of the present invention, such as... Figure 6 As shown, step S404, based on the Dialog session channel, controls the communication between the local protocol stack and the temporary protocol stack to passively restore the SIP protocol stack layer, including: Step S601: Send a request command to the local protocol stack through the temporary protocol stack.

[0087] In this embodiment, passive recovery is the reverse process of active recovery. Figure 7 and Figure 8In the middle, the Dialog section can be regarded as the local protocol stack, which sends a request command to the temporary protocol stack; the request command is the invite command.

[0088] Step S602: Respond with a response command to the temporary protocol stack via the local protocol stack.

[0089] exist Figure 7 and Figure 8 In the process, a response command is sent back to the local protocol stack via a temporary protocol stack. This response command is called the Response command.

[0090] In step S603, if the session instruction data is Invite Dialog, then reply with an ACK instruction to the local protocol stack through the temporary protocol stack.

[0091] In this embodiment, the session commands include Invite Dialog and Subscribe Dialog. The recovery process for both is the same, the only difference being that Subscribe does not have an ACK, so it does not need to send an ACK.

[0092] In step S604, if the session instruction data is Subscribe Dialog, there is no need to reply with an ACK instruction to the local protocol stack through the temporary protocol stack.

[0093] Step S605: Passively restore the SIP protocol stack layer.

[0094] Step S606: After passively restoring the SIP protocol stack layer, destroy the temporary protocol stack.

[0095] This embodiment enables passive recovery of the SIP protocol stack layer. The two communicating parties are the local protocol stack and the temporary protocol stack. It is unaware of the target service's end device. This not only ensures uninterrupted monitoring of device data streams, but also allows for compatibility with devices from different manufacturers in actual access service projects, thereby achieving seamless high availability for all devices.

[0096] This embodiment also provides a fault recovery device for service access, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0097] This embodiment provides a fault recovery device for service access services, such as... Figure 9As shown, it includes: a service access system, which includes an etcd database and an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer deployed from top to bottom; and an apparatus, including: The business service acquisition module 91 is used to acquire the target business service of the currently accessed application layer. The virtual network binding module 92 is used to switch from the backup node to the master node using keepalived at the system layer when the target business service is in a faulty state, and bind the virtual IP to the target business service. The data list acquisition module 93 is used to acquire the UA data list, Session data list and Dialog data list of the target business service from the etcd database based on the target business service. The data fault recovery module 94 is used to restore the UA data list, Session data list and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer, and then restore the SIP protocol stack layer so that the target business service can switch from the fault state to the normal state.

[0098] In one optional implementation, the data fault recovery module 94 includes: The session identifier acquisition submodule is used to pass in the Dialog session identifier of the target business service after restoring the Dialog data list corresponding to the national standard protocol stack layer; The data list retrieval submodule is used to retrieve the restored application layer and national standard protocol stack layer Dialog data lists from the etcd database based on the Dialog session identifier. The Session Channel Creation submodule is used to create a Dialog session channel built from the local protocol stack and the temporary protocol stack based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer, so as to actively or passively restore the SIP protocol stack layer.

[0099] In one alternative implementation, the session channel creation module includes: The local protocol stack determination submodule is used to use the SIP protocol stack layer as the local protocol stack. The session instruction acquisition submodule is used to create a temporary protocol stack based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer. The temporary protocol stack creation module is used to create a temporary protocol stack based on the Dialog data list corresponding to the restored application layer and national standard protocol stack layer. The Session Channel Creation submodule is used to create Dialog session channels built from the local protocol stack and the temporary protocol stack. The fault data recovery submodule is used to control the communication between the local protocol stack and the temporary protocol stack based on the Dialog session channel, so as to actively or passively restore the SIP protocol stack layer.

[0100] In one optional implementation, the fault data recovery submodule includes: The first request instruction sending unit is used to send request instructions to the temporary protocol stack through the local protocol stack. The first response instruction reply unit is used to respond to the response instruction to the local protocol stack through the temporary protocol stack; The first communication action execution unit is used to reply with an ACK command to the local protocol stack through a temporary protocol stack if the session instruction data is Invite Dialog. The second communication action execution unit is used so that if the session instruction data is Subscribe Dialog, there is no need to reply with an ACK instruction to the local protocol stack through the temporary protocol stack; The protocol stack active recovery unit is used to actively recover the SIP protocol stack layer; The protocol stack destruction unit is used to destroy the temporary protocol stack after active recovery of the SIP protocol stack layer.

[0101] In one optional implementation, the fault data recovery submodule includes: The second request instruction sending unit is used to send request instructions to the local protocol stack through the temporary protocol stack; The second response instruction reply unit is used to respond to the response instruction to the temporary protocol stack through the local protocol stack; The third communication action execution unit is used to reply with an ACK command to the local protocol stack through the temporary protocol stack if the session command data is Invite Dialog; The fourth communication action execution unit is used to ensure that if the session instruction data is Subscribe Dialog, there is no need to reply with an ACK instruction to the local protocol stack through the temporary protocol stack; Passive recovery of the SIP protocol stack layer; After passive recovery at the SIP protocol stack layer, the temporary protocol stack is destroyed.

[0102] In one optional implementation, the recoverDialog call interface of the national standard protocol stack layer is used, and the recovery call interface is passed in the Dialog session identifier of the target business service.

[0103] In one alternative implementation, the data list acquisition module includes: The instance data acquisition unit is used to retrieve Dialog instance data corresponding to the target business service from the etcd database based on the Dialog session identifier.

[0104] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0105] In this embodiment, the fault recovery device for service access is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0106] This invention also provides a computer device having the above-described features. Figure 10 The fault recovery device for the service access service shown is shown.

[0107] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 10 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 10 Take a processor 10 as an example.

[0108] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0109] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0110] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0111] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0112] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0113] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0114] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A fault recovery method for a service access service, characterized in that, This is used for a business access service system, which includes an etcd database and an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer, which are deployed layer by layer from top to bottom. The GB / T protocol stack layer is used to parse GB / T protocol signaling, and the SIP protocol stack layer is used to parse SIP protocol signaling. The method includes: Obtain the target business service currently accessing the application layer; When the target service is in a fault state, the system layer uses keepalived to switch from the backup node to the master node and binds the virtual IP to the target service; Based on the target business service, obtain the UA data list, Session data list, and Dialog data list of the target business service from the etcd database respectively; After restoring the UA data list, Session data list, and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer, the SIP protocol stack layer is then restored so that the target service can switch from the fault state to the normal state. The restoration of the SIP protocol stack includes: After restoring the Dialog data list corresponding to the national standard protocol stack layer, the Dialog session identifier of the target service is passed in; Based on the Dialog session identifier, retrieve the restored Dialog data list corresponding to the application layer and the national standard protocol stack layer from the etcd database; Based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer, a Dialog session channel is created by the local protocol stack and the temporary protocol stack to perform active or passive recovery of the SIP protocol stack layer. In active recovery, the local protocol stack acts as the initiator, and in passive recovery, the temporary protocol stack acts as the initiator.

2. The method according to claim 1, characterized in that, Based on the recovered application layer and the corresponding Dialog data list of the national standard protocol stack layer, a Dialog session channel built from the local protocol stack and the temporary protocol stack is created, including: Use the SIP protocol stack layer as the local protocol stack; Based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer, the temporary protocol stack is created. Create a Dialog session channel constructed from the local protocol stack and the temporary protocol stack; Based on the Dialog session channel, the local protocol stack and the temporary protocol stack are controlled to communicate with each other in order to actively or passively restore the SIP protocol stack layer.

3. The method according to claim 2, characterized in that, Based on the Dialog session channel, control the communication between the local protocol stack and the temporary protocol stack to actively restore the SIP protocol stack layer, including: Send a request command to the temporary protocol stack through the local protocol stack; The temporary protocol stack sends a response command to the local protocol stack. If the session command data is Invite Dialog, then an ACK command is sent back to the local protocol stack via the temporary protocol stack; If the session command data is Subscribe Dialog, then there is no need to reply with an ACK command to the local protocol stack through the temporary protocol stack; Actively restore the SIP protocol stack layer; After the SIP protocol stack layer is actively restored, the temporary protocol stack is destroyed.

4. The method according to claim 2, characterized in that, Based on the Dialog session channel, control the communication between the local protocol stack and the temporary protocol stack to passively restore the SIP protocol stack layer, including: Send a request command to the local protocol stack through the temporary protocol stack; The local protocol stack responds to the temporary protocol stack with a response command. If the session command data is Invite Dialog, then an ACK command is sent back to the local protocol stack via the temporary protocol stack; If the session instruction data is a Subscribe Dialog, then there is no need to reply with an ACK instruction to the local protocol stack through the temporary protocol stack; The SIP protocol stack layer is passively restored; After the SIP protocol stack layer is passively restored, the temporary protocol stack is destroyed.

5. The method according to claim 1, characterized in that, The target service's Dialog session identifier is passed through the recoverDialog call interface and the recover call interface of the national standard protocol stack layer.

6. The method according to claim 1, characterized in that, Retrieve the restored Dialog data list corresponding to the application layer and the national standard protocol stack layer from the etcd database, including: Based on the Dialog session identifier, retrieve the Dialog instance data corresponding to the target business service from the etcd database.

7. A fault recovery device for service access, characterized in that, This is for a business access service system, which includes an etcd database and an application layer, a national standard protocol stack layer, a SIP protocol stack layer, and a system layer deployed from top to bottom. The national standard protocol stack layer is used to parse national standard protocol signaling, and the SIP protocol stack layer is used to parse SIP protocol signaling. The device includes: The business service acquisition module is used to acquire the target business service currently accessing the application layer; The virtual network binding module is used to switch from the backup node to the primary node using keepalived at the system layer when the target service is in a faulty state, and bind the virtual IP to the target service. The data list acquisition module is used to acquire, based on the target business service, the UA data list, Session data list, and Dialog data list of the target business service from the etcd database, respectively. The data fault recovery module is used to restore the UA data list, Session data list and Dialog data list corresponding to the application layer and the national standard protocol stack layer layer by layer, and then restore the SIP protocol stack layer so that the target business service can switch from the fault state to the normal state. The data fault recovery module includes: The session identifier acquisition submodule is used to pass in the Dialog session identifier of the target business service after restoring the Dialog data list corresponding to the national standard protocol stack layer; The data list retrieval submodule is used to retrieve the restored application layer and national standard protocol stack layer Dialog data lists from the etcd database based on the Dialog session identifier. The Session Channel Creation submodule is used to create a Dialog session channel built from the local protocol stack and the temporary protocol stack based on the Dialog data list corresponding to the restored application layer and the national standard protocol stack layer. This channel is used to perform active or passive recovery of the SIP protocol stack layer. In active recovery, the local protocol stack acts as the initiator, and in passive recovery, the temporary protocol stack acts as the initiator.

8. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault recovery method for the service access service as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the fault recovery method for the service access service as described in any one of claims 1 to 6.

Images