Active prevention method, device and product for SIP transaction-session double-layer deadlock

Abstract

The application provides a SIP transaction-conversation double-layer deadlock active prevention method, device and product in the field of IP multimedia communication technology, which comprises the following steps: a lock release flag bit is contained in a control flag parameter of a transaction state setting function; when the transaction state setting function is called and before a callback of a higher module is notified, whether the lock release flag bit is set is detected; if yes, the following steps are sequentially executed: a transaction group lock currently held is released; a transaction state change callback function of the higher module is called; after the callback is returned, the transaction group lock is re-acquired; a transaction unique identification key is extended into a four-tuple including a call identification field; in a transaction search function, a range matching including a termination state and a destroyed state is used as a termination state exclusion condition; when the transaction state setting function is called at multiple state conversion calling points, the lock release flag bit is set. According to the technical scheme, the transaction-conversation double-layer deadlock of a SIP signaling protocol processing kernel can be fundamentally eliminated.

Description

Technical Field

[0001] This invention relates to the field of IP multimedia communication technology, and in particular to a proactive prevention method, device and product for SIP transaction-dialogue double-layer deadlock applied to the SIP signaling protocol processing kernel. Background Technology

[0002] The Session Initiation Protocol (SIP) is a core signaling protocol in IP multimedia communication systems, widely used in enterprise IP PBXs, softswitch platforms, and unified communications systems. Modern high-concurrency IP PBX SIP protocol stack engines typically employ a layered architecture to handle signaling messages: the transaction layer manages the state machine of a single SIP request-response interaction (such as the state transitions of the INVITE transaction: Calling, Proceeding, Completed, Confirmed, Terminated), while the session layer manages the persistent session context across multiple transactions (such as maintaining the session state after call establishment). Each layer holds its own independent mutex lock—the transaction layer uses group locks to protect the atomicity of the transaction state machine, and the session layer uses session locks to protect the consistency of the session context.

[0003] However, traditional SIP protocol stack engines generally suffer from SIP transaction-dialogue double deadlock problems in transaction-dialogue double lock interactions, and existing technologies all adopt passive deadlock detection and recovery mechanisms, which cannot fundamentally eliminate the occurrence of deadlock. Summary of the Invention

[0004] Embodiments of the present invention provide a method, device, and product for proactively preventing SIP transaction-dialogue double-layer deadlock applied to the SIP signaling protocol processing kernel, which proactively prevents SIP transaction-dialogue double-layer deadlock based on the callback pre-lock release flag and the four-tuple transaction key.

[0005] To achieve the above objectives, on the one hand, a proactive prevention method for SIP transaction-dialogue two-layer deadlock is provided, applied to the SIP signaling protocol processing kernel. The kernel includes a transaction layer and a dialogue layer. The transaction layer uses group locking to protect the transaction state machine, and the dialogue layer uses dialogue locking to protect the session context. The proactive prevention method includes the following steps: Step S1: In the transaction state setting function, preset control flag parameters, including a lock release flag. When calling the transaction state setting function and before notifying the upper-level module to callback, check whether the lock release flag is set. If so, execute the following in sequence: release the currently held transaction group lock; call the transaction state change callback function of the upper-level module; after the callback returns, reacquire the transaction group lock. Step S2: Expand the transaction unique identifier key into a four-tuple, which includes: role identifier, method name, branch parameter and call identifier fields, and concatenate them according to a predetermined format to generate a four-tuple transaction key; Step S3: In the transaction lookup function, range matching is used as the exclusion condition for the final state; the range matching includes: the final state and the destroyed state; Step S4: When the transaction state setting function is called at the following state transition call point, the lock release flag is set: When the message sending callback detects a sending failure, the transaction transitions from its current state to the terminated state; and When a UAS role transaction receives an ACK message in the completed state, the transaction transitions from the completed state to the acknowledged state.

[0006] Preferably, in the proactive prevention method, the control flag parameter includes three independent flag bits that can be combined bitwise: a prohibition flag bit, a prohibition scheduler flag bit, and a lock release flag bit; step S1 further includes: when calling the transaction state setting function and before notifying the upper-layer module callback, detecting whether the event source is a timeout timer; if so, then sequentially executing: releasing the currently held transaction group lock; calling the transaction state change callback function of the upper-layer module; after the callback returns, reacquiring the transaction group lock.

[0007] Preferably, in the active prevention method, in step S1, the lock release flag is set only when the transaction has entered the final or confirmed state.

[0008] Preferably, in the active prevention method, step S2 includes: When allocating a transaction key buffer in the session-level memory pool, reserve the length of the call identifier field; Write the role identifier character, separator, method name, dollar sign separator, full text of branch parameters, and full text of call identifier into the buffer in sequence.

[0009] Preferably, in the active prevention method, step S2 further includes: Call identifier hard verification: During the UAC role transaction creation process, if the call identifier header field cannot be extracted from the message to be sent, the transaction group lock is released and transaction creation is terminated, returning an error code; otherwise, a four-tuple transaction key is generated using the branch parameters and the call identifier; and... In the transaction key creation process of inbound messages, the identifier field of the call identifier header field is extracted from the message information structure of the received data as the call identifier parameter used to generate the four-tuple transaction key.

[0010] Preferably, in the active prevention method, the termination state and the destroyed state are two adjacent termination states, and the state value of the destroyed state is greater than the state value of the termination state; the range matching covers the state values ​​of the destroyed state and the termination state.

[0011] Preferably, the active prevention method further includes: embedding a lock order recording mechanism in the group lock acquisition function, whereby each thread maintains a lock acquisition stack, and when it is detected that the currently acquired lock is ahead of an already held lock in the lock order graph, the lock is automatically released and the sequence is reacquired, thereby achieving automatic repair of lock order reversal at runtime.

[0012] Preferably, in the proactive prevention method, the transaction unique identifier key is expanded into a 5-tuple, and the 5-tuple further includes: the source transport address.

[0013] On the other hand, an electronic device is also provided, including a memory and a processor, the memory storing at least one program, the at least one program being executed by the processor to implement the steps of the proactive prevention method for SIP transaction-dialogue double deadlock as described in any of the above.

[0014] In another aspect, a computer program product is also provided, comprising a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the proactive prevention method for SIP transaction-dialogue double deadlock as described above.

[0015] The above technical solution has the following technical effects: By using a flag-driven callback-before-lock release mechanism, the AB-BA circular wait chain between transaction group locks and dialog locks in the traditional solution is broken, fundamentally eliminating transaction-dialog circular wait deadlock and reducing the deadlock rate of the system in high-concurrency scenarios from occasional to zero. By transforming the branch parameter collision problem from the indistinguishability of triples to the unique identification of quadruples, deadlocks and session confusion caused by transaction key collisions are eliminated, and the interoperability compatibility of the system with abnormal SBC / agent devices is improved. By simultaneously covering both the terminated and destroyed states through range matching, the race window during the transaction destruction process is eliminated, preventing operations from being performed on partially released transaction objects and improving the system's memory safety. By extending the lock release mechanism to two high-frequency deadlock paths—transmission errors and ACK confirmations—this approach covers the blind spots of traditional solutions. Furthermore, adding these new paths does not require modifying the core logic of the transaction state setting function, demonstrating good scalability and maintainability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an embodiment of the proactive prevention method for SIP transaction-dialogue double-layer deadlock according to the present invention. Figures 2a to 2d This is a flowchart illustrating another embodiment of the proactive prevention method for SIP transaction-dialogue double-layer deadlock according to the present invention. Figures 3a to 3d for Figures 2a to 2d The core timing diagram of the active prevention method in the illustrated embodiment shows a comparison between the deadlock scenario of the existing conventional solution and the deadlock active prevention solution of the present invention. Detailed Implementation

[0017] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments and to explain the operating principles of the embodiments in conjunction with the relevant descriptions in the specification. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention. Components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0018] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0019] In the process of researching the SIP transaction-dialogue double deadlock problem, the inventors of this application discovered the following defects in the traditional SIP protocol stack engine during transaction-dialogue double deadlock interaction: Defect 1: AB-BA Circular Wait Deadlock. The transaction state transition function holds the transaction group lock throughout its execution. When the state transition triggers a callback in the upper-level module, and the callback needs to acquire the transaction lock, if another thread already holds the transaction lock and is waiting for the transaction group lock, a classic AB-BA circular wait deadlock occurs. This deadlock frequently occurs in high-concurrency scenarios, causing the system to hang and unable to recover automatically.

[0020] Defect 2: Transaction key collision deadlock. Traditional solutions use only three fields for the unique identifier of a transaction: role identifier, method name, and branch parameters. When different SIP requests carry the same branch parameters (due to abnormal behavior of certain Session Border Controllers (SBCs) or proxy devices), transaction key collisions cause new requests to be incorrectly routed to existing transactions, leading to deadlocks and session confusion while the existing transactions are holding locks.

[0021] Defect 3: Race Window for Destroyed States. Traditional solutions use exact matching of a single terminated state as the exclusion condition in the transaction lookup function, overlooking destroyed states. During the brief window period when a transaction transitions from a terminated state to a destroyed state, other threads can still find the transaction through a hash table lookup and perform operations on the partially released transaction object, leading to memory access crashes or deadlocks.

[0022] Defect 4: Incomplete deadlock path coverage. Traditional solutions only handle locks specially in state transition paths triggered by timeout timers, failing to cover high-frequency state transition paths such as transmission error paths and paths where UAS role transactions receive ACK messages. Deadlocks frequently occur on these paths.

[0023] To overcome the above-mentioned defects, this invention proposes a proactive prevention scheme for SIP transaction-dialogue double-layer deadlock based on the pre-callback lock release flag and the quadruple transaction key. Through the collaborative design of four levels—lock release flag extension, quadruple transaction key generation, final state range extension, and multi-path lock release injection—the transaction-dialogue double-layer deadlock is fundamentally eliminated.

[0024] Example 1: Figure 1 This is a flowchart illustrating an embodiment of the proactive prevention method for SIP transaction-dialogue double-layer deadlock according to the present invention. The method in this embodiment is applied to the SIP signaling protocol processing kernel, which includes a transaction layer and a dialogue layer. The transaction layer uses group locking to protect the transaction state machine, and the dialogue layer uses dialogue locking to protect the session context. The proactive prevention method includes the following steps: Step S1: In the transaction state setting function, preset control flag parameters, including the lock release flag. When the transaction state setting function is called and before notifying the upper-level module callback, check whether the lock release flag is set. If so, execute the following in sequence: release the currently held transaction group lock; call the transaction state change callback function of the upper-level module; after the callback returns, reacquire the transaction group lock. Step S2: Expand the transaction unique identifier key into a four-tuple, which includes: role identifier, method name, branch parameter and call identifier fields, and concatenate them according to a predetermined format to generate a four-tuple transaction key; Step S3: In the transaction lookup function, range matching is used as the exclusion condition for the final state; the range matching includes: the final state and the destroyed state; Step S4: When the transaction state setting function is called at the following state transition call point, the lock release flag is set: When the message sending callback detects a sending failure, the transaction transitions from its current state to the terminated state; and When a UAS role transaction receives an ACK message in the completed state, the transaction transitions from the completed state to the acknowledged state.

[0025] Example 2: Reference Figures 2a-2d and Figures 3a-3d This invention explains the SIP transaction-dialogue double-layer deadlock proactive prevention method according to an embodiment of the present invention. The method of this embodiment includes the following steps: Step S1, corresponding to Figure 2a and Figure 3a In Phase 1, to address the deadlock problem of AB-BA loop wait, this paper introduces a lock release flag in the transaction state transition control enumeration, that is, expands the preset control flag parameters in the transaction state setting function to include the lock release flag.

[0026] The deadlock sequence in existing traditional solutions is as follows: Thread A acquires the transaction group lock, triggering a callback from the upper-level module, in which it attempts to acquire the session lock; simultaneously, thread B acquires the session lock and attempts to acquire the transaction group lock. The two threads wait for each other, forming an AB-BA deadlock that cannot be automatically resolved.

[0027] An improved embodiment of the present invention adds a third flag bit as a lock release flag bit to the flag bit enumeration of the transaction state setting function. This flag bit is listed alongside the existing "disable notification" flag and "disable scheduler" flag, forming a three-bit independently controlled flag bit combination. Preferably, the value of the lock release flag is 4, corresponding to the third bit in binary; the value of the "disable notification" flag is 1, corresponding to the first bit in binary; and the value of the "disable scheduler" flag is 2, corresponding to the second bit in binary.

[0028] When the transaction state setting function is called, before notifying the upper-level module callback, it checks whether the flags contain a lock release flag or whether the event source is a timeout timer. If the conditions are met, the following three-step atomic operation sequence is executed: Step 1: Call the group lock release function to release the currently held transaction group lock; Step 2: Call the transaction state change callback function of the upper module. At this time, the callback function can safely acquire the dialog lock without forming a circular wait. Step 3: After the callback returns, call the group lock acquisition function to reacquire the transaction group lock and restore the lock protection state of the transaction layer.

[0029] The security of this design is based on the following premise: lock release only occurs when a transaction has entered the final or confirmed state. At this time, the transaction state change has been completed, and other threads' operations on the transaction are limited to lookup and reference counting management, and will not modify the core state of the transaction.

[0030] In addition, such as Figure 2a The detection conditions for this step also include: determining that the event source release is a timeout timer; if so, even if the lock release flag is not set in the control flag parameters, the above three-step operation sequence is still executed to maintain compatibility with existing timeout timer paths.

[0031] Step S2, corresponding to Figure 2b and Figure 3b In Phase Two, to address the deadlock issue caused by transaction key collisions, the unique identifier key for a transaction is expanded from a triple to a quadruple.

[0032] Traditional ternary transaction keys include: role identifier, method name, and branch parameters; they cannot distinguish between different transactions when branch parameters collide, causing new requests to be routed to existing transactions, leading to deadlocks while holding locks.

[0033] This invention expands the transaction unique identifier key into a four-tuple, adding a call-ID field to the original three fields. The specific implementation is as follows: Step 2.1, Memory Allocation Extension: When allocating the transaction key buffer in the session-level memory pool, additional length of the call identifier field is reserved. The total allocation is "branch parameter length + method name length + 4-byte fixed overhead + call identifier length".

[0034] Step 2.2, Key-value concatenation: Write the role identifier character ('c' for client roles and 's' for server roles), separator, method name (skipping INVITE and ACK methods to save space), dollar sign separator, full branch parameter text, and full call identifier text into the buffer sequentially. The final key-value length is the difference between the write pointer and the start pointer.

[0035] Step 2.3, Inbound Message Key Extraction: In the transaction key creation function of the inbound message, extract the identifier field of the call identifier header field from the message information structure of the received data, and pass it as the fourth parameter to the quadruple key generation function.

[0036] Step 2.4, UAC Transaction Creation Key Generation: In the UAC role transaction creation process, the call identifier header field is extracted from the message to be sent. If the call identifier header field does not exist, the transaction group lock is released and the transaction creation is terminated, returning an error code. If it exists, a four-tuple transaction key is generated using the branch parameters and the call identifier.

[0037] In an optional extended implementation, the quadruple transaction key can be further extended to a quintuple, with the source transmission address added as a fifth field in addition to the call identifier field, to support the creation of independent transactions for the same call identifier on different transmission paths in scenarios with multiple network cards and multiple transmission instances.

[0038] Step S3, with Figure 2c and Figure 3c In the third phase of the process, the determination of the transaction finality state is expanded from exact matching to range matching to address the race window problem of the destroyed state.

[0039] In the SIP transaction state enumeration, the TERMINATED and DESTROYED states are two adjacent final states, with the DESTROYED state value being greater than the TERMINATED state value. Traditional solutions exclude final states in the transaction lookup function by requiring an exact match of the TERMINATED state (state == TERMINATED). This allows the transaction to still be found in the hash table during the brief window between its transition from the TERMINATED to the DESTROYED state. Performing operations on partially released transaction objects can lead to memory access crashes or deadlocks.

[0040] In this embodiment of the invention, the termination state exclusion condition in the transaction lookup function is modified from an exact match to a single termination state (i.e., equal to the termination state) to a range match; preferably, the range match is greater than or equal to the termination state (i.e., state>=TERMINATED). After modification, the range match covers both termination states simultaneously, ensuring that transactions in the destruction process will not be matched in the hash table, thus eliminating the aforementioned race window.

[0041] Step S4, with Figure 2d and Figure 3d In Phase 4, to address the issue of incomplete coverage of high-frequency deadlock paths, lock release flags are injected into multiple high-frequency deadlock paths.

[0042] The system injects the lock release flag defined in step S1 at the following three state transition call points: Step 4.1, Error Path: When the message sending callback detects a sending failure (return value is negative), the transaction transitions from the current state to the terminated state. When calling the transaction state setting function, the lock release flag is passed as the fifth parameter. This path is frequently triggered in scenarios such as network fluctuations and TLS connection drops, and is one of the main hotspots for deadlock.

[0043] Step 4.2, UAS Completed State ACK Path: After the UAS role transaction receives the ACK message in the completed state, the transaction transitions from the completed state to the acknowledged state. When calling the transaction state setting function, the lock release flag is passed as the fifth parameter. This path is inevitably triggered during each normal call establishment process and is another major hotspot for deadlock.

[0044] Step 4.3 enhances the existing mechanism by combining the timeout timer path processing from Step S1 with Step S4. By merging the lock release flag and timeout timer determination using a logical OR relationship, comprehensive coverage of the three main deadlock hotspot paths is achieved. Traditional solutions only release locks on timeout timer paths; this invention extends lock release capability to any state transition path through a flag bit mechanism. Since adding a new path only requires setting the control flag parameter at the call point, without modifying the internal logic of the transaction state setting function, the maintenance cost of subsequent path expansion is extremely low.

[0045] This invention employs four collaborative steps to proactively eliminate four types of deadlocks: AB-BA cyclic wait deadlock, transaction key collision deadlock, destroyed state race window, and high-frequency path deadlock blind spot. These four steps work together to form a complete deadlock prevention architecture.

[0046] Example 3: Based on Embodiment 1 or Embodiment 2, the present invention further includes the steps of online detection and automatic repair of lock sequence reversal.

[0047] In specific implementations, based on steps S1-S4 or steps S1 to S4, a lock order recording mechanism can be embedded in the lock acquisition function: each thread maintains a lock acquisition stack, recording the set of locks currently held by the thread and their acquisition order. When it is detected that the lock to be acquired is ahead of an already held lock in the global lock order graph, i.e., when a lock order reversal is detected, the lock is automatically released and the sequence is reacquired. This achieves automatic detection and repair of runtime lock order reversal problems, rather than static prevention at compile time, as a supplementary guarantee to the active prevention mechanism of this invention.

[0048] Example 4: In another alternative implementation, the use of transaction group locks is replaced with a lock-free implementation, specifically including: changing the transaction state field from mutex lock protection to atomic variable operations, and implementing state transitions through compare-and-swap (CAS) atomic instructions, completely eliminating the lock requirements of the transaction layer and eradicating the possibility of transaction-dialogue double deadlock from the architectural level.

[0049] Example 5: The present invention also provides an electronic device including a memory and a processor, the memory storing at least one program, the at least one program being executed by the processor to implement the steps of the proactive prevention method for SIP transaction-dialogue double deadlock as described above.

[0050] 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, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer unit, connecting various parts of the entire computer unit via various interfaces and lines.

[0051] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer unit by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. 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, RAM, plug-in hard disk, smart media card (SMC), secure digital card (SD card), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0052] Example 6: The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described above.

[0053] 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 proactive method for preventing SIP transaction-dialogue two-layer deadlock, applied to a SIP signaling protocol processing kernel, wherein the kernel includes a transaction layer and a dialogue layer, the transaction layer uses group locking to protect the transaction state machine, and the dialogue layer uses dialogue locking to protect the session context, characterized in that... The proactive prevention method includes the following steps: Step S1: In the transaction state setting function, preset control flag parameters, including a lock release flag. When calling the transaction state setting function and before notifying the upper-level module to callback, check whether the lock release flag is set. If so, execute the following in sequence: release the currently held transaction group lock; call the transaction state change callback function of the upper-level module; after the callback returns, reacquire the transaction group lock. Step S2: Expand the transaction unique identifier key into a four-tuple, which includes: role identifier, method name, branch parameter and call identifier fields, and concatenate them according to a predetermined format to generate a four-tuple transaction key; Step S3: In the transaction lookup function, range matching is used as the exclusion condition for the final state; the range matching includes: the final state and the destroyed state; Step S4: When the transaction state setting function is called at the following state transition call point, the lock release flag is set: When the message sending callback detects a sending failure, the transaction transitions from its current state to the terminated state; and When a UAS role transaction receives an ACK message in the completed state, the transaction transitions from the completed state to the acknowledged state.

2. The active prevention method according to claim 1, characterized in that, The control flag parameters include three independent flags that can be combined bitwise: a prohibition flag, a prohibition scheduler flag, and a lock release flag; step S1 further includes: when calling the transaction state setting function and before notifying the upper-level module callback, checking whether the event source is a timeout timer; if so, then executing the following in sequence: releasing the currently held transaction group lock; calling the transaction state change callback function of the upper-level module; after the callback returns, reacquiring the transaction group lock.

3. The active prevention method according to claim 1, characterized in that, In step S1, the lock release flag is set only when the transaction has entered the final or confirmed state.

4. The active prevention method according to claim 1, characterized in that, Step S2 includes: When allocating a transaction key buffer in the session-level memory pool, reserve the length of the call identifier field; Write the role identifier character, separator, method name, dollar sign separator, full text of branch parameters, and full text of call identifier into the buffer in sequence.

5. The active prevention method according to claim 1 or 4, characterized in that, Step S2 further includes: Call identifier hard verification: During the UAC role transaction creation process, if the call identifier header field cannot be extracted from the message to be sent, the transaction group lock is released and transaction creation is terminated, returning an error code; otherwise, a four-tuple transaction key is generated using the branch parameters and the call identifier; and... In the transaction key creation process of inbound messages, the identifier field of the call identifier header field is extracted from the message information structure of the received data as the call identifier parameter used to generate the four-tuple transaction key.

6. The active prevention method according to claim 1, characterized in that, The termination state and the destroyed state are two adjacent termination states, and the state value of the destroyed state is greater than the state value of the termination state; the range matching covers the state values ​​of the destroyed state and the termination state.

7. The active prevention method according to claim 1, characterized in that, It also includes: embedding a lock order recording mechanism in the group lock acquisition function, where each thread maintains a lock acquisition stack, and when it is detected that the currently acquired lock is ahead of an already held lock in the lock order graph, it automatically triggers the lock release and reacquisition sequence, thus achieving automatic repair of lock order reversal at runtime.

8. The active prevention method according to claim 1 or 4, characterized in that, The transaction unique identifier key is expanded into a 5-tuple, which also includes the source transport address.

9. An electronic device, characterized in that, The system includes a memory and a processor, the memory storing at least one program that is executed by the processor to implement the steps of the proactive prevention method for SIP transaction-dialogue double deadlock as described in any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the proactive prevention method for SIP transaction-dialogue double deadlock as described in any one of claims 1 to 8.

Images