A method and device for adaptive notification and automatic management of the life cycle of SIP message waiting indication
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAMEN XINGZONG DIGITAL TECH CO LTD
- Filing Date
- 2026-04-03
- Publication Date
- 2026-07-21
Smart Images
Figure CN122437835A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of IP multimedia communication technology, and in particular to a method and apparatus for adaptive notification of SIP message waiting indication and automatic management of subscription lifecycle. Background Technology
[0002] In enterprise communication systems, Message Waiting Indication (MWI) is the core mechanism for notifying end users of unread messages in their voicemail. The SIP protocol defines two MWI notification modes: request-based notification, where the terminal actively sends a SUBSCRIBE request to establish a conversation-level subscription, and the system sends a NOTIFY notification within the conversation; and push-based notification, where the system proactively sends a NOTIFY notification without requiring a conversation subscription from the terminal. These two modes differ fundamentally at the SIP protocol level—request-based notifications carry a conversation identifier, while push-based notifications must be sent without a conversation; otherwise, the terminal will reject the notification with a 481 (conversation not found) error.
[0003] Traditional SIP engines typically employ a single container to hybridize subscription objects across two modes for MWI notification management. This design suffers from three serious flaws: First, when both request-based and push-based subscriptions exist simultaneously on the same endpoint, the system cannot effectively arbitrate their priority, leading to duplicate notifications or lost notifications. Second, configuring hot reload requires a complete destruction and reconstruction of all subscriptions, resulting in the loss of mailbox state changes occurring during the reconstruction interval. Third, after request-based subscriptions are closed, the system cannot automatically resume push notifications; MWI functionality can only be restored after the next configuration reload or terminal re-registration. These issues are particularly pronounced in large-scale deployment scenarios (thousands of terminals, mixed multi-vendor devices), severely impacting the reliability and real-time performance of voicemail notifications.
[0004] Therefore, how to achieve automatic arbitration of dual-mode notifications and complete management of the subscription lifecycle, eliminate duplicate notifications and subscription gaps, and improve the reliability and real-time performance of MWI notifications are problems that need to be solved by those skilled in the art. Summary of the Invention
[0005] This invention provides a method and apparatus for adaptive notification of SIP message waiting indication and automatic management of subscription lifecycle, which can solve problems such as duplicate notifications caused by dual-mode subscription hybrid storage, loss of state when configuring hot reload, and inability to automatically recover push notifications after request subscription is closed in the prior art.
[0006] The first aspect of this invention provides a method for adaptive notification of SIP message wait indication and automatic management of subscription lifecycle, comprising:
[0007] Construct a dual-mode container divide-and-conquer isolation architecture, creating independent request-based subscription containers and proactive push-based subscription containers. The request-based subscription container is used to manage request-based subscription objects, and the proactive push-based subscription container is used to manage proactive push-based subscription objects. When it is necessary to create or receive message waiting instruction subscriptions for an endpoint, a three-level mode conflict arbitration is performed, and admission detection, preemption replacement and automatic recovery are performed between request subscription containers and proactive push subscription containers to ensure that only one notification mode exists for the same endpoint and the same mailbox at any time. When the system configuration changes and the message waiting indication subscription needs to be reloaded, a three-stage mark-sweep hot reload is performed to mark all subscription objects in the proactive push subscription container, rebuild each endpoint, and clear the remnants so that there are no subscription blank windows during the hot reload. For each message waiting instruction subscription object, a two-level subscription hierarchy is constructed. The outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key. Register a contact observer in the persistent object management framework to listen for contact creation and update events. When the terminal registers, automatically create an active push subscription for the endpoint and send initial notifications in batches via asynchronous tasks after the system starts up. During the module unloading phase, the active push subscription container is traversed sequentially to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription handler to complete the safe release of resources.
[0008] Optionally, a three-tiered conflict arbitration process may be implemented, including: During the admission detection phase, when attempting to create an active push subscription for an endpoint, the system checks whether a subscription for that endpoint already exists in the active push subscription container. If it does, creation is rejected. The system also checks whether a request subscription for that endpoint exists in the request subscription container. If it does, and the endpoint has a request preemption policy configured, creation of the push subscription is rejected. If a request subscription exists but no request preemption policy is configured, the request subscription is terminated before push subscription creation is allowed. During the preemption and replacement phase, when a subscription request to establish a request-based subscription is received from a terminal, it is checked whether the subscription for that endpoint exists in the active push subscription container. If it exists and the endpoint has been configured with a request-based preemption strategy, the event bus listening for the push subscription is canceled, the mailbox entry is removed from the event bus sub-container, the subscription object is removed from the active push subscription container, and the request-based subscription is allowed to be established. During the automatic recovery phase, when a request subscription is closed, the subscription object is removed from the request subscription container. It is then checked whether there are any other subscriptions for the endpoint in the request subscription container. If not, an active push subscription is automatically created for the endpoint.
[0009] Optionally, perform a three-stage zero-gap thermal overload with marking and cleaning, including: During the full marking phase, under the protection of the global lock of the proactive push subscription container, all subscription objects in the container are traversed, and the deletion flag of each subscription object is set to the state of pending deletion. During the endpoint reconstruction phase, all endpoint configurations in the system are traversed. If the endpoint already has a subscription in the request subscription container, it is skipped. If the endpoint already has a subscription in the push subscription container, its deletion flag is cleared. If neither exists, a new push subscription is created for the endpoint and linked into the container. During the cleanup phase, the active push subscription container is traversed again, subscription objects whose deletion flag is still set to be deleted are removed, their event bus listeners are canceled, and their resources are released.
[0010] Optionally, a second-level subscription hierarchy is constructed for each message wait indicator subscription object, including: The outer subscription object stores the corresponding pattern container with the endpoint unique identifier as the key, holding the SIP subscription reference, the address record list and the aggregation pattern flag; The inner event bus subscription sub-container uses the mailbox identifier as the key, and each entry holds an event bus subscription handle. When the mailbox state changes, the event bus callback function is triggered, and the notification sending task is delivered to the corresponding serializer queue through the serializer asynchronous task push mechanism.
[0011] Optionally, register a contact observer in the persistent object management framework, including: Register a contact observer in the persistent object management framework to listen for contact creation and update events. When the terminal registration triggers contact creation, check the endpoint. If the endpoint does not have a push subscription, create the contact automatically. When a contact is updated, a message waiting instruction notification is triggered on the endpoint so that the terminal receives the latest mailbox status immediately after registration. During the system startup phase, listen for the full startup event of the system manager. Once all system modules have finished loading and report a full startup, send the initial notifications of all push subscriptions in batches through an asynchronous task push mechanism. In the contact observer callback and notification sending function, pre-filtering is performed on terminal types that do not support the display of message waiting indication, skipping invalid notification sending.
[0012] Optionally, the method further includes: During the system startup phase, the system waits for the initial message to be sent by listening to the full startup event of the system manager. Once all system modules have been loaded and a full startup is reported, the initial notifications of all push subscriptions are sent in batches through an asynchronous task push mechanism.
[0013] Optionally, resource safety release is completed during the module unloading phase, including: Iterate through the active push subscription container, cancel all event bus subscriptions and remove all subscription objects; Release the reference count of the proactive push subscription container; Remove the contact observer from the persistent object management framework; Release the reference count of the request-based subscription container; Cancel the SIP subscription processor.
[0014] A second aspect of the present invention provides a device for adaptive notification of SIP message wait indication and automatic management of subscription lifecycle, comprising: The container building unit is used to build a dual-mode container divide-and-conquer isolation architecture, creating independent request-subscribe containers and push-subscribe containers. The request-subscribe container is used to manage request-subscribe objects, and the push-subscribe container is used to manage push-subscribe objects. The conflict arbitration unit is used to perform three-level mode conflict arbitration when it is necessary to create or receive message waiting instruction subscriptions for an endpoint. It performs admission detection, preemption replacement and automatic recovery between request subscription containers and push subscription containers to ensure that only one notification mode exists for the same endpoint and the same mailbox at any time. The hot reload unit is used to perform a mark-sweep three-stage zero-gap hot reload when the system configuration changes and the message waiting indication subscription needs to be reloaded. It performs full marking, endpoint reconstruction and cleanup of the subscription objects in the active push subscription container to ensure that there are no subscription blank windows during the hot reload. The hierarchical building unit is used to build a two-level subscription hierarchy for each message waiting indication subscription object. The outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key. The observer registration unit is used to register contact observers in the persistent object management framework, listen for contact creation and update events, automatically create proactive push subscriptions for endpoints when the terminal registers, and send initial notifications in batches through asynchronous tasks after the system starts up; The resource release unit is used during the module unloading phase to sequentially traverse the proactive push subscription container to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription handler to complete the safe release of resources.
[0015] A third aspect of the present invention provides a device for adaptive notification of SIP message wait indication and automatic management of subscription lifecycle, comprising: One or more processors; A memory on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the SIP message wait indication adaptive notification and subscription lifecycle automatic management method as described in any of the above.
[0016] A fourth aspect of the present invention provides a computer storage medium for storing a program, which, when executed, implements the SIP message wait indication adaptive notification and subscription lifecycle automatic management method as described in any of the preceding claims.
[0017] Beneficial effects: This invention achieves physical isolation through independent request-based subscription containers and proactive push-based subscription containers. Only one notification mode exists for the same endpoint and mailbox at any given time, and the terminal will not receive duplicate MWI notifications from both modes, ensuring that the mailbox status display is always accurate.
[0018] This invention employs a three-tiered arbitration mechanism—access detection, preemptive replacement, and automatic recovery—to ensure that the system automatically reverts to push notifications after request-based subscriptions are closed, without waiting for configuration reload or terminal re-registration. This reduces the MWI function recovery time from minutes to milliseconds.
[0019] This invention adopts a three-stage strategy of marking and cleaning to replace the traditional "full destruction-full reconstruction" scheme. It only removes subscriptions that really need to be deleted and retains subscriptions that are still valid. This ensures that all mailbox status changes can be correctly captured and notified during configuration changes. In large-scale deployment scenarios, configuration reload will not cause any terminal's MWI status to be temporarily invalidated.
[0020] This invention reduces the peak load of SIP transactions during system startup by delaying the initial notification sending during the system's full startup event. At the same time, it performs pre-filtering for terminal types that do not support MWI display, avoiding resource waste and network congestion caused by a large number of invalid NOTIFY messages. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a flowchart illustrating a method for adaptive notification of SIP message waiting indication and automatic management of subscription lifecycle provided in an embodiment of the present invention. Figure 2This is a schematic diagram of the structure of a SIP message waiting indication adaptive notification and subscription lifecycle automatic management device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation
[0023] This invention provides a method and apparatus for adaptive SIP message wait indication (MWI) notification and automatic subscription lifecycle management, applied to a self-developed high-concurrency IPPBX core communication routing engine. It provides a dual-mode adaptive distribution and automatic subscription lifecycle management method for SIP message wait indication (MWI) notifications. Through a collaborative design of container-level physical isolation, mode-level conflict arbitration, and subscription-level automatic recovery, fully automatic lifecycle management of MWI notifications is achieved.
[0024] See Figure 1 This figure is a flowchart illustrating a SIP message wait indication adaptive notification and subscription lifecycle automatic management method provided by an embodiment of the present invention. The SIP message wait indication adaptive notification and subscription lifecycle automatic management method provided by this embodiment of the present invention can be implemented, for example, through the following steps S101-106.
[0025] S101: Construct a dual-mode container divide-and-conquer isolation architecture.
[0026] In this embodiment of the invention, separate request-based subscription containers and push-based subscription containers are created, wherein the request-based subscription container is used to manage request-based subscription objects, and the push-based subscription container is used to manage push-based subscription objects.
[0027] Specifically, a dual-mode container divide-and-conquer isolation architecture is constructed. During the module initialization phase, two independent hash containers are created to manage subscription objects for the two MWI notification modes respectively: Request-based subscription container: A hash container protected by a mutex lock. The number of buckets is configured differently based on the deployment scale (573 buckets for large-scale deployment, 53 buckets for standard deployment). It stores in-session subscription objects triggered by external SUBSCRIBE requests. Each subscription object uses an endpoint unique identifier as the hash key and embeds a 13-bucket event bus subscription sub-container. Each sub-container entry corresponds to a mailbox's status listener.
[0028] Active push subscription container: Uses a hash container of the same specifications to store non-dialogue push subscription objects actively created by the system. Its internal structure is consistent with that of a request-based subscription object, but it does not hold SIP dialogue references.
[0029] The two containers are completely independent in terms of creation, destruction, lock protection, and traversal operations, achieving physical isolation between the two notification modes of request and push.
[0030] In one implementation of this invention, in a high-availability dual-machine hot standby deployment scenario, the dual-mode container state of the primary node can be replicated to the standby node in real time through a subscription state synchronization mechanism between the primary and standby nodes. When the primary node fails and switches over, the standby node can immediately take over all MWI subscriptions and resume notification services without waiting for terminals to re-register, achieving zero-interruption failover for MWI notifications.
[0031] S102: When it is necessary to create or receive a message waiting instruction subscription for an endpoint, perform a three-level mode conflict arbitration.
[0032] In this embodiment of the invention, admission detection, preemption replacement, and automatic recovery are performed between the request-based subscription container and the proactive push subscription container to ensure that only one notification mode exists for the same endpoint and the same mailbox at any given time.
[0033] During the admission detection phase, when attempting to create an active push subscription for an endpoint, the system checks if a subscription for that endpoint already exists in the active push subscription container. If it does, creation is rejected. It then checks if a request subscription for that endpoint exists in the request subscription container. If it exists and the endpoint has a request preemption policy configured, push subscription creation is rejected. If a request subscription exists but no request preemption policy is configured, the request subscription is terminated before push subscription creation is allowed. During the preemption replacement phase, when a subscription request to establish a request subscription is received from a terminal, the system checks if a subscription for that endpoint exists in the active push subscription container. If it exists and the endpoint has a request preemption policy configured, the event bus listener for the push subscription is canceled, the mailbox entry is removed from the event bus sub-container, and the subscription object is removed from the active push subscription container, allowing request subscription establishment. During the automatic recovery phase, when a request subscription is closed, the subscription object is removed from the request subscription container, and the system checks if any other subscriptions for that endpoint exist in the request subscription container. If none exist, an active push subscription is automatically created for the endpoint.
[0034] Specifically, a three-tiered notification mode conflict arbitration engine is implemented. When creating or accepting an MWI subscription for an endpoint, the following three-tiered arbitration mechanism ensures that only one notification mode exists for the same endpoint and mailbox at any given time: Admission detection: When attempting to create a push subscription for an endpoint, the system first checks if a subscription for that endpoint already exists in the push container. If it does, creation is rejected to prevent duplicate subscriptions. Then, it checks the request container. If a request subscription exists and the endpoint is configured with a "request-based preemption" policy, push subscription creation is rejected. If a request subscription exists but no preemption policy is configured, the request subscription is actively terminated (by setting a termination flag and sending a NOTIFY status), and then push subscription creation is allowed.
[0035] Preemption and Replacement: When an endpoint sends a SUBSCRIBE request to establish a request-based subscription, it checks whether the subscription for that endpoint and mailbox exists in the proactive push container. If it exists and the endpoint is configured with a "request-based preemption" policy, a three-step preemption operation is performed: canceling the event bus listener for the push subscription, removing the mailbox entry from the event bus sub-container, and removing the subscription object from the proactive push container. After preemption is complete, request-based subscription establishment is allowed.
[0036] Automatic recovery: When a request-based subscription is closed due to terminal logout, timeout, or active cancellation, the subscription object is removed from the request container. Then, it is checked whether any other subscriptions for that endpoint exist in the request container. If none exist, an active push subscription is automatically created for that endpoint, restoring MWI notification capabilities and ensuring zero loss during mode switching.
[0037] In one implementation of this invention, the three-level conflict arbitration engine is extended to a general arbitration framework supporting multi-level priorities. This framework is not only applicable to the request-based and push-based modes of MWI, but can also be extended to multi-mode notification management of other SIP event packets (such as BLF device status and online status). Each mode is configured with an independent priority weight, and the arbitration engine automatically selects the optimal notification mode based on the weight.
[0038] S103: When the system configuration changes and a reload message waiting instruction subscription is required, perform a three-stage zero-gap hot reload of the mark-sweep process.
[0039] In this embodiment of the invention, the subscription objects in the proactive push subscription container are fully marked, reconstructed endpoint by endpoint, and residuals are cleared so that there are no subscription blank windows during hot reload.
[0040] During the full marking phase, under the global lock protection of the proactive push subscription container, all subscription objects in the container are traversed, and the deletion flag of each subscription object is set to the pending deletion state. During the endpoint reconstruction phase, all endpoint configurations in the system are traversed. If the endpoint already has a subscription in the request subscription container, it is skipped. If the endpoint already has a subscription in the proactive push subscription container, its deletion flag is cleared. If none of them exist, a new push subscription is created for the endpoint and linked into the container. During the cleanup phase, the proactive push subscription container is traversed again, subscription objects whose deletion flag is still in the pending deletion state are removed, their event bus listeners are canceled, and resources are released.
[0041] Specifically, a three-stage, zero-gap hot reload is implemented, consisting of marking and sweeping. When a configuration change necessitates reloading the MWI subscription, this invention employs the following three-stage strategy to replace the traditional "full destruction-full reconstruction" approach: Full Marking: Under the global lock protection of the proactive push container, traverse all subscribed objects in the container and set the deletion flag of each object to the "to be deleted" state.
[0042] Reconstructing endpoints one by one: Traverse all endpoint configurations in the system and perform the following checks on each endpoint: If the endpoint already has a subscription in the request container, skip it (request priority); if the endpoint already has a subscription in the push container, clear its deletion flag (mark it as "retain"); if neither exists, create a new push subscription and link it into the container.
[0043] Clean up remnants: Iterate through the proactive push container again, remove only subscription objects whose deletion flag is still "to be deleted" (i.e., subscriptions corresponding to endpoints that have been removed in the configuration), cancel their event bus listeners and release resources.
[0044] The three phases are executed consecutively under the protection of a global lock in the container, ensuring that there is no subscription blank window during hot reload and that any mailbox state changes that occur during the reload process can be correctly captured and notified.
[0045] In one implementation of this invention, the three-stage hot reload of marking-sweeping is further optimized into incremental reload: maintaining a set of configuration change differences (adding endpoint list, deleting endpoint list, modifying endpoint list), performing subscription creation or destruction operations only on endpoints in the difference set, skipping the traversal of unchanged endpoints, and further reducing the computational overhead of hot reload in ultra-large-scale deployment scenarios.
[0046] S104: Build a second-level subscription hierarchy for each message wait indication subscription object.
[0047] In this embodiment of the invention, the outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key.
[0048] The outer subscription object is stored in the corresponding pattern container with the endpoint unique identifier as the key, holding a SIP subscription reference, an address record list, and an aggregation pattern flag; the inner event bus subscription sub-container uses the mailbox identifier as the key, and each entry holds an event bus subscription handle. When the mailbox state changes, the event bus callback function is triggered, and the notification sending task is delivered to the corresponding serializer queue through the serializer asynchronous task push mechanism.
[0049] Specifically, a two-level subscription hierarchy and an event bus are asynchronously driven. Each MWI subscription object is organized using a two-level hierarchical structure: The outer subscription object stores the corresponding pattern container (request-based or push-based) with the endpoint unique identifier as the key, and holds metadata such as SIP subscription reference (request-only), address record list, and aggregation pattern flag.
[0050] The inner event bus subscription sub-container (13 buckets of hashes) uses the mailbox identifier as the key, and each entry holds an event bus subscription handle. When the mailbox state changes, the event bus callback function is triggered, and the NOTIFY send task is delivered to the corresponding serializer queue through the serializer asynchronous task push mechanism. Request-based subscriptions use the serializer bound to the SIP subscription to ensure the order of messages within the conversation, while push-based subscriptions use the global serializer.
[0051] It supports two subscription strategies: aggregation mode and independent mode. In aggregation mode, a single outer subscription object covers all mailboxes configured on the endpoint, and the message counts of all mailboxes are summarized in the NOTIFY message; in independent mode, an outer subscription object is created independently for each mailbox.
[0052] S105: Register a contact observer in the persistent object management framework to listen for contact creation and update events. When the terminal registers, it automatically creates an active push subscription for the endpoint and sends initial notifications in batches via asynchronous tasks after the system starts up.
[0053] In this embodiment of the invention, a contact observer is registered in the persistent object management framework to listen for contact creation and update events. When a terminal registration triggers contact creation, the endpoint is checked; if the endpoint has no push subscription, it is automatically created. When a contact is updated, a message waiting indication notification is triggered for the endpoint so that the terminal receives the latest mailbox status immediately after registration. During the system startup phase, the system listens for the system manager's full startup event. After all system modules have finished loading and report full startup, the initial notifications for all push subscriptions are sent in batches through an asynchronous task push mechanism. In the contact observer callback and notification sending function, terminal types that do not support message waiting indication display are pre-filtered to skip invalid notification sending.
[0054] During the system startup phase, the system waits for the initial message to be sent by listening to the full startup event of the system manager. Once all system modules have been loaded and a full startup is reported, the initial notifications of all push subscriptions are sent in batches through an asynchronous task push mechanism.
[0055] Specifically, it enables the contact observer to automatically detect and activate storm protection.
[0056] Register a contact observer in the persistent object management framework to listen for contact creation and update events. When an endpoint registers (a contact is created), automatically check if the endpoint already has a push subscription—if not, create it automatically; when a contact is updated, trigger the sending of an MWI notification for that endpoint to ensure that the endpoint receives the latest mailbox status immediately after registration.
[0057] During system startup, the initial MWI notification is delayed by listening to the "Full Startup" event from the system manager. Only after all system modules have finished loading and reported a full startup is the initial NOTIFY notification for all push subscriptions sent in batches via an asynchronous task push mechanism, thus avoiding a notification storm caused by a large number of terminals registering simultaneously during startup.
[0058] For specific types of mobile terminals (terminal types that do not support MWI display), pre-filtering is performed in the contact observer callback and notification sending function to skip invalid notifications and reduce unnecessary SIP transaction overhead.
[0059] S106: During the module unloading phase, the active push subscription container is traversed sequentially to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription handler to complete the safe release of resources.
[0060] In this embodiment of the invention, the active push subscription container is traversed, all event bus subscriptions are canceled and all subscription objects are removed; the reference count of the active push subscription container is released; the contact observer is removed from the persistent object management framework; the reference count of the request subscription container is released; and the SIP subscription processor is unregistered.
[0061] Specifically, module-level security lifecycle management is implemented. During the module unloading phase, the following steps are executed sequentially: traversing the proactive push container to cancel all event bus subscriptions and remove all subscribed objects; releasing the proactive push container reference count; removing the contact observer from the persistent object management framework; releasing the request container reference count; and unregistering the SIP subscription handler. These operations ensure that all resources are safely released, and there are no dangling subscriptions or memory leaks.
[0062] Beneficial effects: Dual-mode isolation eliminates duplicate notifications. Only one notification mode exists for the same endpoint and mailbox at any given time. The terminal will not receive duplicate MWI notifications from both modes, and the mailbox status display will always be accurate.
[0063] An automatic recovery mechanism ensures notification continuity. When request-based subscriptions are turned off, the system automatically reverts to push notifications without waiting for configuration reload or terminal re-registration, reducing MWI function recovery time from minutes to milliseconds.
[0064] Zero-gap hot reload eliminates state loss. All mailbox state changes during configuration changes are correctly captured and notified, and configuration reload will not cause any terminal's MWI state to temporarily fail in large-scale deployment scenarios (thousands of endpoints online simultaneously).
[0065] Enable storm protection and endpoint type filtering. Reduce peak SIP transaction load during system startup to avoid resource waste and network congestion caused by a large number of invalid NOTIFY messages.
[0066] Based on the methods provided in the above embodiments, this invention also provides a SIP message waiting indication adaptive notification and subscription lifecycle automatic management device. The SIP message waiting indication adaptive notification and subscription lifecycle automatic management device is described below with reference to the accompanying drawings.
[0067] See Figure 2 The figure is a schematic diagram of the structure of a SIP message waiting indication adaptive notification and subscription lifecycle automatic management device provided in an embodiment of the present invention.
[0068] The SIP message waiting indication adaptive notification and subscription lifecycle automatic management device 200 provided in this embodiment of the invention includes: a container building unit 201, a conflict arbitration unit 202, a hot reload unit 203, a hierarchy building unit 204, an observer registration unit 205, and a resource release unit 206.
[0069] Container building unit 201 is used to build a dual-mode container divide-and-conquer isolation architecture, creating independent request-subscription containers and proactive push-subscription containers. The request-subscription container is used to manage request-subscription objects, and the proactive push-subscription container is used to manage proactive push-subscription objects. The conflict arbitration unit 202 is used to perform three-level mode conflict arbitration when it is necessary to create or receive message waiting instruction subscriptions for an endpoint. It performs admission detection, preemption replacement and automatic recovery between request subscription containers and push subscription containers to ensure that only one notification mode exists for the same endpoint and the same mailbox at any time. Hot reload unit 203 is used to perform a mark-sweep three-stage zero-gap hot reload when the system configuration changes and the message waiting indication subscription needs to be reloaded. It performs full marking, endpoint reconstruction and cleanup of the subscription objects in the active push subscription container so that there is no subscription blank window during hot reload. The hierarchical construction unit 204 is used to construct a two-level subscription hierarchy for each message waiting indication subscription object. The outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key. The observer registration unit 205 is used to register contact observers in the persistent object management framework, listen for contact creation and update events, automatically create an active push subscription for the endpoint when the terminal registers, and send initial notifications in batches through asynchronous tasks after the system starts up. Resource release unit 206 is used to sequentially traverse the active push subscription container to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription processor during the module unloading phase, thereby completing the safe release of resources.
[0070] In one possible implementation, the conflict arbitration unit 202 is specifically used for: During the admission detection phase, when attempting to create an active push subscription for an endpoint, the system checks whether a subscription for that endpoint already exists in the active push subscription container. If it does, creation is rejected. The system also checks whether a request subscription for that endpoint exists in the request subscription container. If it does, and the endpoint has a request preemption policy configured, creation of the push subscription is rejected. If a request subscription exists but no request preemption policy is configured, the request subscription is terminated before push subscription creation is allowed. During the preemption and replacement phase, when a subscription request to establish a request-based subscription is received from a terminal, it is checked whether the subscription for that endpoint exists in the active push subscription container. If it exists and the endpoint has been configured with a request-based preemption strategy, the event bus listening for the push subscription is canceled, the mailbox entry is removed from the event bus sub-container, the subscription object is removed from the active push subscription container, and the request-based subscription is allowed to be established. During the automatic recovery phase, when a request subscription is closed, the subscription object is removed from the request subscription container. It is then checked whether there are any other subscriptions for the endpoint in the request subscription container. If not, an active push subscription is automatically created for the endpoint.
[0071] In one possible implementation, the hot reload unit 203 is specifically used for: During the full marking phase, under the protection of the global lock of the proactive push subscription container, all subscription objects in the container are traversed, and the deletion flag of each subscription object is set to the state of pending deletion. During the endpoint reconstruction phase, all endpoint configurations in the system are traversed. If the endpoint already has a subscription in the request subscription container, it is skipped. If the endpoint already has a subscription in the push subscription container, its deletion flag is cleared. If neither exists, a new push subscription is created for the endpoint and linked into the container. During the cleanup phase, the active push subscription container is traversed again, subscription objects whose deletion flag is still set to be deleted are removed, their event bus listeners are canceled, and their resources are released.
[0072] In one possible implementation, the hierarchical building unit 204 is specifically used for: The outer subscription object stores the corresponding pattern container with the endpoint unique identifier as the key, holding the SIP subscription reference, the address record list and the aggregation pattern flag; The inner event bus subscription sub-container uses the mailbox identifier as the key, and each entry holds an event bus subscription handle. When the mailbox state changes, the event bus callback function is triggered, and the notification sending task is delivered to the corresponding serializer queue through the serializer asynchronous task push mechanism.
[0073] In one possible implementation, the observer registration unit 205 is specifically used for: Register a contact observer in the persistent object management framework to listen for contact creation and update events. When the terminal registration triggers contact creation, check the endpoint. If the endpoint does not have a push subscription, create the contact automatically. When a contact is updated, a message waiting instruction notification is triggered on the endpoint so that the terminal receives the latest mailbox status immediately after registration. During the system startup phase, listen for the full startup event of the system manager. Once all system modules have finished loading and report a full startup, send the initial notifications of all push subscriptions in batches through an asynchronous task push mechanism. In the contact observer callback and notification sending function, pre-filtering is performed on terminal types that do not support the display of message waiting indication, skipping invalid notification sending.
[0074] In one possible implementation, the observer registration unit 205 is specifically used for: During the system startup phase, the system waits for the initial message to be sent by listening to the full startup event of the system manager. Once all system modules have been loaded and a full startup is reported, the initial notifications of all push subscriptions are sent in batches through an asynchronous task push mechanism.
[0075] In one possible implementation, the resource release unit 206 is specifically used for: Iterate through the active push subscription container, cancel all event bus subscriptions and remove all subscription objects; Release the reference count of the proactive push subscription container; Remove the contact observer from the persistent object management framework; Release the reference count of the request-based subscription container; Cancel the SIP subscription processor.
[0076] Since the SIP message waiting indication adaptive notification and subscription lifecycle automatic management device 200 is a device corresponding to the SIP message waiting indication adaptive notification and subscription lifecycle automatic management method provided in the above method embodiments, the specific implementation of each unit of the SIP message waiting indication adaptive notification and subscription lifecycle automatic management device 200 is based on the same concept as in the above method embodiments. Therefore, for the specific implementation of each unit of the SIP message waiting indication adaptive notification and subscription lifecycle automatic management device 200, please refer to the description of the SIP message waiting indication adaptive notification and subscription lifecycle automatic management method in the above method embodiments, and will not be repeated here.
[0077] This invention also provides a SIP message wait indication adaptive notification and subscription lifecycle automatic management device, the device comprising: a processor and a memory; The memory is used to store instructions; The processor is configured to execute the instructions in the memory, and to execute the SIP message wait indication adaptive notification and subscription lifecycle automatic management method mentioned in the above embodiments.
[0078] It should be noted that the hardware structure of the SIP message waiting indication adaptive notification and subscription lifecycle automatic management device provided in the embodiments of the present invention can be as follows: Figure 3 The structure shown, Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention.
[0079] Please see Figure 3 As shown, device 300 includes: a processor 310, a communication interface 320, and a memory 330. The number of processors 310 in device 300 can be one or more. Figure 3 Taking a processor as an example, in this embodiment of the invention, the processor 310, communication interface 320, and memory 330 can be connected via a bus system or other means. Figure 3 Taking the connection between China and Israel via bus system 340 as an example.
[0080] Processor 310 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. Processor 310 may further include hardware chips. These hardware chips may be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.
[0081] The memory 330 may include volatile memory, such as random-access memory (RAM); the memory 330 may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 330 may also include a combination of the above types of memory.
[0082] Optionally, the memory 330 stores an operating system and programs, executable modules, or data structures, or subsets thereof, or extended sets thereof. The programs may include various operation instructions for implementing various operations. The operating system may include various system programs for implementing various basic services and handling hardware-based tasks. The processor 310 can read the programs in the memory 330 to implement the SIP message wait indication adaptive notification and subscription lifecycle automatic management method provided in this embodiment of the invention.
[0083] The bus system 340 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus system 340 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0084] This invention also provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the SIP message wait indication adaptive notification and subscription lifecycle automatic management method mentioned in the above embodiments.
[0085] This invention also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute the SIP message waiting indication adaptive notification and subscription lifecycle automatic management method mentioned in the above embodiments.
[0086] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.
Claims
1. A method for adaptive notification of SIP message wait indication and automatic management of subscription lifecycle, characterized in that, include: Construct a dual-mode container divide-and-conquer isolation architecture, creating independent request-based subscription containers and proactive push-based subscription containers, wherein the request-based subscription container is used to manage request-based subscription objects, and the proactive push-based subscription container is used to manage proactive push-based subscription objects; When it is necessary to create or receive message waiting indication subscriptions for an endpoint, a three-level mode conflict arbitration is performed, and admission detection, preemption replacement and automatic recovery are carried out between the request-based subscription container and the proactive push subscription container to ensure that only one notification mode exists for the same endpoint and the same mailbox at any time. When the system configuration changes and a message waiting instruction subscription needs to be reloaded, a three-stage zero-gap hot reload of marking-sweeping is performed. The subscription objects in the active push subscription container are fully marked, rebuilt endpoint by endpoint, and residuals are cleared to ensure that there are no subscription blank windows during the hot reload. For each message waiting instruction subscription object, a two-level subscription hierarchy is constructed. The outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key. Register a contact observer in the persistent object management framework to listen for contact creation and update events. When the terminal registers, automatically create an active push subscription for the endpoint and send initial notifications in batches via asynchronous tasks after the system starts up. During the module unloading phase, the active push subscription container is traversed sequentially to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription handler to complete the safe release of resources.
2. The method according to claim 1, characterized in that, The implementation of the three-level conflict arbitration model includes: During the admission detection phase, when attempting to create an active push subscription for an endpoint, the system checks whether a subscription for that endpoint already exists in the active push subscription container. If it does, creation is rejected. The system also checks whether a request subscription for that endpoint exists in the request subscription container. If it does, and the endpoint has a request preemption policy configured, creation of the push subscription is rejected. If a request subscription exists but no request preemption policy is configured, the request subscription is actively terminated before the creation of the push subscription is allowed. During the preemption and replacement phase, when a subscription request to establish a request-based subscription is received from a terminal, it is checked whether the subscription of the endpoint exists in the active push subscription container. If it exists and the endpoint has been configured with a request-based preemption strategy, the event bus listening of the push subscription is canceled, the mailbox entry is removed from the event bus sub-container, the subscription object is removed from the active push subscription container, and the request-based subscription is allowed to be established. During the automatic recovery phase, when a request subscription is closed, the subscription object is removed from the request subscription container. It is then checked whether there are any other subscriptions for the endpoint in the request subscription container. If not, an active push subscription is automatically created for the endpoint.
3. The method according to claim 1, characterized in that, The execution of the mark-clean three-stage zero-gap thermal overload includes: During the full marking phase, under the protection of the global lock of the proactive push subscription container, all subscription objects in the container are traversed, and the deletion flag of each subscription object is set to the state of pending deletion. During the endpoint reconstruction phase, all endpoint configurations in the system are traversed. If the endpoint already has a subscription in the request subscription container, it is skipped. If the endpoint already has a subscription in the push subscription container, its deletion flag is cleared. If neither exists, a new push subscription is created for the endpoint and linked into the container. During the cleanup phase, the active push subscription container is traversed again, subscription objects whose deletion flag is still set to be deleted are removed, their event bus listeners are canceled, and their resources are released.
4. The method according to claim 1, characterized in that, The construction of a two-level subscription hierarchy for each message waiting indication subscription object includes: The outer subscription object stores the corresponding pattern container with the endpoint unique identifier as the key, holding the SIP subscription reference, the address record list and the aggregation pattern flag; The inner event bus subscription sub-container uses the mailbox identifier as the key, and each entry holds an event bus subscription handle. When the mailbox state changes, the event bus callback function is triggered, and the notification sending task is delivered to the corresponding serializer queue through the serializer asynchronous task push mechanism.
5. The method according to claim 1, characterized in that, Registering a contact observer in the persistent object management framework includes: Register a contact observer in the persistent object management framework to listen for contact creation and update events. When a terminal registration triggers contact creation, check the endpoint. If the endpoint does not have a push subscription, create the contact automatically. When a contact is updated, a message waiting indication notification is triggered on the endpoint so that the terminal receives the latest mailbox status immediately after registration. During the system startup phase, listen for the full startup event of the system manager. Once all system modules have finished loading and report a full startup, send the initial notifications of all push subscriptions in batches through an asynchronous task push mechanism. In the contact observer callback and notification sending function, pre-filtering is performed on terminal types that do not support the display of message waiting indication, and invalid notifications are skipped.
6. The method according to claim 1, characterized in that, The method further includes: During the system startup phase, the system waits for the initial message to be sent by listening to the full startup event of the system manager. Once all system modules have been loaded and a full startup is reported, the initial notifications of all push subscriptions are sent in batches through an asynchronous task push mechanism.
7. The method according to claim 1, characterized in that, During the module unloading phase, the process sequentially iterates through the proactive push subscription container, cancels the event bus subscription and removes the subscription object, removes the contact observer, releases the container reference count, and unregisters the SIP subscription handler to complete the safe release of resources, including: Iterate through the active push subscription container, cancel all event bus subscriptions and remove all subscription objects; Release the reference count of the proactive push subscription container; Remove the contact observer from the persistent object management framework; Release the reference count of the request-based subscription container; Cancel the SIP subscription processor.
8. A SIP message wait indication adaptive notification and subscription lifecycle automatic management device, characterized in that, include: A container building unit is used to build a dual-mode container divide-and-conquer isolation architecture, creating independent request-subscribe containers and proactive push-subscribe containers, wherein the request-subscribe container is used to manage request-subscribe objects, and the proactive push-subscribe container is used to manage proactive push-subscribe objects; The conflict arbitration unit is used to perform three-level mode conflict arbitration when it is necessary to create or receive message waiting instruction subscriptions for the endpoint. It performs admission detection, preemption replacement and automatic recovery between the request subscription container and the active push subscription container to ensure that only one notification mode exists for the same endpoint and the same mailbox at any time. The hot reload unit is used to perform a three-stage zero-gap hot reload of marking and sweeping when the system configuration changes and the message waiting indication subscription needs to be reloaded. It performs full marking, endpoint reconstruction and clearing of residuals on the subscription objects in the active push subscription container so that there are no subscription blank windows during the hot reload. The hierarchical building unit is used to build a two-level subscription hierarchy for each message waiting indication subscription object. The outer subscription object is stored in the corresponding pattern container with the endpoint identifier as the key, and the inner event bus subscription sub-container stores the event bus subscription handle with the mailbox identifier as the key. The observer registration unit is used to register contact observers in the persistent object management framework, listen for contact creation and update events, automatically create proactive push subscriptions for endpoints when the terminal registers, and send initial notifications in batches through asynchronous tasks after the system starts up; The resource release unit is used during the module unloading phase to sequentially traverse the proactive push subscription container to cancel the event bus subscription and remove the subscription object, remove the contact observer, release the container reference count, and unregister the SIP subscription handler to complete the safe release of resources.
9. An electronic device, characterized in that, The device includes: a processor and a memory; The memory is used to store instructions; The processor is configured to execute the instructions in the memory to perform the method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, Including instructions that, when run on a computer, cause the computer to perform the method described in any one of claims 1-7 above.