A method and device for probing the health of a SIP terminal, and a storage medium

Abstract

This application belongs to the field of core communication engines for Internet Protocol dedicated switches (IP switches), specifically involving a SIP terminal health detection method, apparatus, and storage medium. The method includes: when a contact has configured a detection frequency, if the contact has successfully registered for the first time, marking the contact's status as reachable; otherwise, determining whether the contact's terminal is a peer relay terminal and whether the peer relay terminal's configuration is being loaded for the first time; if so, asynchronously pushing the detection task to a dedicated thread pool; otherwise, periodically scheduling according to the detection frequency; during periodic scheduling, for unregistered relays, returning to the next scheduling interval; otherwise, pushing the detection task to the dedicated thread pool; when a normal response is received, for unregistered relays, marking the contact's status as unreachable; if the response times out or a transmission error occurs, forcibly terminating all subsequent retransmission attempts. This application's solution can improve scheduling efficiency, resource utilization, and security.

Description

Technical Field

[0001] This application belongs to the field of core communication engine technology of Internet Protocol dedicated switches, specifically relating to a method, device and storage medium for detecting the health of SIP terminals. Background Technology

[0002] In enterprise communication systems based on the Session Initiation Protocol (SIP), the core engine of an IPPBX (Internet Protocol Private Branch Exchange) needs to continuously monitor the online status of all registered SIP endpoints and trunks to ensure the accuracy of call routing decisions. The current industry practice is for the IPPBX to periodically send SIP OPTIONS requests to each contact and determine the reachability of that contact based on the received response code (e.g., 200 OK) or timeout event, thereby maintaining the health of the endpoints or trunks.

[0003] However, traditional SIP endpoint health detection and contact management solutions generally suffer from the following technical bottlenecks in actual deployment: First, the active scheduling lacks awareness of the registration status.

[0004] Traditional solutions indiscriminately send OPTIONS requests to all contacts configured with a probe frequency, even if the SIP trunk has not yet completed outbound registration. This not only leads to a large number of invalid probes consuming network bandwidth and protocol stack transaction resources, but may also cause OPTIONS responses from unregistered trunks to be misjudged as reachable, thus routing calls to trunk links that are actually unavailable.

[0005] Second, there is a waste of transaction resources after OPTIONS times out.

[0006] When the OPTIONS request times out for the first time, traditional solutions rely on the underlying protocol stack's transaction layer to continuously retransmit according to the exponential backoff strategy of the SIP specification. A single probe failure can generate up to seven invalid retransmissions. When a large number of terminals go offline simultaneously, the accumulated retransmission messages severely consume the protocol stack's transaction processing capacity and network bandwidth, while also delaying the final confirmation of the terminal's unreachable state.

[0007] In summary, existing SIP terminal health detection methods have significant shortcomings in terms of scheduling efficiency, resource utilization, and security, and there is an urgent need for an improved solution that can comprehensively address these issues. Summary of the Invention

[0008] To improve the scheduling efficiency, resource utilization, and security of SIP terminal health detection methods, in a first aspect, embodiments of this application provide a SIP terminal health detection method, the method comprising: When a contact has a liveness detection frequency configured, if the contact is registering successfully for the first time, the contact's status will be marked as reachable directly, and no OPTIONS liveness detection request will be sent. Otherwise, determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is being loaded for the first time. If yes, asynchronously push the detection task to the dedicated thread pool and immediately detect the contact. If no, perform periodic scheduling according to the configured detection frequency. In periodic scheduling, if the scheduling callback function detects that the contact's terminal type is relay and has not yet completed outbound registration, it returns to the next scheduling interval and skips the sending of the current round of activation request; otherwise, it pushes the activation task to a dedicated thread pool to activate the contact. Send a SIP OPTIONS request to the contact to be contacted and wait for a response; When a normal response is received, the timeout counter corresponding to the contact is reset to zero; if the contact's terminal type is relay type and outbound registration has not yet been completed, the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. If a response times out or a transmission error occurs, the retransmission timer and timeout timer for the transaction corresponding to the OPTIONS request are canceled through the protocol stack timer heap interface. The timeout event is then rescheduled with a zero-delay value to forcibly terminate all subsequent retransmission attempts. The timeout counter for the contact is incremented, and the contact's status is marked as unreachable.

[0009] In one possible implementation, the method further includes: When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

[0010] In one possible implementation, sending a SIP OPTIONS request to the contact to be contacted includes: When it is detected that the terminal to which the contact belongs is configured with both IPv4 and IPv6 transmission names, a transmission mismatch callback function pointer is injected into the data sending object, and the terminal identifier of the contact is copied to the terminal name field of the data sending object. Determine whether the transmission protocol matches the address family of the target address. If they do not match, trigger the transmission mismatch callback function. The transmission mismatch callback function is used to rebind the data object to the correct transmission channel according to the address family of the target address.

[0011] In one possible implementation, the method further includes: If the response message carries a custom SIP header field, extract the IP address of the SBC proxy from the custom SIP header field and persist the IP address to the proxy IP field of the contact object, and mark the status of the contact as reachable; If the status code and reason phrase in the response message indicate that the SBC agent has been disconnected, clear the contacts connected to the SBC agent and cancel the liveness detection schedule for the contacts.

[0012] In one possible implementation, the scheduling interval for the first liveness detection is generated by multiplying a random double-precision floating-point number by the configured liveness detection frequency, and is constrained by the global maximum initial liveness detection time parameter.

[0013] In one possible implementation, the method further includes: Under the protection of a global static mutex lock, the existing contact object is searched through the identifier retrieval interface of the configuration framework. If no contact object corresponding to the liveness detection task exists, it is created and persisted through the creation interface of the configuration framework. A custom destructor is bound to the created contact object to release the URI string, AoR identifier and proxy IP address when the reference count of the contact object reaches zero.

[0014] In one possible implementation, the method further includes: Receive inbound OPTIONS requests from the sender and retrieve all registered contacts under the sender's AoR; If the inbound OPTIONS request comes from a terminal of the extension type or an account type, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. If no match is found, the confirmation response will be rejected. If the inbound OPTIONS request comes from a terminal registered with a fully qualified domain name, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. A reverse DNS resolution will be performed on the IP address of the request source to determine whether the IP address of the request source is a valid resolution address of the fully qualified domain name. If it does not belong to the domain name and the match is unsuccessful, the confirmation response will be rejected. If the inbound OPTIONS request originates from a human endpoint, which is the default endpoint automatically assigned for requests whose origin cannot be identified, no response will be returned.

[0015] Secondly, embodiments of this application provide a SIP terminal health detection device, the device comprising: The first scheduling module is used to mark the status of a contact as reachable and not send the OPTIONS liveness detection request if the contact has configured a liveness detection frequency and the contact has successfully registered for the first time. The second scheduling module is used to determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is being loaded for the first time. If yes, the activation detection task is asynchronously pushed to a dedicated thread pool and the contact is immediately activated. If no, the activation detection is periodically scheduled according to the configured activation detection frequency. The third scheduling module is used to, during periodic scheduling, if the scheduling callback function detects that the terminal type of the contact is a relay type and has not yet completed outbound registration, return to the next scheduling interval and skip the sending of the current round of detection request; otherwise, push the detection task to a dedicated thread pool to detect the contact. The sending module is used to send a SIP OPTIONS request to the contact to be contacted and wait for a response; The first processing module is used to reset the timeout counter corresponding to the contact to zero when a normal response is received; if the contact's terminal type is relay type and outbound registration has not been completed, then the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. The second processing module is used to cancel the retransmission timer and timeout timer of the transaction corresponding to the OPTIONS request through the protocol stack timer heap interface if the response times out or a transmission error occurs, reschedule the timeout event with a zero-delay value to forcibly terminate all subsequent retransmission attempts, increment the timeout counter of the contact, and mark the status of the contact as unreachable.

[0016] In one possible implementation, the device further includes a routing module for: When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

[0017] Thirdly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described SIP terminal health detection methods.

[0018] This application provides a SIP terminal health detection method, comprising: when a contact has configured a detection frequency, if the contact has successfully registered for the first time, directly marking the contact's status as reachable, and not sending the current OPTIONS detection request; otherwise, determining whether the contact's terminal is a peer relay terminal and whether the peer relay terminal's configuration is being loaded for the first time, if yes, asynchronously pushing the detection task to a dedicated thread pool, and immediately detecting the contact's health; otherwise, periodically scheduling according to the configured detection frequency; during periodic scheduling, if the scheduling callback function detects that the contact's terminal type is relay type and has not yet completed outbound registration, returning to the next scheduling interval and skipping the sending of the current round of detection requests; otherwise, pushing the detection task to a dedicated thread pool, and detecting the contact's health; sending SIP messages to the contact to be detected. The system requests an OPTIONS request and waits for a response. Upon receiving a normal response, it resets the timeout counter for the contact to zero. If the contact's terminal type is relay and outbound registration has not yet been completed, the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. If the response times out or a transmission error occurs, the retransmission timer and timeout timer for the transaction corresponding to the OPTIONS request are canceled via the protocol stack timer heap interface. The timeout event is then rescheduled with zero latency to forcibly terminate all subsequent retransmission attempts. The contact's timeout counter is incremented, and the contact's status is marked as unreachable. This solution improves scheduling efficiency, resource utilization, and security. Attached Figure Description

[0019] Figure 1 This is a schematic flowchart of a SIP terminal health detection method provided in an embodiment of this application; Figure 2 A schematic diagram of the registration-aware differentiated scheduling process; Figure 3 A diagram illustrating the process of sending OPTIONS and optimizing transactions; Figure 4 A flowchart illustrating the processing flow for response event types; Figure 5 This is a schematic diagram of the OPTIONS response security filtering process; Figure 6 The system initialization timing diagram; Figure 7 Create a sequence diagram for the contact; Figure 8 This is a time-series diagram for periodic liveness detection; Figure 9 For SBC agent tracking and disconnection self-healing timing diagram; Figure 10 This is a timing diagram for dual-stack adaptive matching; Figure 11 Sequence diagram for inbound OPTIONS source address verification + high availability linkage. Detailed Implementation

[0020] In enterprise communication systems based on the Session Initiation Protocol (SIP), the core engine of an IPPBX (Internet Protocol Private Branch Exchange) needs to continuously monitor the online status of all registered SIP endpoints and trunks to ensure the accuracy of call routing decisions. The current industry practice is for the IPPBX to periodically send SIP OPTIONS requests to each contact and determine the reachability of that contact based on the received response code (e.g., 200 OK) or timeout event, thereby maintaining the health of the endpoints or trunks.

[0021] However, traditional SIP endpoint health detection and contact management solutions generally suffer from the following technical bottlenecks in actual deployment: First, the active scheduling lacks awareness of the registration status.

[0022] Traditional solutions indiscriminately send OPTIONS requests to all contacts configured with a probe frequency, even if the SIP trunk has not yet completed outbound registration. This not only leads to a large number of invalid probes consuming network bandwidth and protocol stack transaction resources, but may also cause OPTIONS responses from unregistered trunks to be misjudged as reachable, thus routing calls to trunk links that are actually unavailable.

[0023] Second, there is a waste of transaction resources after OPTIONS times out.

[0024] When the OPTIONS request times out for the first time, traditional solutions rely on the underlying protocol stack's transaction layer to continuously retransmit according to the exponential backoff strategy of the SIP specification. A single probe failure can generate up to seven invalid retransmissions. When a large number of terminals go offline simultaneously, the accumulated retransmission messages severely consume the protocol stack's transaction processing capacity and network bandwidth, while also delaying the final confirmation of the terminal's unreachable state.

[0025] In summary, existing SIP terminal health detection methods have significant shortcomings in terms of scheduling efficiency, resource utilization, and security, and there is an urgent need for an improved solution that can comprehensively address these issues.

[0026] Firstly, see [the following] Figure 1 This application provides a method for detecting the health of a SIP terminal, the method comprising: S101, when a contact has configured a liveness detection frequency, if the contact is registering successfully for the first time, the contact's status is directly marked as reachable, and no OPTIONS liveness detection request is sent.

[0027] The scheduling interval for the first liveness detection is generated by multiplying a random double-precision floating-point number by the configured liveness detection frequency, and is constrained by the global maximum initial liveness detection time parameter.

[0028] If the first health probes for all terminals occur simultaneously, it can cause instantaneous network congestion, exhaustion of protocol stack transaction resources, and service jitter. Therefore, the timing of the first health probes must be staggered. The random double-precision floating-point number is typically a double-precision random number between 0 and 1, such as 0.367. The probe frequency is, for example, once every 60 seconds. The product of the two is 22.02 seconds. If the global maximum initial health probe time parameter is 30 seconds, the calculated first health probe scheduling interval can be used. If the calculated first health probe scheduling interval is greater than the global maximum initial health probe time parameter of 30 seconds, then the global maximum initial health probe time parameter of 30 seconds is used as the first health probe scheduling interval. The scheduling interval for the first health probe is generated by multiplying the random double-precision floating-point number by the configured health probe period and is constrained by the global maximum initial health probe time parameter. This disperses the first probes of a large number of terminals across the time window, preventing a probe storm during system startup.

[0029] S102, otherwise, determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is loaded for the first time. If yes, asynchronously push the detection task to the dedicated thread pool and immediately detect the contact. If no, perform periodic scheduling according to the configured detection frequency.

[0030] Peer relay terminals do not require registration and directly trust each other via IP address and port. When the IPPBX starts up or after the administrator adds / modifies the configuration, the configuration needs to be loaded into memory to generate the corresponding contact object. If the configuration of the peer relay terminal is loaded for the first time, since it does not need to register, it can directly perform a liveness detection. Compared with the traditional solution that waits for the liveness detection cycle, this application directly pushes the liveness detection task asynchronously to a dedicated thread pool after determining that the configuration of the peer relay terminal is loaded for the first time, and performs liveness detection on the contact. The reachability status of the peer relay can be obtained in a very short time, improving the response speed.

[0031] Ordinary extensions or registration relays usually only start the activity detection process after successful registration. In this case, you just need to wait for the activity detection cycle to begin.

[0032] S103, In periodic scheduling, if the scheduling callback function detects that the terminal type of the contact is relay type and has not yet completed outbound registration, it returns to the next scheduling interval and skips the sending of the current round of detection request; otherwise, it pushes the detection task to a dedicated thread pool to detect the contact.

[0033] When the activation period arrives, for unregistered relay terminals, the current OPTIONS activation request is not sent, and the next scheduling interval is returned; otherwise, the activation task is pushed to a dedicated thread pool to activate the contact.

[0034] In the SIP terminal health detection subsystem, a registration status flag and a terminal type identifier are introduced to construct a four-level differentiated detection scheduling strategy. The system adds a Boolean registration status flag to the contact data structure to indicate whether the relay to which the contact belongs has successfully completed outbound registration. For relay-type terminals, when the registration status flag is false, even if the OPTIONS response arrives normally, the system forcibly reverts the contact status to "CREATED" instead of "AVAILABLE" to prevent unregistered relays from being mistakenly identified as available. At the periodic scheduling level, when the scheduling callback function detects that the registration status flag of a relay-type contact is false, it directly returns to the next scheduling interval and skips the current round of OPTIONS sending, eliminating invalid probes at the source. The registration status flag is updated dynamically by a self-developed status query function that detects the relay registration progress, setting the flag to true only when the relay is in a non-failure state. For contacts that successfully register for the first time, the system directly marks their status as available, skipping the network round-trip delay of the first OPTIONS probe. For peer-to-peer relay type terminals, the system immediately pushes the liveness detection task asynchronously to the task queue upon initial configuration loading, instead of waiting for the first liveness detection cycle. The system maintains a hash container with a prime number of buckets of 2^11 to store all scheduling data objects. Each object holds a scheduling identifier and a contact reference, and O(1) retrieval is achieved through the string hash of the contact identifier.

[0035] S104, send a SIP OPTIONS request to the contact to be explored and wait for a response.

[0036] When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

[0037] If the same account is registered on multiple devices, there will be one Address of Record (AoR) corresponding to multiple contact objects. In this application, the route with the lowest mean and variance of round-trip time can be used as the highest routing priority.

[0038] S105, when a normal response is received, the timeout counter corresponding to the contact is reset to zero; if the contact's terminal type is relay type and outbound registration has not been completed, the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable.

[0039] For unregistered relay terminals, even if the OPTIONS response arrives normally, the contact status will be forcibly rolled back to "CREATED" instead of "AVAILABLE".

[0040] S106, if the response times out or a transmission error occurs, the retransmission timer and timeout timer of the transaction corresponding to the OPTIONS request are canceled through the protocol stack timer heap interface, and the timeout event is rescheduled with a zero-delay value to forcibly terminate all subsequent retransmission attempts. The timeout counter of the contact is incremented, and the status of the contact is marked as unreachable.

[0041] In OPTIONS timeout handling, the system implements real-time resource reclamation at the protocol stack transaction layer. When an OPTIONS request triggers a timeout event (PJSIP_EVENT_TIMER) or a transmission error event (PJSIP_EVENT_TRANSPORT_ERROR), the callback function first obtains a reference to the current transaction object, then cancels the retransmission timer and timeout timer for that transaction sequentially through the protocol stack timer heap interface. Subsequently, it reschedules the timeout event with zero latency, forcibly terminating all subsequent retransmission attempts for the transaction. This mechanism reduces the number of network interactions for a single probe failure from a maximum of seven (initial transmission plus six exponential backoff retransmissions) in the traditional scheme to only one. At the task scheduling level, the system transfers all probe tasks from the default SIP serializer task queue to a dedicated thread pool (delivered via the thread pool push interface), avoiding blocking call establishment and registration transactions on the SIP signaling master serializer during OPTIONS processing. In scenarios requiring batch liveness detection, such as system restarts or configuration reloads, the system creates a separate daemon thread (with the PTHREAD_CREATE_DETACHED attribute) to asynchronously execute full terminal traversal and liveness detection scheduling, preventing the blocking of the main loading process of the SIP protocol stack.

[0042] This application provides a SIP terminal health detection method, comprising: when a contact has configured a detection frequency, if the contact has successfully registered for the first time, directly marking the contact's status as reachable, and not sending the current OPTIONS detection request; otherwise, determining whether the contact's terminal is a peer relay terminal and whether the peer relay terminal's configuration is being loaded for the first time, if yes, asynchronously pushing the detection task to a dedicated thread pool, and immediately detecting the contact's health; otherwise, periodically scheduling according to the configured detection frequency; during periodic scheduling, if the scheduling callback function detects that the contact's terminal type is relay type and has not yet completed outbound registration, returning to the next scheduling interval and skipping the sending of the current round of detection requests; otherwise, pushing the detection task to a dedicated thread pool, and detecting the contact's health; sending SIP messages to the contact to be detected. The system requests an OPTIONS request and waits for a response. Upon receiving a normal response, it resets the timeout counter for the contact to zero. If the contact's terminal type is relay and outbound registration has not yet been completed, the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. If the response times out or a transmission error occurs, the retransmission timer and timeout timer for the transaction corresponding to the OPTIONS request are canceled via the protocol stack timer heap interface. The timeout event is then rescheduled with zero latency to forcibly terminate all subsequent retransmission attempts. The contact's timeout counter is incremented, and the contact's status is marked as unreachable. This solution improves scheduling efficiency, resource utilization, and security.

[0043] In one example, sending a SIP OPTIONS request to the contact to be contacted includes: When it is detected that the terminal to which the contact belongs is configured with both IPv4 and IPv6 transmission names, a transmission mismatch callback function pointer is injected into the data sending object, and the terminal identifier of the contact is copied to the terminal name field of the data sending object. Determine whether the transmission protocol matches the address family of the target address. If they do not match, trigger the transmission mismatch callback function. The transmission mismatch callback function is used to rebind the data object to the correct transmission channel according to the address family of the target address.

[0044] For IPv4 / IPv6 dual-stack deployment environments, the system implements dynamic transport protocol adaptation for OPTIONS requests. When it detects that an endpoint is configured with both IPv4 and IPv6 transport names, the system injects a transport mismatch callback function pointer into the OPTIONS data object and copies the endpoint identifier to the endpoint name field of the data object. When the underlying protocol stack detects a mismatch between the selected transport protocol and the target address's address family during transmission, this callback function is triggered. The callback function retrieves the endpoint object from the configuration framework using the endpoint identifier and rebinds the data object to the correct transport channel via the transport name selection interface based on the target address family (IPv6 selects v6transport configuration, IPv4 selects v4transport configuration). In OPTIONS response processing, when a response is detected to arrive via the IPv6 transport layer, the system automatically sets the contact's IPv6 flag, providing an address family determination basis for subsequent RTP (Real-time Transport Protocol) media stream establishment. The default transport channel for the OPTIONS request is determined through the transport field configured on the endpoint, ensuring that probe messages and SIP signaling follow the same transport path.

[0045] In cloud deployments and SBC (Side Controller) relay scenarios, terminal SIP signaling is forwarded via the SBC. Traditional solutions cannot recognize connection interruptions at the SBC proxy layer; disconnected contacts are still marked as reachable, causing calls to be routed to invalid proxy paths.

[0046] In one example, if the response message carries a custom SIP header field, the IP address of the SBC proxy is extracted from the custom SIP header field and persisted to the proxy IP field of the contact object, and the status of the contact is marked as reachable; If the status code and reason phrase in the response message indicate that the SBC agent has been disconnected, clear the contacts connected to the SBC agent and cancel the liveness detection schedule for the contacts.

[0047] For cloud deployments and border session controller relay scenarios, deep awareness and automatic response of the SBC proxy layer are implemented. In OPTIONS response message processing, when a contact's endpoint type is detected as peer-to-peer, the system parses the custom SIP header field "ProxyIp" in the response message, extracts the actual IP address of the SBC proxy, and persists it to the contact object's proxy IP field via a string field setting interface. Simultaneously, the contact status object is expanded with both the registration URI and proxy IP fields, allowing cloud monitoring systems to track the extension's actual registration address and SBC proxy address. Regarding SBC disconnection detection, when the OPTIONS response status code is 501 and the first 16 bytes of the reason phrase exactly match "SBC NoConnection," the system determines that the SBC proxy has disconnected and immediately calls the configuration framework's delete interface to remove the contact, achieving immediate removal of disconnected contacts.

[0048] In terms of SBC handover detection, the system registers a contact update observer callback function. When the contact's URI field changes (indicating SBC address switching or failover), the system executes a complete reset process of "cancel current scheduling → delete old contact status → re-execute explore and scheduling" to ensure the immediate update of the target address after SBC handover.

[0049] In a multi-threaded environment, traditional solutions lack atomicity guarantees for the "lookup or creation" operation of contact status objects. Two threads may simultaneously detect that a certain contact status object does not exist and each create a new status object, leading to duplicate object leaks and inconsistent status data.

[0050] In one example, under the protection of a global static mutex lock, the identifier retrieval interface of the configuration framework is used to search for existing contact objects. If no contact object corresponding to the liveness detection task exists, it is created and persisted through the creation interface of the configuration framework. A custom destructor is bound to the created contact object to release the URI string, AoR identifier and proxy IP address when the reference count of the contact object reaches zero.

[0051] The "lookup or creation" operation for contact status objects is fully wrapped by a global static mutex lock: Under lock protection, an existing status object is first searched through the identifier retrieval interface of the configuration framework; if it does not exist, a new object is allocated within the same lock protection range and persisted through the creation interface of the configuration framework, ensuring that duplicate objects are not generated in multi-threaded concurrent scenarios. When allocating status objects, a custom destructor is bound through the extended configuration object allocation interface to ensure that all dynamic fields such as the URI string, AoR identifier, and proxy IP are accurately released when the reference count reaches zero.

[0052] Traditional solutions respond to inbound OPTIONS requests from any source with a 200 OK response, failing to distinguish between legitimate registered terminals and deceptive probe requests from unknown sources, posing security risks of information leakage and malicious state contamination.

[0053] In one example, the system receives an inbound OPTIONS request from the sender and retrieves all registered contacts under the sender's AoR. If the inbound OPTIONS request comes from a terminal of the extension type or an account type, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. If no match is found, the confirmation response will be rejected. If the inbound OPTIONS request comes from a terminal registered with a fully qualified domain name, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. A reverse DNS resolution will be performed on the IP address of the request source to determine whether the IP address of the request source is a valid resolution address of the fully qualified domain name. If it does not belong to the domain name and the match is unsuccessful, the confirmation response will be rejected. If the inbound OPTIONS request originates from a human endpoint, which is the default endpoint automatically assigned for requests whose origin cannot be identified, no response will be returned.

[0054] This application's embodiments construct a multi-layered security filtering and high-availability collaborative mechanism for inbound OPTIONS requests. For inbound OPTIONS requests from extension and account-type terminals, source address matching verification is performed: all registered contacts under the AoR to which the endpoint belongs are retrieved, and the IP address and port number of the request source are matched one by one through the source address comparison interface. If no match is found after traversing all registered contacts, the system refuses to reply with a 200 response to prevent unregistered devices from deceptively probing and obtaining server reachability information. For FQDN (Fully Qualified Domain Name) registration scenarios, OPTIONS requests from the domain name resolution address need to undergo additional source address verification to prevent illegal address probing when the domain name resolves to multiple IPs. The system also identifies human endpoints (default endpoints automatically assigned by the configuration framework for requests with unidentifiable sources), and directly returns no response for OPTIONS requests matched to human endpoints to avoid leaking server information to unknown sources.

[0055] In high-availability deployment scenarios, the system registers contact reload observer callbacks: when a HA (High Availability) event triggers contact reload, the observer automatically iterates through all contacts and re-executes the liveness detection and scheduling process to ensure timely updates to the reachability of terminals after a primary / standby switchover. In IPPBX high-availability deployments, there are typically two servers: a primary node and a standby node. When the primary node fails or experiences a network failure, the standby node switches to become the new primary node, handling all services, including sending outgoing OPTIONS requests and processing inbound OPTIONS requests. After the primary / standby switchover, the new primary node needs to reload the status of all contacts and restart the liveness detection and scheduling process.

[0056] For each of the four lifecycle events of an AoR object—creation, update, deletion, and HA reload—an independent observer callback is registered: during creation, update, and HA reload, the liveness detection is rescheduled; during deletion, the scheduling is canceled (the scheduling data is removed from the 211-bucket hash container) and the state is cleaned up (the contact state object is cleared through the configuration framework's deletion interface), ensuring scheduling consistency throughout the entire lifecycle of the contact.

[0057] The proposed solution is triggered by a contact lifecycle event. If the event type is deletion, the periodic scheduling of the contact is canceled, the scheduling data is removed from the 211-bucket hash container, and the contact status object is cleared through the configuration framework deletion interface. If the event type is creation / update / HA reload, then the registration-aware differentiated scheduling is entered.

[0058] See Figure 2 This is a schematic diagram of the registration-aware differentiated scheduling process. It checks if the contact has configured a probe frequency. If so, it checks if the contact is registering successfully for the first time. If so, it marks the contact as reachable, skipping the initial OPTIONS round-trip delay. Then, it checks if the contact is a peer relay terminal and is loading for the first time. If so, it immediately pushes the probe task asynchronously to a dedicated thread pool (with unequal periods). Otherwise, it performs probe detection according to the normal period. Afterward, it calculates a random initial probe interval, creates a scheduling data object (scheduling ID + contact reference linked into a 211-bucket hash scheduling container to start a periodic timer), and the timer triggers periodic callbacks. When the terminal type is relay and not registered, it skips the current round of OPTIONS sending and only returns the next scheduling interval, eliminating invalid probes at the source. When the terminal type is not relay or is already registered, it proceeds to step two: OPTIONS sending and transaction optimization.

[0059] See Figure 3This is a schematic diagram of the OPTIONS sending and transaction optimization process. First, the liveness detection task is pushed to a dedicated thread pool, and the microsecond-level round-trip timer start timestamp is recorded. When the endpoint is configured with both v4transport and v6transport, a transmission mismatch callback function pointer is injected into the data sending object, the endpoint identifier is copied to the endpointname field, and it is determined whether the transmission protocol and the target address family match. If they do not match, the endpoint configuration is queried, the correct transmission channel is rebound, and then a SIP OPTIONS request is sent—including transmission binding, outbound proxy, Support501, and To domain customization—and the OPTIONS response is awaited.

[0060] See Figure 4 This diagram illustrates the processing flow for response event types. For normal responses, the timeout counter is reset to zero, and the RTT (Round-Trip Time) is calculated. When the response arrives via IPv6 transmission, the contact's uriisi (IPv6 flag) is set to provide address family information for subsequent media streams. For unregistered terminals, the status is forced to fall back to CREATED to prevent unregistered relays from misjudging reachability. When an SBC disconnects, the configuration framework's delete interface is called to automatically clear the disconnected contact, and the contact's scheduling cleanup status object is canceled. If the response contains a ProxyIp header field, the actual IP of the SBC proxy is extracted, persisted to the contact's proxy-ip+reg-uri field, and the status is updated to reachable. In case of timeout or transmission error, the retransmission timer and timeout timer are canceled, and the timeout event is rescheduled with zero delay to forcibly terminate all subsequent retransmissions. Afterward, the timeout counter is incremented, and the status is updated to unreachable.

[0061] See Figure 5 This is a schematic diagram of the OPTIONS response security filtering process. When an external inbound OPTIONS request arrives, it checks whether it matches a human endpoint and whether the system is shutting down. If neither is true, it checks whether the terminal type is an extension / account. If so, it retrieves all registered contacts under the endpoint AoR and performs source address comparison one by one. If it is an FQDN registration scenario, additional FQDN address verification is required. If the source address matches successfully, a 200 OK response is sent, including Accept / Allow / Supported headers. If the terminal type is a relay or similar type, a 200 OK response is sent directly.

[0062] See Figure 6 This is the system initialization sequence diagram. The scheduling data container creates a registration hash function after the system starts. The contact lifecycle observer is used to bind to the contact object type in the configuration framework, and the AoR lifecycle observer is used to bind to the AoR object type in the configuration framework.

[0063] See Figure 7The process involves creating a sequence diagram for the contact. The SIP terminal device sends a SIPREGISTER message to the contact lifecycle observer, successfully triggering the contact creation event. The contact lifecycle observer then sends a call to the contact detection and scheduling function (carrying the contact object) to the differential scheduling strategy engine. The differential scheduling strategy engine checks the contact detection frequency configuration. If it is greater than 0, detection is required. For the first registration, the status is directly updated to reachable. For peer relays, the detection task is immediately pushed asynchronously to a dedicated thread pool. After that, a random initial detection interval is calculated, and a scheduling data object is created and linked into a 211-bucket hash container to start a periodic timer.

[0064] See Figure 8 This is a periodic liveness detection sequence diagram. The differentiated scheduling strategy engine is triggered by a timer to periodically detect liveness through callbacks. First, it checks if the terminal type is a relay and unregistered. For unregistered relays, it returns the interval; for registered or non-relay relays, it pushes the liveness detection task to a dedicated thread pool. The dedicated thread pool task delivery records the microsecond-level round-trip timer start timestamp and sends SIP OPTIONS requests (including transport binding / outbound proxy / Support501 header field / To domain customization) to the SIP protocol stack transaction layer. Upon receiving a normal response, the SIP protocol stack transaction layer resets the timeout counter to zero and calculates the RTT. The concurrent security state manager sets the unregistered relay state to CREATED and the normally reachable state to reachable. When the SIP protocol stack transaction layer receives a timeout or transmission error, it retrieves the transaction object reference, cancels the retransmission timer and timeout timer, terminates all subsequent retransmissions with zero delay, then increments the timeout counter, and the concurrent security state manager sets the state to unreachable.

[0065] See Figure 9 The sequence diagram for SBC proxy tracing and disconnection self-healing is as follows: The SBC border session controller sends an OPTIONS response with a custom ProxyIp header field to the SIP protocol stack transaction layer. The SIP protocol stack transaction layer parses the header field, persists it to the contact's proxy-ip, and updates the reg-uri field. The SBC border session controller then sends an OPTIONS response with status code 501 + "SBC NoConnection" to the SIP protocol stack transaction layer. The SIP protocol stack transaction layer calls the configuration framework's delete interface to clear the disconnected contact and cancels the contact's scheduling cleanup state object. Finally, the SBC border session controller sends a message to the contact lifecycle observer that the contact's URI has changed. The contact lifecycle observer cancels the current scheduling, deletes the old contact state, and re-executes the reactivation and scheduling process.

[0066] See Figure 10This is a dual-stack adaptive matching sequence diagram. The dedicated thread pool task delivery sends an OPTIONS request to the SIP protocol stack transaction layer. If the SIP protocol stack transaction layer detects a mismatch between the transport protocol and the target address family, it rebinds the correct transport channel. When the SIP terminal device sends an OPTIONS response arriving via IPv6, the SIP protocol stack transaction layer sets the uriisi ipv6 flag.

[0067] See Figure 11 This is a sequence diagram for inbound OPTIONS source address verification and high availability linkage. Upon receiving an inbound OPTIONS request, the source address verification guard identifies the endpoint type, retrieves all registered contacts under AoR, and performs source address comparisons one by one: if the source address matches, a 200 OK response is sent; if the source address does not match, the response is rejected; manual endpoints do not respond. When the high availability reload linkage receives a high availability primary / standby switchover event, it triggers a contact reload callback to the contact lifecycle observer. Then, the contact lifecycle observer iterates through all contacts, re-executing scheduling and liveness detection.

[0068] Existing IPPBX systems employ indiscriminate periodic OPTIONS probes, failing to differentiate between terminal registration status and type. After timeout, they rely on the protocol stack's default exponential backoff retransmission strategy. This lack of concurrent security guarantees for contact status management and inability to detect connection changes at the SBC proxy layer further complicates matters. This invention introduces a registration status-aware four-level differentiated scheduling strategy to eliminate invalid probes from unregistered terminals at the source. It reduces invalid network interactions after timeout to zero by immediately canceling retransmission timers at the protocol stack transaction layer. It constructs a mutex-protected atomic state creation and custom destructor to ensure zero leakage. It achieves a cloud-edge collaborative closed loop for SBC proxy IP tracking, automatic disconnection eviction, and handover rescheduling. Finally, it deploys source address verification guards and high-availability linkage to ensure the security and continuity of the probe system.

[0069] Beneficial effects: 1. The consumption of active resources has been significantly reduced.

[0070] Registration-aware scheduling skips invalid probes from unregistered relays, transaction-level instant cancellation of retransmissions reduces redundant network interactions after timeouts from the traditional six times to zero times, and dedicated thread pool isolation avoids blocking signaling processing during liveness detection. The three working together can reduce the network and computing resource consumption of the liveness detection system by more than 70%.

[0071] 2. Zero leakage and zero race conditions in contact status management.

[0072] Atomic "lookup or create" operations protected by global mutex locks completely eliminate duplicate object creation in multi-threaded concurrent scenarios. Custom destructor binding ensures accurate reclamation of all dynamic fields, and a per-contact timeout counter provides quantitative health metrics for upper-layer business.

[0073] 3. Real-time detection and automatic recovery of SBC disconnection.

[0074] Millisecond-level detection of SBC disconnection and automatic contact eviction are achieved through precise matching of 501 signature response codes. Contact URI change detection enables instant switching of the live target after SBC failover. ProxyIp header field resolution supports full-link proxy tracing in cloud monitoring systems.

[0075] 4. Zero-configuration adaptation for IPv4 / IPv6 dual-stack.

[0076] The transmission mismatch callback function enables automatic switching of OPTIONS requests between IPv4 and IPv6 transmission channels. The IPv6 response is automatically marked to provide address family basis for the establishment of subsequent media streams, eliminating the need for maintenance personnel to manually configure dual-stack liveness detection strategies.

[0077] 5. OPTIONS response security and high availability continuity.

[0078] Source address matching verification rejects deceptive probes from unregistered sources; manual endpoint filtering prevents information leakage to unknown sources; high-availability heavy-load observers ensure timely updates of the status of all terminals after primary / standby failover; and AoR lifecycle observers guarantee scheduling consistency.

[0079] In deployment scenarios with a large number of terminals, the probe frequency can be dynamically adjusted based on the overall system's OPTIONS success rate and RTT trend. When a decrease in OPTIONS success rate or a significant increase in RTT is detected (indicating network congestion), the system automatically extends the probe interval to reduce probe traffic load; when network conditions recover, it gradually returns to the normal probe frequency. This adaptive mechanism can reduce bandwidth contention for service signaling by probe traffic during network congestion, improving the overall stability of the system under adverse network conditions.

[0080] Secondly, embodiments of this application provide a SIP terminal health detection device, the device comprising: The first scheduling module is used to mark the status of a contact as reachable and not send the OPTIONS liveness detection request if the contact has configured a liveness detection frequency and the contact has successfully registered for the first time. The second scheduling module is used to determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is being loaded for the first time. If yes, the activation detection task is asynchronously pushed to a dedicated thread pool and the contact is immediately activated. If no, the activation detection is periodically scheduled according to the configured activation detection frequency. The third scheduling module is used to, during periodic scheduling, if the scheduling callback function detects that the terminal type of the contact is a relay type and has not yet completed outbound registration, return to the next scheduling interval and skip the sending of the current round of detection request; otherwise, push the detection task to a dedicated thread pool to detect the contact. The sending module is used to send a SIP OPTIONS request to the contact to be contacted and wait for a response; The first processing module is used to reset the timeout counter corresponding to the contact to zero when a normal response is received; if the contact's terminal type is relay type and outbound registration has not been completed, then the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. The second processing module is used to cancel the retransmission timer and timeout timer of the transaction corresponding to the OPTIONS request through the protocol stack timer heap interface if the response times out or a transmission error occurs, reschedule the timeout event with a zero-delay value to forcibly terminate all subsequent retransmission attempts, increment the timeout counter of the contact, and mark the status of the contact as unreachable.

[0081] In one possible implementation, the device further includes a routing module for: When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

[0082] In one possible implementation, the device further includes a special processing module for: If the response message carries a custom SIP header field, extract the IP address of the SBC proxy from the custom SIP header field and persist the IP address to the proxy IP field of the contact object, and mark the status of the contact as reachable; If the status code and reason phrase in the response message indicate that the SBC agent has been disconnected, clear the contacts connected to the SBC agent and cancel the liveness detection schedule for the contacts.

[0083] In one possible implementation, the apparatus further includes a creation module for: Under the protection of a global static mutex lock, the existing contact object is searched through the identifier retrieval interface of the configuration framework. If no contact object corresponding to the liveness detection task exists, it is created and persisted through the creation interface of the configuration framework. A custom destructor is bound to the created contact object to release the URI string, AoR identifier and proxy IP address when the reference count of the contact object reaches zero.

[0084] In one possible implementation, the apparatus further includes an inbound processing module for: Receive inbound OPTIONS requests from the sender and retrieve all registered contacts under the sender's AoR; If the inbound OPTIONS request comes from a terminal of the extension type or an account type, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. If no match is found, the confirmation response will be rejected. If the inbound OPTIONS request comes from a terminal registered with a fully qualified domain name, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. A reverse DNS resolution will be performed on the IP address of the request source to determine whether the IP address of the request source is a valid resolution address of the fully qualified domain name. If it does not belong to the domain name and the match is unsuccessful, the confirmation response will be rejected. If the inbound OPTIONS request originates from a human endpoint, which is the default endpoint automatically assigned for requests whose origin cannot be identified, no response will be returned.

[0085] Thirdly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described SIP terminal health detection methods.

[0086] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0087] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0088] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are described simply because they are similar to the method embodiments; relevant parts can be referred to the descriptions of the method embodiments.

[0089] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for detecting the health and activity of a SIP terminal, characterized in that, The method includes: When a contact has a liveness detection frequency configured, if the contact is registering successfully for the first time, the contact's status will be marked as reachable directly, and no OPTIONS liveness detection request will be sent. Otherwise, determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is being loaded for the first time. If yes, asynchronously push the detection task to the dedicated thread pool and immediately detect the contact. If no, perform periodic scheduling according to the configured detection frequency. In periodic scheduling, if the scheduling callback function detects that the contact's terminal type is relay and has not yet completed outbound registration, it returns to the next scheduling interval and skips the sending of the current round of activation request; otherwise, it pushes the activation task to a dedicated thread pool to activate the contact. Send a SIP OPTIONS request to the contact to be contacted and wait for a response; When a normal response is received, the timeout counter corresponding to the contact is reset to zero; if the contact's terminal type is relay type and outbound registration has not yet been completed, the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. If a response times out or a transmission error occurs, the retransmission timer and timeout timer for the transaction corresponding to the OPTIONS request are canceled through the protocol stack timer heap interface. The timeout event is then rescheduled with a zero-delay value to forcibly terminate all subsequent retransmission attempts. The timeout counter for the contact is incremented, and the contact's status is marked as unreachable.

2. The method according to claim 1, characterized in that, The method further includes: When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

3. The method according to claim 1, characterized in that, Sending a SIPOPTIONS request to the contact to be explored includes: When it is detected that the terminal to which the contact belongs is configured with both IPv4 and IPv6 transmission names, a transmission mismatch callback function pointer is injected into the data sending object, and the terminal identifier of the contact is copied to the terminal name field of the data sending object. Determine whether the transmission protocol matches the address family of the target address. If they do not match, trigger the transmission mismatch callback function. The transmission mismatch callback function is used to rebind the data object to the correct transmission channel according to the address family of the target address.

4. The method according to claim 1, characterized in that, The method further includes: If the response message carries a custom SIP header field, extract the IP address of the SBC proxy from the custom SIP header field and persist the IP address to the proxy IP field of the contact object, and mark the status of the contact as reachable; If the status code and reason phrase in the response message indicate that the SBC agent has been disconnected, clear the contacts connected to the SBC agent and cancel the liveness detection schedule for the contacts.

5. The method according to claim 1, characterized in that, The scheduling interval for the first liveness detection is generated by multiplying a random double-precision floating-point number by the configured liveness detection frequency, and is constrained by the global maximum initial liveness detection time parameter.

6. The method according to claim 1, characterized in that, The method further includes: Under the protection of a global static mutex lock, the existing contact object is searched through the identifier retrieval interface of the configuration framework. If no contact object corresponding to the liveness detection task exists, it is created and persisted through the creation interface of the configuration framework. A custom destructor is bound to the created contact object to release the URI string, AoR identifier and proxy IP address when the reference count of the contact object reaches zero.

7. The method according to claim 1, characterized in that, The method further includes: Receive inbound OPTIONS requests from the sender and retrieve all registered contacts under the sender's AoR; If the inbound OPTIONS request comes from a terminal of the extension type or an account type, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. If no match is found, the confirmation response will be rejected. If the inbound OPTIONS request comes from a terminal registered with a fully qualified domain name, the IP address and port number of the request source will be matched one by one with the IP address and port number of all registered contacts. A reverse DNS resolution will be performed on the IP address of the request source to determine whether the IP address of the request source is a valid resolution address of the fully qualified domain name. If it does not belong to the domain name and the match is unsuccessful, the confirmation response will be rejected. If the inbound OPTIONS request originates from a human endpoint, which is the default endpoint automatically assigned for requests whose origin cannot be identified, no response will be returned.

8. A SIP terminal health detection device, characterized in that, The device includes: The first scheduling module is used to mark the status of a contact as reachable and not send the OPTIONS liveness detection request if the contact has configured a liveness detection frequency and the contact has successfully registered for the first time. The second scheduling module is used to determine whether the terminal to which the contact belongs is a peer relay terminal and whether the configuration of the peer relay terminal is being loaded for the first time. If yes, the activation detection task is asynchronously pushed to a dedicated thread pool and the contact is immediately activated. If no, the activation detection is periodically scheduled according to the configured activation detection frequency. The third scheduling module is used to, during periodic scheduling, if the scheduling callback function detects that the terminal type of the contact is a relay type and has not yet completed outbound registration, return to the next scheduling interval and skip the sending of the current round of detection request; otherwise, push the detection task to a dedicated thread pool to detect the contact. The sending module is used to send a SIP OPTIONS request to the contact to be contacted and wait for a response; The first processing module is used to reset the timeout counter corresponding to the contact to zero when a normal response is received; if the contact's terminal type is relay type and outbound registration has not been completed, then the contact's status is marked as unreachable; otherwise, the contact's status is marked as reachable. The second processing module is used to cancel the retransmission timer and timeout timer of the transaction corresponding to the OPTIONS request through the protocol stack timer heap interface if the response times out or a transmission error occurs, reschedule the timeout event with a zero-delay value to forcibly terminate all subsequent retransmission attempts, increment the timeout counter of the contact, and mark the status of the contact as unreachable.

9. The apparatus according to claim 8, characterized in that, The device further includes a routing module for: When sending a SIP OPTIONS request to the contact to be monitored, record the microsecond-level timestamp of the sending time; When a normal response is received, calculate the difference between the current time and the recorded timestamp as the round-trip time delay for that contact, and store the round-trip time delay. When there are multiple reachable contacts for the same AoR, the routing priority is calculated based on the mean and variance of the round-trip latency of each contact, and the contact with the lowest latency and the most stable connection is selected for call routing.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images