IP-PBX multi-terminal concurrent login session management method and system

Abstract

The application discloses an IP-PBX multi-terminal concurrent login session management method and system, and the method comprises the following steps: establishing a global hash index table with a username as a key and a two-level mapping; setting a hierarchical lock sequence protocol and reference counting for life cycle management; establishing a multi-dimensional key type session search engine; executing differentiated concurrent strategies and accurate kicking out based on client types and SDK versions; performing device-level distribution of events, pushing and CTI states with device identification as a primary key; performing new and old protocol compatibility and rolling upgrade support; and performing session group activity aging detection and self-healing. The method solves the problems of session organization, search, scheduling and recovery when the same extension account accesses an IP-PBX server simultaneously through multiple types of physical terminals.

Description

Technical Field

[0001] This application belongs to the field of IP-PBX communication service technology, specifically referring to an IP-PBX multi-terminal concurrent login session management method and system. Background Technology

[0002] In enterprise unified communications scenarios, the same user needs to be online on multiple terminals simultaneously to maintain a continuous experience across multiple service dimensions such as calls, messaging, CTI, and push notifications. However, traditional IP-PBX servers (represented by open-source Asterisk derivative projects and early commercial IP-PBX implementations) face the following technical bottlenecks in multi-terminal concurrent scenarios: Flat session lists lead to "single extension, single session mutual exclusion": Traditional implementations use a single global session list to host all online terminals, scanning sequentially with the username as the unique key. During login, "destroying old sessions with the same name" is used to avoid state conflicts, resulting in new logins inevitably displacing older ones. There is no precise offline channel at the device level: Kick-out operations are performed at the username level for overall cleanup, making it impossible to remove only a single physical device while retaining other devices under the same account. A typical manifestation is that "after a mobile device is kicked from the device list, call records still retain information about the kicked device," leading to subsequent ringing group errors. Event distribution is coarse-grained and overflows across devices: Call notifications, message pushes, CTI status, recording commands, and other events are broadcast to all online terminals with the username as the key, causing CTI on desktop PCs to overflow. The system exhibits a series of defects, including incorrect display of mobile devices in the list, interception of recording commands from mobile devices by other devices, and continuous "calling in progress" display when the host device is pushing data in the background on a tablet. Concurrency lock ordering is lacking, leading to deadlocks: the same session may be accessed concurrently by the login main thread, push thread, and codec negotiation thread. Without unified lock order constraints, duplicate locking and deadlocks are likely to occur. Historically, defects such as "login failure after modifying the mobile device's codec, requiring a service process restart" have been observed multiple times. Push status updates are not user-granular: when synchronizing push status to the PBX core, the system uses the username as the key to mark the entire system, failing to reflect the true situation where "one user logs out on one device but another is still online," causing call record residue and incorrect push notifications. Older client versions cannot coexist with newer versions, requiring a "big bang" upgrade: the server needs to simultaneously interface with multiple major SDK versions spanning several years. Without a protocol compatibility layer, introducing new session semantics will interrupt login on existing devices, which is operationally unacceptable. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies, this application provides a method and system for managing concurrent login sessions on IP-PBX multi-terminals, which solves the problems of session organization, retrieval, scheduling and recycling when the same extension account is accessed by multiple types of physical terminals at the same time.

[0004] This invention provides a method for managing concurrent login sessions of multiple terminals in an IP-PBX, the method comprising: Establish a global hash index table with username as the key and a two-level mapping; Configure a hierarchical locking protocol and use reference counting for lifecycle management; Establish a session retrieval engine with multi-dimensional key types; Implement differentiated concurrency strategies and precise kick-out based on client type and SDK version; Perform device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key; Support for compatibility with both new and old protocols and rolling upgrades; Perform session group activity aging detection and self-healing.

[0005] Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the step of establishing a global hash index table with username as the key and a two-level mapping includes: When the IP-PBX server starts, it initializes a global hash index table using the username as the key. Whenever a terminal successfully logs in, the IP-PBX server locates the "session group" object in the global hash index table based on the username; if the "session group" object does not exist, it is created. Each "session group" maintains internally: a group-level mutex, reference count, creation timestamp, last active timestamp, and a linked list of sessions within the group; All online terminals of the same user are attached to the linked list of their respective "session groups" as session nodes; The session object holds a pointer to its own "session group" in reverse, thus enabling O(1) reverse lookup from any session to its own group. Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, in the step of setting a hierarchical locking protocol and using reference counting for lifecycle management, setting the hierarchical locking protocol includes: Define a fixed four-layer locking order on the IP-PBX server, from the outside in: Bucket-level read-write locks on the session group's global hash index table; The mutex lock for the session group object; Bucket-level read-write locks on the join descriptor secondary index table; The session object's own mutex lock.

[0006] Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, in the step of setting a hierarchical locking protocol and performing lifecycle management using reference counting, the lifecycle management using reference counting includes: Both session groups and sessions use reference counting; Any thread increments the reference count before accessing an object and decrements it when it finishes accessing it. Memory is only truly released when the reference count reaches zero and the object has been marked for destruction. Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the step of establishing a multi-dimensional key type session retrieval engine includes: Within the session group, a unified multi-dimensional key type retrieval interface is provided. The caller only needs to pass three parameters: "username + matching key type + matching value" to obtain the target session. The matching key types include: device identifier, user agent, client type, connection descriptor, and session identifier; When performing session retrieval, first use the username to hit the group in the global hash index table in O(1) time, and then perform linear matching on the linked list with only a few elements in the group.

[0007] Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the step of executing differentiated concurrency strategies and precise kick-out based on client type and SDK version includes: After a terminal successfully logs in, the new session is first added to its respective session group; The IP-PBX server core calculates and returns the "device identifier that should be disqualified from this login" based on the client type and SDK version of the currently online client of the account, as well as the corresponding attributes of the terminal that is currently logged in; If the identifier of "device identifier that should be kicked out by this login" is not empty, the server uses "device identifier" as the matching key to accurately locate the target session in the session group, sets it to be forcibly destroyed and marks it with "kicked out for login from other locations"; The IP-PBX server sends a structured notification to the kicked-out client, which includes a field for the reason for disconnection. Based on this, the client can accurately distinguish different disconnection semantics on the interface, such as "administrator disconnected / incorrect password / multiple client access". The IP-PBX server notifies the PBX core synchronization push status at the device identifier level, only disqualifying the kicked end from making call pushes; other online ends under the same account are unaffected.

[0008] Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the device-level distribution step of events, push notifications, and CTI status with device identifier as the primary key includes: The device identifier is elevated to the first-level key for event distribution. Call ringing, message notification, CTI status, third-party push, and recording control commands are all conveyed by the distribution module in the following path: "Traverse the global hash index table of the session group as needed" to "Execute the "add reference and lock" primitive on the target group" to "Retrieve the target session within the group by multi-dimensional key" to "Send only to the target session". Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the step of supporting compatibility between old and new protocols and rolling upgrades includes: To ensure compatibility between the old and new protocols, both old and new session structures coexist in the IP-PBX server, including: The new structure includes a session group association field and a multi-dimensional key field, while the old structure retains the flat semantics and the old field layout. The login entry is automatically routed to the corresponding structure based on the version characteristics in the terminal registration message; For older terminals that cannot recognize the newly added device identifier field, the system assigns a predefined default compatibility identifier to prevent them from being mistakenly kicked out in the multi-dimensional key distribution path. For existing CTI integrations, the system sends both the new and old notification numbers simultaneously to ensure that existing plugins function correctly.

[0009] Furthermore, according to the IP-PBX multi-terminal concurrent login session management method provided by the present invention, the step of performing session group activity aging detection and self-healing includes: Each session group maintains a "last active time" stamp, which is periodically scanned by a background scheduled task; When a session group meets the three conditions of "the internal session list is empty, the reference count is zero, and the idle time exceeds the threshold", the scheduled task removes it from the hash table and releases it. This invention also provides an IP-PBX multi-terminal concurrent login session management system, the system comprising: A global hash index table creation module is used to create a global hash index table with the username as the key and a two-level mapping. A hierarchical locking sequence protocol and lifecycle management module, wherein the hierarchical locking sequence protocol is set and reference counting is used for lifecycle management; A session retrieval engine building module, which builds a session retrieval engine with multi-dimensional key types; A login device kickout module, which executes differentiated concurrency strategies and precise kickout based on client type and SDK version; The device-level distribution module performs device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key. The compatibility and upgrade module supports compatibility with both old and new protocols and rolling upgrades. And an activity aging detection and self-healing module, which performs session group activity aging detection and self-healing.

[0010] The beneficial effects of this invention are as follows: This invention provides a method and system for managing concurrent login sessions on multiple terminals in an IP-PBX. This method introduces a "session group intermediate abstraction" in the server-side session management layer, reconstructing the original flat mapping of "username → single session" into a two-level mapping of "username → session group → multiple sessions". It also proposes six collaborative mechanisms: hierarchical locking sequence, multi-dimensional key matching retrieval, differentiated concurrency strategy, device-level event distribution, compatibility between new and old protocols, and session group aging self-healing. This solves the problems of session organization, retrieval, scheduling, and recycling when the same extension account accesses the IP-PBX server simultaneously on multiple types of physical terminals (mobile App, Pad, PC soft client, Web, CTI / CRM integration SDK, etc.). Attached Figure Description

[0011] The technical solution and other beneficial effects of this application will become apparent from the following detailed description of specific embodiments in conjunction with the accompanying drawings.

[0012] Figure 1 This is a schematic diagram of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment.

[0013] Figure 2 This is the overall flowchart of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment.

[0014] Figure 3 This is the core timing diagram of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0016] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0017] The following disclosure provides many different embodiments or examples for implementing different structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. In addition, various specific examples of processes and materials are provided in this application, but those skilled in the art will recognize the application of other processes and / or the use of other materials.

[0018] The embodiments of this application will now be further described in conjunction with the accompanying drawings and specific implementation details.

[0019] Example 1 This invention provides a method for managing concurrent login sessions on an IP-PBX using multiple terminals. This method introduces a "session group intermediate abstraction" at the server-side session management layer, reconstructing the original flat mapping of "username → single session" into a two-level mapping of "username → session group → multiple sessions." It also proposes six collaborative mechanisms: hierarchical locking sequence, multi-dimensional key matching retrieval, differentiated concurrency strategies, device-level event distribution, compatibility with new and old protocols, and session group aging self-healing. This solves the problems of session organization, retrieval, scheduling, and recycling when the same extension account simultaneously accesses the IP-PBX server from multiple physical terminals (mobile apps, tablets, PC soft clients, Web, CTI / CRM integration SDKs, etc.).

[0020] Figure 1 This is a schematic diagram of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment. Figure 1As shown, the method includes: Step 1: Establish a global hash index table with username as the key and a two-level mapping.

[0021] Step one includes: when the IP-PBX server starts, it initializes a global hash index table using the username as the key; Whenever a terminal successfully logs in, the IP-PBX server locates the "session group" object in the global hash index table based on the username; if the "session group" object does not exist, it is created. Each "session group" maintains internally: a group-level mutex, reference count, creation timestamp, last active timestamp, and a linked list of sessions within the group; All online devices of the same user (whether mobile, desktop, or tablet) are attached to the linked list of their respective "session groups" as session nodes; The session object holds a pointer to its own "session group" in reverse, thus enabling O(1) reverse lookup from any session to its own group.

[0022] Therefore, the complexity of locating "all online sessions of a certain user" is reduced from O(N) (where N is the total number of global sessions) to O(1) + O(k) (where k is the number of concurrent endpoints of the user, which is usually a single digit due to concurrency restrictions).

[0023] Step 2: Set up a hierarchical locking protocol and use reference counting for lifecycle management.

[0024] In order to eliminate deadlock from the architectural perspective, this embodiment defines a fixed four-layer locking order on the IP-PBX server, from the outside in: Bucket-level read-write locks on the session group's global hash index table; The mutex lock for the session group object; Bucket-level read-write locks on the join descriptor secondary index table; The session object's own mutex lock.

[0025] Therefore, through the above four-layer locking sequence, any business path that needs to hold multiple locks simultaneously must acquire them in this order and release them in the reverse order. This lock sequence is forcibly pushed down to the basic interface as an external primitive. The caller can only access the session group and session through three types of paired primitives: "find and lock / reference / dereference," and cannot arbitrarily acquire locks directly, thus avoiding lock sequence reversal.

[0026] The reference counting lifecycle management includes: both session groups and sessions use reference counting; any thread increments the reference count before accessing an object and decrements it when the access ends; memory is only truly released when the reference count reaches zero and the object has been marked for destruction. This mechanism structurally eliminates dangling references that are "released while in use".

[0027] Step 3: Build a session retrieval engine with multi-dimensional key types.

[0028] In this embodiment, a unified multi-dimensional key type retrieval interface is provided within the session group. The caller only needs to pass in three parameters: "username + matching key type + matching value" to obtain the target session.

[0029] The matching key types include: device identifier (identifying a specific physical device), user agent (distinguishing between iOS / Android / PC / tablet and other terminal families), client type (distinguishing between App / PC / other integrated clients), connection descriptor (used for quick cleanup of disconnected connections), and session identifier (used for reverse lookup by session ID), etc.

[0030] When performing session retrieval, the group is first matched in O(1) time in the global hash index table by username, and then a linear match is performed on the linked list with only a few elements in the group. The overall complexity is close to constant time.

[0031] Meanwhile, to further improve the efficiency of connection breakage handling, an auxiliary index table is introduced in this embodiment to directly map connection descriptors to the corresponding sessions, so that when a connection breakage event occurs, the session can be located directly without traversing the entire table.

[0032] Step 4: Implement differentiated concurrency strategies and precise kick-out based on client type and SDK version.

[0033] In this embodiment, the "number of concurrent connections allowed per account and under what circumstances a connection should be kicked out" are considered configurable business policies, calculated by the PBX core side and only executed by the IP-PBX server middleware. The process is as follows: After a terminal successfully logs in, the new session is first added to its respective session group; The IP-PBX server core calculates and returns the "device identifier that should be disqualified from this login" based on the client type and SDK version of the currently online client of the account, as well as the corresponding attributes of the terminal that is currently logged in; If the identifier of "device identifier that should be kicked out by this login" is not empty, the server uses "device identifier" as the matching key to accurately locate the target session in the session group, sets it to be forcibly destroyed and marks it with "kicked out for login from other locations"; The IP-PBX server sends a structured notification to the kicked-out client, which includes a field for the reason for disconnection (such as "login from another location"). Based on this, the client can accurately distinguish different disconnection semantics on the interface, such as "administrator disconnected / incorrect password / multiple devices logging in". The IP-PBX server notifies the PBX core synchronization push status at the device identifier level, only disqualifying the kicked end from making call pushes; other online ends under the same account are unaffected.

[0034] Therefore, this decoupling of strategy and execution means that when adjusting single-user concurrency (e.g., differentiating between Enterprise and Flagship editions based on license levels), only the PBX core strategy needs to be modified, without updating the middleware.

[0035] Step 5: Perform device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key.

[0036] In this embodiment, the device identifier is elevated to the first-level key for event distribution. Events such as call ringing, message notification, CTI status, third-party push notifications, and recording control commands are all communicated by the distribution module according to the following path: traverse the session group hash table as needed → execute the "add reference and lock" primitive on the target group → retrieve the target session within the group by multi-dimensional key → send only to the target session.

[0037] Therefore, call ringing can be precisely routed to the physical device that initiated the push based on the device identifier; CTI notifications can be filtered by client type to prevent desktop PCs from receiving information from mobile devices; message pushes can be deduplicated within groups based on device identifiers to avoid duplicate pushes to the same account; and push status is synchronously updated in the PBX core at the granularity of device identifiers to eliminate call record residues.

[0038] Step 6: Perform compatibility testing and rolling upgrade support for both new and old protocols.

[0039] To support seamless migration of existing SDKs spanning multiple years, this embodiment uses two sets of session structures—one new and one old—in the IP-PBX server's memory model: the new structure includes session group association fields and multi-dimensional key fields, while the old structure retains flat semantics and the old field layout. The login entry point is automatically routed to the corresponding structure based on the version characteristics in the terminal registration message. For older terminals that cannot recognize the newly added device identifier field, the system assigns a predefined default compatibility identifier to prevent them from being mistakenly kicked out in the multi-dimensional key distribution path. For existing CTI integrations, the system sends both the new and old notification numbers simultaneously to ensure the normal operation of existing plugins. Combined with a temporary version number fallback mechanism, this solution allows for rolling migration of new and old clients in a production environment without downtime.

[0040] Step 7: Perform conversation group activity aging detection and self-healing.

[0041] Step seven specifically includes: each session group maintains a "last active time" stamp, which is periodically scanned by a background scheduled task; when a session group meets the three conditions of "the internal session list is empty, the reference count is zero, and the idle time exceeds the threshold", the scheduled task removes it from the hash table and releases it.

[0042] This mechanism prevents "zombie empty groups" from residing in the hash table during long-term operation and provides a fallback cleanup for reference count leaks, ensuring the stability of the service under continuous operation at the monthly and yearly levels.

[0043] Figure 2 This is the overall flowchart of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment.

[0044] Figure 2 The process flow of this method between the new terminal, access server, session group manager, PBX core, and old terminal is shown here, but will not be elaborated upon here.

[0045] Figure 3 This is the core timing diagram of the IP-PBX multi-terminal concurrent login session management method provided in this embodiment.

[0046] Figure 3 The timing flow of this method is shown in the middleware of the server (new login) and terminal B (already online), as well as the hash table and push gateway, which will not be elaborated here.

[0047] This embodiment also provides an IP-PBX multi-terminal concurrent login session management system, the system comprising: A global hash index table creation module is used to create a global hash index table with the username as the key and a two-level mapping. A hierarchical locking sequence protocol and lifecycle management module, wherein the hierarchical locking sequence protocol is set and reference counting is used for lifecycle management; A session retrieval engine building module, which builds a session retrieval engine with multi-dimensional key types; A login device kickout module, which executes differentiated concurrency strategies and precise kickout based on client type and SDK version; The device-level distribution module performs device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key. The compatibility and upgrade module supports compatibility with both old and new protocols and rolling upgrades. And an activity aging detection and self-healing module, which performs session group activity aging detection and self-healing.

[0048] In summary, the IP-PBX multi-terminal concurrent login session management method and system provided in this embodiment establishes a session group intermediate abstraction layer + two-level index to replace the flat session linked list: existing solutions use a single global linked list on the server side to carry all online sessions, linearly scanning by username. This invention introduces the intermediate abstraction of "session group" between users and sessions, constructing a two-level index of "username → session group → multiple sessions". The session group simultaneously assumes four roles: group-level lock, group-level reference counting, group-level timestamp, and group-level linked list, so that all online terminals of the same account are aggregated in memory into independent lockable, countable, and ageable first-class citizen objects. This is the core structural innovation of this invention and the foundation of all subsequent mechanisms.

[0049] Furthermore, a multi-dimensional key retrieval system with an auxiliary index table is established to support event distribution: Existing solutions rely on the business layer to traverse and filter events manually, with retrieval dimensions limited to usernames or session pointers. This invention abstracts the matching key into a set of enumerations (covering device identifier, user agent, client type, connection descriptor, session identifier, etc.), with the server providing a unified multi-dimensional key retrieval interface. The business layer can obtain the target session by any business dimension without needing to concern itself with session organization details; simultaneously, an auxiliary index table directly maps connection descriptors to sessions, further supporting immediate cleanup of broken connections.

[0050] Furthermore, it establishes a hierarchical locking order protocol and a reference counting lifecycle: existing solutions lack mandatory constraints on the order in which concurrent locks are acquired on the server side, easily leading to duplicate locking and deadlocks. This invention solidifies the four-layer locking order on the server side in the form of external primitives and completely eliminates dangling references that are "released while in use" using reference counting. This is guaranteed by the execution mechanism of the method itself, ensuring that the two-level index remains linearly scalable under high concurrency.

[0051] Furthermore, a PBX-middleware collaboration mechanism is proposed, combining centralized decision-making for concurrency strategies with precise device-level kick-out. In existing solutions, "who to kick and who to keep" is typically hard-coded in the middleware at the username level. This invention decentralizes concurrency strategy decision-making to the PBX core, using the "device identifier to be kicked" as the explicit result returned by the PBX to the middleware. The middleware is only responsible for accurately locating the target session within the session group using this device identifier as the key, executing the kick-out action, and sending a structured offline notification (with a clear reason) to the kicked end. This collaboration mechanism achieves both precise device-level kick-out and decoupling of strategy and execution, allowing adjustments to business strategies without modifying the middleware.

[0052] Furthermore, it provides device-level event distribution and push status synchronization: Existing solutions synchronize events and push status at the username level, causing cross-device overflow in multi-device scenarios. This invention elevates the device identifier to a primary key for event distribution and push status synchronization. All events are transmitted via the path of "location group → key matching within the group → precise delivery to the target session," and push status updates are also performed at the device level. This eliminates a series of defects common in existing solutions in multi-device scenarios, such as incorrect ringing, CTI list mixing, duplicate pushes, and call record residue.

[0053] Furthermore, it provides rolling upgrade support for the coexistence of old and new protocols within the same process: Existing protocol upgrades typically require downtime switching or dual-process parallelism, which is costly and risky. This invention simultaneously stores both old and new session structures and notification numbers in the server-side memory model, automatically routing based on version characteristics in the terminal registration message; assigning predefined compatibility identifiers to older terminals that cannot recognize new fields; and simultaneously sending both old and new notification numbers to existing CTI plugins. This compatibility layer allows new and old clients to coexist seamlessly within the same process.

[0054] Group-level aging and self-healing can also be performed: existing solutions lack the abstraction of "group", and therefore there is no "group-level aging". This invention defines the recycling boundary of the session group with three conditions: "empty linked list + reference count to zero + idle timeout", and the background timed task self-heals and cleans up to ensure long-term operational stability.

[0055] Alternatively, in another embodiment, the session group can be based on the tenant identifier or the global extension UUID as the key; the key of the session group global hash index table in step one can be expanded from "username" to "tenant identifier + username" or a globally unique extension UUID to support scenarios such as multi-tenant cloud PBX and multi-PBX merged deployment; the hash function and conflict handling logic remain unchanged, only the key derivation strategy is different.

[0056] Alternatively, in another embodiment, a lock-free read path based on RCU can be adopted; the hierarchical locking protocol in step two can be replaced by the RCU (Read-Copy-Update) mechanism in read-heavy, write-light scenarios. The event distribution path only needs to obtain the RCU read-side reference of the group, while write paths such as login / kickout / group state changes follow the write-side clone-replace process. This alternative can further reduce event distribution latency under tens of thousands of concurrent deployments.

[0057] In another embodiment, concurrent strategies can be dynamically deployed and take effect in real time; the concurrent strategy table in step four can be updated in real time by the PBX core through the configured deployment channel, rather than being a built-in constant; the operator can flexibly adjust the upper limit of the number of concurrent terminals per user according to the authorization level (such as 5 terminals for the enterprise version and 10 terminals for the flagship version), and the middleware can take effect without restarting or upgrading.

[0058] In another embodiment, eventual consistency synchronization of cross-node session groups can be configured. For cloud-based PBX cluster deployments, session groups can be expanded into cross-node replicable data structures. The group state is synchronized among multiple access nodes through an eventual consistency synchronization protocol, supporting load balancing, disaster recovery in different locations, and multi-terminal concurrency across nodes.

[0059] In another embodiment, unified message service synchronization across multiple devices can be achieved; the "session group + multi-dimensional key + device-level distribution" model of this method can be extended to instant messaging, voicemail notifications, missed call notifications, etc., to achieve accurate synchronization of message read / unread status across multiple devices with the same account.

[0060] Alternatively, in another embodiment, fine-grained device-level control of CTI / CRM integration is possible. In CTI / CRM plug-in scenarios, specific instructions (such as "pop up only on the PC where the CRM plug-in is located, without disturbing mobile phones with the same account") can be sent to designated devices using the device identifier as the key, achieving more granular collaboration capabilities than traditional extension-level control.

[0061] In another embodiment, operational situation awareness can be achieved; based on a full scan of the session group hash table, monitoring indicators such as "distribution of concurrent user terminals", "activity level by client type" and "distribution by SDK version" can be output in real time, providing data support for capacity planning, forced upgrade strategies and channel operations.

[0062] Example 2 This embodiment also provides a computer terminal device for IP-PBX multi-terminal concurrent login session management method. The terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the embodiments of the above-described method of Embodiment 1 of the present invention.

[0063] Furthermore, as an executable solution, the computer terminal device of the IP-PBX multi-terminal concurrent login session management method can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer terminal device of the IP-PBX multi-terminal concurrent login session management method may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described composition of the computer terminal device for the IP-PBX multi-terminal concurrent login session management method is merely an example and does not constitute a limitation on the computer terminal device for the IP-PBX multi-terminal concurrent login session management method. It may include more or fewer components than described above, or combine certain components, or different components. For example, the computer terminal device for the IP-PBX multi-terminal concurrent login session management method may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0064] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices. The general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the computer terminal equipment in the IP-PBX multi-terminal concurrent login session management method, connecting various parts of the computer terminal equipment using various interfaces and lines.

[0065] The memory can be used to store the computer programs and / or modules. The processor, by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory, realizes various functions of the computer terminal device of the IP-PBX multi-terminal concurrent login session management method. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0066] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the methods described in the embodiments of the present invention.

[0067] If the modules / units integrated into the computer terminal device of the IP-PBX multi-terminal concurrent login session management method are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0068] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the present invention. Finally, it should be noted that in this document, relational terms such as "first" and "second" are used merely 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 terminal device 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 terminal device. 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 terminal device that includes said element.

[0069] The above provides a detailed description of an IP-PBX multi-terminal concurrent login session management method and system provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of this application. Those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for managing IP-PBX multi-terminal concurrent login session, characterized in that, The method includes: Establish a global hash index table with username as the key and a two-level mapping; Configure a hierarchical locking protocol and use reference counting for lifecycle management; Establish a session retrieval engine with multi-dimensional key types; Implement differentiated concurrency strategies and precise kick-out based on client type and SDK version; Perform device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key; Support for compatibility with both new and old protocols and rolling upgrades; Perform session group activity aging detection and self-healing.

2. The IP-PBX multi-terminal concurrent log-in session management method according to claim 1, characterized by, The step of establishing a global hash index table with username as the key and a two-level mapping includes: When the IP-PBX server starts, it initializes a global hash index table using the username as the key. Whenever a terminal successfully logs in, the IP-PBX server locates the "session group" object in the global hash index table based on the username; if the "session group" object does not exist, it is created. Each "session group" maintains internally: a group-level mutex, a reference count, a creation timestamp, a last active timestamp, and a linked list of sessions within the group; All online terminals of the same user are attached to the linked list of their respective "session groups" as session nodes; The session object holds a pointer to its own "session group" in reverse, thus enabling O(1) reverse lookup from any session to its own group.

3. The IP-PBX multi-terminal concurrent logon session management method of claim 1, wherein, In the step of setting up a hierarchical locking protocol and using reference counting for lifecycle management, setting up the hierarchical locking protocol includes: Define a fixed four-layer locking order on the IP-PBX server, from the outside in: Bucket-level read-write locks on the session group's global hash index table; The mutex lock for the session group object; Bucket-level read-write locks on the join descriptor secondary index table; The session object's own mutex lock.

4. The IP-PBX multi-terminal concurrent logon session management method of claim 3, wherein, In the step of setting up a hierarchical locking protocol and using reference counting for lifecycle management, the reference counting for lifecycle management includes: Both session groups and sessions use reference counting; Any thread increments the reference count before accessing an object and decrements it when the access ends; Memory is only truly released when the reference count reaches zero and the object has been marked for destruction.

5. The IP-PBX multi-terminal concurrent logon session management method of claim 1, wherein, The step of establishing a multi-dimensional key type session retrieval engine includes: Within the session group, a unified multi-dimensional key type retrieval interface is provided. The caller only needs to pass three parameters: "username + matching key type + matching value" to obtain the target session. The matching key types include: device identifier, user agent, client type, connection descriptor, and session identifier; When performing session retrieval, first use the username to hit the group in the global hash index table in O(1) time, and then perform linear matching on the linked list with only a few elements in the group.

6. The IP-PBX multi-terminal concurrent logon session management method of claim 1, wherein, The execution of differentiated concurrency strategies and precise kick-out steps based on client type and SDK version includes: After a terminal successfully logs in, the new session is first added to its respective session group; The IP-PBX server core calculates and returns the "device identifier that should be disqualified from this login" based on the client type and SDK version of the currently online client of the account, as well as the corresponding attributes of the terminal that is currently logged in; If the identifier of "device identifier that should be kicked out by this login" is not empty, the server uses "device identifier" as the matching key to accurately locate the target session in the session group, sets it to be forcibly destroyed and marks it with "kicked out for login from other locations"; The IP-PBX server sends a structured notification to the kicked-out client, which includes a field for the reason for disconnection. Based on this, the client can accurately distinguish different disconnection semantics on the interface, such as "administrator disconnected / incorrect password / multiple devices blocking access". The IP-PBX server notifies the PBX core synchronization push status at the device identifier level, only disqualifying the kicked end from making call pushes; other online ends under the same account are unaffected.

7. The IP-PBX multi-terminal concurrent logon session management method of claim 1, wherein, The device-level distribution steps for events, push notifications, and CTI status, using the device identifier as the primary key, include: The device identifier is elevated to the first-level key for event distribution. Call ringing, message notification, CTI status, third-party push, and recording control commands are all transmitted by the distribution module in the following path: "Traverse the global hash index table of the session group as needed" to "Execute the primitive of adding reference and locking to the target group" to "Retrieve the target session within the group by multi-dimensional key" to "Send only to the target session".

8. The IP-PBX multi-terminal concurrent logon session management method of claim 1, wherein, The steps for supporting compatibility between old and new protocols and rolling upgrades include: To ensure compatibility between the old and new protocols, both old and new session structures coexist in the IP-PBX server, including: The new structure includes a session group association field and a multi-dimensional key field, while the old structure retains the flat semantics and the old field layout. The login entry is automatically routed to the corresponding structure based on the version characteristics in the terminal registration message; For older terminals that cannot recognize the newly added device identifier field, the system assigns a predefined default compatibility identifier to prevent them from being mistakenly kicked out in the multi-dimensional key distribution path. For existing CTI integrations, the system sends both the new and old notification numbers simultaneously to ensure that existing plugins function correctly.

9. The IP-PBX multi-terminal concurrent login session management method according to claim 1, characterized in that, The steps for performing session group activity aging detection and self-healing include: Each session group maintains a "last active time" stamp, which is periodically scanned by a background scheduled task; When a session group meets the three conditions of "the internal session list is empty, the reference count is zero, and the idle time exceeds the threshold", the scheduled task removes it from the hash table and releases it.

10. A multi-terminal concurrent login session management system for IP-PBX, characterized in that, The system includes: A global hash index table creation module is used to create a global hash index table with the username as the key and a two-level mapping. A hierarchical locking sequence protocol and lifecycle management module, wherein the hierarchical locking sequence protocol is set and reference counting is used for lifecycle management; A session retrieval engine building module, which builds a session retrieval engine with multi-dimensional key types; A login device kickout module, which executes differentiated concurrency strategies and precise kickout based on client type and SDK version; The device-level distribution module performs device-level distribution of events, push notifications, and CTI status, with the device identifier as the primary key. The compatibility and upgrade module supports compatibility with both old and new protocols and rolling upgrades. And an activity aging detection and self-healing module, which performs session group activity aging detection and self-healing.

Images