A port multiplexing session life cycle management method and device

Abstract

This invention discloses a method and apparatus for managing the lifecycle of port multiplexing sessions, belonging to the field of real-time communication technology. The method defines an RTCP channel type enumeration state machine, including a disabled state, a standard independent port state, and a single-port multiplexing state; it parses the RTCP multiplexing attributes in the SDP and determines the channel type based on the local configuration; it dynamically adjusts the ICE component count according to the channel type; it performs socket dual-mode management, pointing the RTCP socket to the RTP socket and performing double-close protection in the multiplexing state; it tracks resource ownership at the DTLS layer through pointer equality comparison; it triggers TURN resource security destruction when the ICE component count drops from 2 to 1; it executes single-component bypass logic in ICE candidate verification; and it performs remote address dual-mode synchronization according to the channel type. This invention, through the enumeration state machine and resource ownership tracking, achieves dynamic topology adaptation and secure resource sharing of ICE components in RTCP-MUX mode, eliminates concurrency defects such as double-close and double-release, and improves WebRTC interoperability and system stability.

Description

Technical Field

[0001] This invention relates to the field of Internet protocol communication and real-time media transmission technology, and in particular to a method and apparatus for managing the lifecycle of port multiplexing sessions. Background Technology

[0002] In modern real-time communication systems, RTP is used to carry voice and video media streams, while RTCP is used to transmit statistical feedback and quality control information. Traditional SIP media engines follow the RFC 3550 specification, allocating separate UDP ports for RTP and RTCP (RTP port N and RTCP port N+1). The ICE framework is hardcoded into a two-component mode when a session is established.

[0003] However, with the widespread adoption of the WebRTC protocol, the RTCP-MUX mechanism defined in RFC 5761 requires RTCP to be multiplexed onto the same RTP port for transmission. This poses a systemic challenge to traditional architectures: First, the ICE component topology is rigidly bound. Traditional ICE frameworks have a fixed number of two components and cannot dynamically switch to single-component mode at runtime based on SDP negotiation results, leading to redundant RTCP candidate verification failures or ICE negotiation timeouts. Second, resource ownership becomes chaotic during mode switching. The UDP sockets, DTLS secure session objects, and TURN relay sockets of the RTCP subsystem are created and managed independently. When switching from dual-port mode to single-port multiplexing mode at runtime, socket multiplexing leads to double closing, DTLS session object sharing leads to double releasing, and cross-library lock contention during TURN resource destruction leads to cross-deadlock. Third, the remote address management strategy is not adaptive. Traditional solutions use a hard-coded derivation strategy of "RTP remote port + 1 = RTCP remote port," which cannot automatically switch to the semantics of sharing the same transport address in multiplexing mode, resulting in RTCP packets being sent to the wrong port and quality feedback links being interrupted.

[0004] Therefore, how to achieve dynamic topology adaptation and secure resource sharing of ICE components in RTCP-MUX mode, eliminate concurrency defects such as double shutdown and double release, and improve WebRTC interoperability and system stability 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 managing the lifecycle of port reuse sessions, which can solve problems such as rigid binding of ICE component topology, chaotic resource ownership during mode switching, and non-adaptive remote address management in the prior art.

[0006] The first aspect of this invention provides a method for managing the lifecycle of port multiplexing sessions, comprising:

[0007] Define an RTCP channel type enumeration state machine, which includes a disabled state, a standard independent port state, and a single-port multiplexing state; The RTCP multiplexing attribute in the remote media description is parsed at the SIP session description protocol processing layer. The RTCP channel type is determined in combination with the local endpoint configuration, and an RTP instance is injected through the attribute setting interface. The ICE component count is dynamically adjusted based on the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, the number of ICE components is set to 1, and when it is determined to be a standard independent port state, the number of ICE components is set to 2. Socket dual-mode management is performed according to the RTCP channel type. An independent UDP socket is created in the standard independent port state, and the RTCP socket is pointed to the RTP socket and a double-close protection detection is performed in the single-port multiplexing state. Ownership tracking is performed at the DTLS secure session layer. A pointer equality comparison is used to determine whether RTCP holds an independent SSL object. If it does hold an independent SSL object, a release operation is performed. When the number of ICE components decreases from 2 to 1, the TURN relay resource destruction process is triggered, and deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms are executed. During the ICE candidate verification process, single-component bypass logic is executed based on the ICE component count. When the component count is 1, the absence of RTCP candidates is tolerated. An ICE checklist is created based on RTP candidates, and remote candidates with component identifiers greater than 1 are automatically filtered. In the remote address setting function, dual-mode synchronization is performed according to the RTCP channel type. In the standard independent port mode, the RTCP port is derived from the RTP port, and in the single-port multiplexing mode, RTCP directly shares the RTP address.

[0008] Optionally, the ICE component count is dynamically adjusted based on the RTCP channel type obtained from the decision, including: Register a component count change interface in the ICE engine. The component count change interface is used to receive the target component count parameter. When an ICE session exists and the current number of components differs from the target number of components, atomically update the ICE component number field maintained in the RTP instance; Retain the current ICE role, destroy the original ICE session, and rebuild a new ICE session with the target number of components.

[0009] Optionally, socket dual-mode management is performed based on the RTCP channel type, including: In the standard standalone port state path, create a standalone UDP socket and bind it to the RTP local port plus one, and register the RTCP component candidate address with the ICE framework; In a single-port multiplexed path, a double-close protection detection is performed, and the close operation is only performed when RTCP currently holds an independent socket and that socket is not equal to the RTP socket; Point the RTCP socket descriptor to the RTP socket descriptor to achieve port multiplexing.

[0010] Optionally, ownership tracking is performed at the DTLS secure session layer, determining whether RTCP holds an independent SSL object through pointer equivalence comparison, including: In the DTLS session termination function, an equality comparison is performed between the SSL object pointer of RTCP and the SSL object pointer of RTP. When the two pointers are not equal, it is determined that RTCP holds an independent SSL object, and normal release is performed; When the two pointers are equal, it is determined that the RTCP shares the SSL object of RTP, and only the null pointer is set without calling the release function; Inject the same decision logic into the DTLS renegotiation path, and perform independent key renegotiation on RTCP only when the two pointers are not equal.

[0011] Optionally, when the number of ICE components decreases from 2 to 1, a TURN relay resource destruction process is triggered, including: The pre-test checks whether the number of ICE components is 1 and whether the RTCP TURN socket is not empty; Release the RTP instance-level exclusive lock to avoid cross-waiting with the underlying protocol stack group lock; Call the TURN socket asynchronous destruction interface to trigger the TURN state transition; After reacquiring the instance lock, the system blocks and waits for the TURN state to transition to the completion state through a condition variable timeout waiting mechanism.

[0012] Optionally, single-component bypass logic is executed during the ICE candidate verification process, including: In the ICE remote candidate startup function, adaptive logic is implemented based on the digital segment of the ICE component. When the number of components is greater than 1, a warning is issued and the process terminates if there is a lack of RTCP candidates; When the number of components is 1, the absence of RTCP candidates is tolerated, and the creation of the ICE checklist is allowed based solely on RTP candidates. In single-port reuse mode, remote candidates with component identifiers greater than 1 are automatically skipped to avoid injecting invalid candidates into the ICE framework.

[0013] Optionally, dual-mode synchronization is performed in the remote address setting function according to the RTCP channel type, including: In standard independent port mode, the RTCP remote port is automatically set to the RTP remote port plus one, and the RTCP local port is synchronously set to the RTP local port plus one. In single-port multiplexing mode, the RTCP remote address is set to the same address and port as the RTP remote address, and the RTCP local address is set to the same address and port as the RTP local address. Type detection is injected into the NAT symmetric RTP learning path, and the RTCP remote address is updated and port increment derivation is performed only in the standard independent port state through NAT address learning. During the channel file descriptor registration process, independent RTCP file descriptors are not registered in single-port multiplexing mode.

[0014] A second aspect of the present invention provides a port multiplexing session lifecycle management device, comprising: The state machine definition unit is used to define the RTCP channel type enumeration state machine, which includes the disabled state, the standard independent port state, and the single-port multiplexing state. The SDP decision unit is used to parse the RTCP multiplexing attribute in the remote media description at the SIP session description protocol processing layer, combine the local endpoint configuration to determine the RTCP channel type, and inject the RTP instance through the attribute setting interface. The ICE component adjustment unit is used to dynamically adjust the ICE component count based on the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, the number of ICE components is set to 1; when it is determined to be a standard independent port state, the number of ICE components is set to 2. The socket management unit is used to perform dual-mode socket management according to the RTCP channel type. In the standard independent port mode, it creates an independent UDP socket, and in the single-port multiplexing mode, it points the RTCP socket to the RTP socket and performs double-close protection detection. The DTLS tracing unit is used to perform ownership tracing at the DTLS secure session layer. It determines whether RTCP holds an independent SSL object by comparing pointers, and performs a release operation if it holds an independent SSL object. The TURN destruction unit is used to trigger the TURN relay resource destruction process when the number of ICE components decreases from 2 to 1, and to perform deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms. The ICE bypass unit is used to execute single-component bypass logic based on the ICE component count during the ICE candidate verification process. When the component count is 1, it tolerates the absence of RTCP candidates, creates an ICE checklist based on RTP candidates, and automatically filters remote candidates with component identifiers greater than 1. The address synchronization unit is used to perform dual-mode synchronization based on the RTCP channel type in the remote address setting function. In the standard independent port mode, the RTCP port is derived from the RTP port, and in the single-port multiplexing mode, RTCP directly shares the RTP address.

[0015] A third aspect of the present invention provides a port multiplexing session lifecycle management device, 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 port multiplexing session lifecycle 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, is used to implement the port multiplexing session lifecycle management method as described in any of the preceding claims.

[0017] Beneficial effects: This invention enables seamless switching between dual-port and single-port operation during runtime, is fully compatible with RFC 5761 RTCP-MUX protocol requirements, and eliminates the ICE negotiation failure problem with WebRTC clients.

[0018] This invention eliminates three fatal concurrency defects at the architectural level—double-closing of sockets, double-release of SSL objects, and hanging of TURN resources—through a unified ownership tracking mechanism based on pointer equivalence detection, thus ensuring system stability in high-concurrency scenarios.

[0019] The single-component mode of this invention reduces the number of ICE candidate pairs by 50%, directly shortens the connectivity detection time window, and accelerates the WebRTC call establishment speed.

[0020] In the MUX mode of this invention, each call saves the resource overhead of 1 UDP socket, 1 ICE component, and 1 independent DTLS secure session, significantly freeing up system resources in scenarios with thousands of concurrent calls. 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 A flowchart illustrating a port reuse session lifecycle management method provided in an embodiment of the present invention; Figure 2 A schematic diagram of a port multiplexing session lifecycle 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 managing the lifecycle of port multiplexing sessions, which achieves complete RTCP-MUX session resource management based on an RTCP channel type enumeration state machine and multi-dimensional resource ownership tracking.

[0024] See Figure 1 This figure is a flowchart illustrating a port multiplexing session lifecycle management method provided in an embodiment of the present invention. The port multiplexing session lifecycle management method provided in this embodiment of the present invention can be implemented, for example, through the following steps S101-108.

[0025] S101: Define the RTCP channel type enumeration state machine, which includes the disabled state, standard independent port state, and single-port multiplexing state.

[0026] In this embodiment of the invention, a three-value enumeration of RTCP channel types is defined in the header file of the media transmission engine: `DISABLED` (disabled state, value = 0), `STANDARD` (standard independent port state, value = 1), and `MUX` (single-port multiplexing state, value = 2). A `type` field is added to the RTCP control channel substructure to store the current enumeration value. This field serves as a unified mode determination predicate for the entire system, running through all code paths including socket management, DTLS handshake decision-making, address synchronization, and ICE candidate verification.

[0027] S102: The RTCP multiplexing attribute in the remote media description is parsed at the SIP session description protocol processing layer, the RTCP channel type is determined in combination with the local endpoint configuration, and the RTP instance is injected through the attribute setting interface.

[0028] In this embodiment of the invention, a two-phase negotiation logic is implemented in the SIP session description protocol processing layer: (a) the `a=rtcp-mux` attribute in the remote SDP media description is parsed, and the result is written to the `remote_rtcp_mux` boolean flag in the session media structure; (b) the `enable_rtcp()` function combines the local endpoint configuration (whether RTCP-MUX is enabled) and the remote capability flag to determine whether the RTCP channel type is MUX or STANDARD, and injects the RTP instance through the attribute setting interface. This decision is executed uniformly at the three entry points of SDP response creation, SDP response processing, and SDP negotiation callback to ensure the consistency of the negotiation results.

[0029] In one implementation of this invention, a multi-level policy engine is introduced to support weighted decision-making based on multiple factors such as terminal type (WebRTC / SIP phone / mobile terminal), network environment (NAT type detection result), and concurrent load level. When the system is under high load, it can actively force a switch to MUX mode to save resources, or automatically downgrade to STANDARD mode and dynamically rebuild the ICE session when the peer does not support MUX.

[0030] S103: Dynamically adjust the ICE component count based on the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, set the ICE component count to 1. When it is determined to be a standard independent port state, set the ICE component count to 2.

[0031] In this embodiment of the invention, a component number change interface is registered in the ICE engine. The component number change interface is used to receive the target component number parameter. When an ICE session exists and the current component number is different from the target component number, the ICE component number field maintained in the RTP instance is atomically updated. The current ICE role is retained, the original ICE session is destroyed, and a new ICE session is rebuilt with the target component number.

[0032] Specifically, the `change_components` method pointer is extended and registered in the ICE engine interface method table. Its core implementation function receives the target number of components as a parameter and performs three steps: (a) a pre-guard check—if ICE is not enabled, the ICE session does not exist, or the number of components has not changed, it returns directly; (b) it atomically updates the `ice_num_components` field in the RTP instance structure; and (c) it calls the ICE session reset function—preserving the current ICE role (controlling / controlled), destroying the old session, and reconstructing the ICE session with the new number of components. The `set_ice_components()` function in the SDP processing layer calls this interface based on the negotiation result, passing 1 for MUX mode and 2 for STANDARD mode.

[0033] S104: Perform socket dual-mode management according to the RTCP channel type. Create an independent UDP socket in standard independent port mode, and point the RTCP socket to the RTP socket and perform double-close protection detection in single-port multiplexing mode.

[0034] In this embodiment of the invention, in the standard independent port state path, an independent UDP socket is created and bound to the RTP local port plus one, and the RTCP component candidate address is registered with the ICE framework; in the single port multiplexing state path, a double-close protection detection is performed, and the close operation is only performed when RTCP currently holds an independent socket and the socket is not equal to the RTP socket; the RTCP socket descriptor is pointed to the RTP socket descriptor to realize port multiplexing.

[0035] Specifically, the RTCP attribute setting function is divided into two paths based on the channel type enumeration value: STANDARD path: Create an independent UDP socket, bind it to the local RTP port +1, register the RTCP component candidate address with the ICE framework, and initialize an independent DTLS secure session.

[0036] MUX Path: First, perform double-close protection detection—close the socket only if RTCP currently holds an independent socket (`rtcp_socket>-1`) and that socket is not equal to the RTP socket, to prevent accidental closure of the shared RTP socket while already in MUX mode; directly point the RTCP socket descriptor to the RTP socket descriptor to achieve zero-copy port reuse; directly copy the RTCP remote address to the RTP remote address (without port +1 derivation); point the RTCP DTLS secure session object pointer to the RTP DTLS object to achieve secure transport layer sharing.

[0037] The destruction phase also uses pointer equivalence checks: `if (rtcp_socket>-1&&rtcp_socket != rtp_socket)` to ensure that only independent sockets are closed.

[0038] S105: Perform ownership tracking at the DTLS secure session layer, determine whether RTCP holds an independent SSL object by pointer equality comparison, and perform a release operation if it holds an independent SSL object.

[0039] In this embodiment of the invention, in the DTLS session termination function, the SSL object pointer of RTCP is compared with the SSL object pointer of RTP. When the two pointers are not equal, it is determined that RTCP holds an independent SSL object and performs normal release. When the two pointers are equal, it is determined that RTCP shares the SSL object of RTP, and only the null pointer is set without calling the release function. The same determination logic is injected into the DTLS renegotiation path, and independent key renegotiation is performed on RTCP only when the two pointers are not equal.

[0040] Specifically, in the DTLS session termination function, ownership determination logic is constructed through an equality comparison of SSL object pointers: `rtcp_dtls_unique = rtp_ssl ? (rtp_ssl != rtcp_ssl) : 1`. When the result is 1 (RTCP holds an independent SSL object), a normal release is performed; when the result is 0 (RTCP shares the RTP's SSL object), only a null pointer is set without calling the release function, thus preventing double-freeing at the architectural level. This protection logic is synchronously injected into the DTLS renegotiation path: only when the RTCP's SSL object pointer is not equal to the RTP's SSL object pointer is an independent key renegotiation operation performed on RTCP.

[0041] In one implementation of this invention, an independent atomic reference counter is introduced for each shared resource (socket, DTLS session object). In MUX mode, sharing operations increment the counter by 1, and releasing operations decrement the counter by 1, with actual release only performed when the counter reaches zero. This invention offers better scalability for future expansion scenarios supporting three-party or multi-party RTP sessions sharing the same DTLS context, but introduces additional atomic operation overhead.

[0042] S106: When the number of ICE components decreases from 2 to 1, the TURN relay resource destruction process is triggered, and deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms are executed.

[0043] In this embodiment of the invention, the following steps are taken: first, check whether the number of ICE components is 1 and whether the RTCP TURN socket is not empty; release the RTP instance-level exclusive lock to avoid cross-waiting with the underlying protocol stack group lock; call the TURN socket asynchronous destruction interface to trigger the TURN state transition; after reacquiring the instance lock, block and wait for the TURN state transition to the completion state through the condition variable timeout waiting mechanism.

[0044] Specifically, when the ICE session is reset and the number of components has decreased from 2 to 1, the TURN relay resource destruction process is triggered: (a) Precondition check: `ice_num_components == 1 && turn_rtcp_socket != NULL`; (b) Deadlock avoidance: release the RTP instance-level exclusive lock to avoid cross-waiting with the group lock of the underlying PJSIP protocol stack; (c) call the TURN socket asynchronous destruction interface to trigger the TURN state transition; (d) reacquire the instance lock; (e) block and wait for the TURN state to transition to the `DESTROYING` completion state through the condition variable timeout wait mechanism (`TURN_STATE_WAIT_TIME` millisecond timeout), and timeout protection prevents infinite blocking.

[0045] S107: During the ICE candidate verification process, single-component bypass logic is executed based on the ICE component count. When the component count is 1, the absence of RTCP candidates is tolerated. An ICE checklist is created based on RTP candidates, and remote candidates with component identifiers greater than 1 are automatically filtered.

[0046] In this embodiment of the invention, adaptive logic is implemented based on the digital segment of the ICE component in the ICE remote candidate startup function; when the number of components is greater than 1, a warning is issued and the process terminates if there is a missing RTCP candidate; when the number of components is 1, the absence of RTCP candidates is tolerated, and the creation of the ICE checklist is allowed based solely on RTP candidates; in single-port multiplexing mode, remote candidates with component identifiers greater than 1 are automatically skipped to avoid injecting invalid candidates into the ICE framework.

[0047] Specifically, in the ICE remote candidate startup function, three adaptive logics are implemented based on the `ice_num_components` field: (a) RTCP candidate missing tolerance: warnings are issued and the process terminates only when the number of components is greater than 1 due to the lack of RTCP candidates; (b) ICE checklist creation condition: `has_rtp&&(has_rtcp || ice_num_components == 1)`, single-component mode allows the creation of checklists based solely on RTP candidates; (c) SDP layer RTCP candidate filtering: in MUX mode, remote candidates with candidate identifiers greater than 1 (i.e., RTCP components) are automatically skipped to avoid injecting invalid candidates into the ICE framework.

[0048] In one implementation of this invention, the component counting adaptive engine can be extended to support RTP / RTCP / RTCPFB (Extended Feedback) tri-protocol multiplexing scenarios. This is achieved by extending the enumeration state machine to multi-value enumeration (e.g., adding a `MUX_EXTENDED` state) and adding awareness of extended attributes such as `a=rtcp-rsize` (simplified RTCP) at the SDP parsing layer, thus enabling broader protocol multiplexing topology management. Simultaneously, the design of the ICE component counting adaptive engine can be reused in future QUIC transport protocol stack multi-stream multiplexing scenarios. By mapping component concepts to QUIC stream identifiers, the secure release of multi-stream shared transport connections is managed using the same resource ownership tracking mechanism.

[0049] S108: In the remote address setting function, dual-mode synchronization is performed according to the RTCP channel type. In the standard independent port mode, the RTCP port is derived from the RTP port. In the single-port multiplexing mode, RTCP directly shares the RTP address.

[0050] In this embodiment of the invention, under standard independent port mode, the RTCP remote port is automatically set to the RTP remote port plus one, and the RTCP local port is synchronously set to the RTP local port plus one; under single-port multiplexing mode, the RTCP remote address is set to the same address and port as the RTP remote address, and the RTCP local address is set to the same address and port as the RTP local address; type detection is injected into the NAT symmetric RTP learning path, and the RTCP remote address is updated and port incremented is performed only under standard independent port mode; in the channel file descriptor registration stage, independent RTCP file descriptors are not registered under single-port multiplexing mode.

[0051] Specifically, type-aware dual-mode synchronization is implemented in the remote address setting function: In STANDARD mode, the RTCP remote port is automatically set to the RTP remote port + 1, and the RTCP local port is synchronously set to the RTP local port + 1; in MUX mode, the RTCP remote address is directly copied from the RTP remote address (with the same port), and the RTCP local address directly uses the RTP local address. Type detection is also injected into the NAT symmetric RTP learning path: only in STANDARD mode is the RTCP remote address updated through NAT address learning and port + 1 derivation executed; in MUX mode, this logic is skipped because RTCP already shares the RTP address. Simultaneously, in the channel file descriptor registration stage, MUX mode does not register independent RTCP file descriptors to avoid the event loop repeatedly listening to already reused ports.

[0052] Beneficial effects: WebRTC Full Interoperability: Enabling Dual-Port Runtime Seamless single-port switching, fully compliant with RFC 5761 RTCP-MUX protocol requirements, eliminating ICE negotiation failure issues with WebRTC clients.

[0053] Concurrency security assurance: Through a unified ownership tracking mechanism using pointer equivalence detection, three fatal concurrency defects—socket double closure, SSL object double release, and TURN resource hanging—are eliminated at the architectural level, ensuring system stability in high-concurrency scenarios.

[0054] Improved ICE negotiation efficiency: The single-component mode reduces the number of ICE candidate pairs by 50%, directly shortening the connectivity detection time window and accelerating WebRTC call establishment.

[0055] System resource saving: In MUX mode, each call saves the resource overhead of 1 UDP socket + 1 ICE component + 1 independent DTLS secure session, significantly freeing up system resources in scenarios with thousands of concurrent calls.

[0056] Based on the methods provided in the above embodiments, this invention also provides a port multiplexing session lifecycle management device, which is described below with reference to the accompanying drawings.

[0057] See Figure 2 The figure is a schematic diagram of the structure of a port multiplexing session lifecycle management device provided in an embodiment of the present invention.

[0058] The port multiplexing session lifecycle management device 200 provided in this embodiment of the invention includes: a state machine definition unit 201, an SDP decision unit 202, an ICE component adjustment unit 203, a socket management unit 204, a DTLS tracing unit 205, a TURN destruction unit 206, an ICE bypass unit 207, and an address synchronization unit 208.

[0059] State machine definition unit 201 is used to define the RTCP channel type enumeration state machine, which includes disabled state, standard independent port state and single port multiplexing state; SDP decision unit 202 is used to parse the RTCP multiplexing attribute in the remote media description at the SIP session description protocol processing layer, decide the RTCP channel type in combination with the local endpoint configuration, and inject the RTP instance through the attribute setting interface. The ICE component adjustment unit 203 is used to dynamically adjust the ICE component count according to the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, the number of ICE components is set to 1, and when it is determined to be a standard independent port state, the number of ICE components is set to 2. The socket management unit 204 is used to perform dual-mode socket management according to the RTCP channel type, create an independent UDP socket in the standard independent port mode, and point the RTCP socket to the RTP socket and perform double-close protection detection in the single-port multiplexing mode. DTLS tracing unit 205 is used to perform ownership tracing at the DTLS secure session layer, determine whether RTCP holds an independent SSL object by pointer equality comparison, and perform a release operation when it holds an independent SSL object; The TURN destruction unit 206 is used to trigger the TURN relay resource destruction process when the number of ICE components decreases from 2 to 1, and to execute deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms. ICE bypass unit 207 is used to execute single-component bypass logic based on ICE component count during ICE candidate verification. When the component count is 1, it tolerates the absence of RTCP candidates, creates an ICE checklist based on RTP candidates, and automatically filters remote candidates with component identifiers greater than 1. Address synchronization unit 208 is used to perform dual-mode synchronization based on the RTCP channel type in the remote address setting function. In the standard independent port mode, the RTCP port is derived from the RTP port, and in the single-port multiplexing mode, the RTCP directly shares the RTP address.

[0060] In one possible implementation, the ICE component adjustment unit 203 is specifically used for: Register a component count change interface in the ICE engine. The component count change interface is used to receive the target component count parameter. When an ICE session exists and the current number of components differs from the target number of components, atomically update the ICE component number field maintained in the RTP instance; Retain the current ICE role, destroy the original ICE session, and rebuild a new ICE session with the target number of components.

[0061] In one possible implementation, the socket management unit 204 is specifically used for: In the standard standalone port state path, create a standalone UDP socket and bind it to the RTP local port plus one, and register the RTCP component candidate address with the ICE framework; In a single-port multiplexed path, a double-close protection detection is performed, and the close operation is only performed when RTCP currently holds an independent socket and that socket is not equal to the RTP socket; Point the RTCP socket descriptor to the RTP socket descriptor to achieve port multiplexing.

[0062] In one possible implementation, the DTLS tracing unit 205 is specifically used for: In the DTLS session termination function, an equality comparison is performed between the SSL object pointer of RTCP and the SSL object pointer of RTP. When the two pointers are not equal, it is determined that RTCP holds an independent SSL object, and normal release is performed; When the two pointers are equal, it is determined that the RTCP shares the SSL object of RTP, and only the null pointer is set without calling the release function; Inject the same decision logic into the DTLS renegotiation path, and perform independent key renegotiation on RTCP only when the two pointers are not equal.

[0063] In one possible implementation, the TURN destruction unit 206 is specifically used for: The pre-test checks whether the number of ICE components is 1 and whether the RTCP TURN socket is not empty; Release the RTP instance-level exclusive lock to avoid cross-waiting with the underlying protocol stack group lock; Call the TURN socket asynchronous destruction interface to trigger the TURN state transition; After reacquiring the instance lock, the system blocks and waits for the TURN state to transition to the completion state through a condition variable timeout waiting mechanism.

[0064] In one possible implementation, the ICE bypass unit 207 is specifically used for: When the number of components is greater than 1, a warning is issued and the process terminates if there is a lack of RTCP candidates; When the number of components is 1, the absence of RTCP candidates is tolerated, and the creation of the ICE checklist is allowed based solely on RTP candidates. In single-port reuse mode, remote candidates with component identifiers greater than 1 are automatically skipped to avoid injecting invalid candidates into the ICE framework.

[0065] In one possible implementation, the address synchronization unit 208 is specifically used for: In standard independent port mode, the RTCP remote port is automatically set to the RTP remote port plus one, and the RTCP local port is synchronously set to the RTP local port plus one. In single-port multiplexing mode, the RTCP remote address is set to the same address and port as the RTP remote address, and the RTCP local address is set to the same address and port as the RTP local address. Type detection is injected into the NAT symmetric RTP learning path, and the RTCP remote address is updated and port increment derivation is performed only in the standard independent port state through NAT address learning. During the channel file descriptor registration process, independent RTCP file descriptors are not registered in single-port multiplexing mode.

[0066] Since the port multiplexing session lifecycle management device 200 is a device corresponding to the port multiplexing session lifecycle management method provided in the above method embodiments, the specific implementation of each unit of the port multiplexing session lifecycle management device 200 is based on the same concept as the above method embodiments. Therefore, for the specific implementation of each unit of the port multiplexing session lifecycle management device 200, please refer to the description of the port multiplexing session lifecycle management method in the above method embodiments, and it will not be repeated here.

[0067] This invention also provides a port multiplexing session lifecycle management device, the device including: a processor and a memory; Memory, used to store instructions; The processor is used to execute instructions in memory and perform the port multiplexing session lifecycle management method mentioned in the above embodiments.

[0068] It should be noted that the hardware structure of the port multiplexing session lifecycle management device provided in the embodiments of the present invention can be as follows: Figure 3 The structure shown, Figure 3This is a schematic diagram of the structure of a device provided in an embodiment of the present invention.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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 from the memory 330 to implement the port multiplexing session lifecycle management method provided in this embodiment of the invention.

[0073] 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 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0074] This invention also provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the port multiplexing session lifecycle management method mentioned in the above embodiments.

[0075] This invention also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute the port multiplexing session lifecycle management method mentioned in the above embodiments.

[0076] 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 managing the lifecycle of a port multiplexing session, characterized in that, include: Define an RTCP channel type enumeration state machine, which includes a disabled state, a standard independent port state, and a single-port multiplexing state; The RTCP multiplexing attribute in the remote media description is parsed at the SIP session description protocol processing layer. The RTCP channel type is determined in combination with the local endpoint configuration, and an RTP instance is injected through the attribute setting interface. The ICE component count is dynamically adjusted based on the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, the number of ICE components is set to 1, and when it is determined to be a standard independent port state, the number of ICE components is set to 2. Socket dual-mode management is performed according to the RTCP channel type. An independent UDP socket is created in the standard independent port state, and the RTCP socket is pointed to the RTP socket and a double-close protection detection is performed in the single-port multiplexing state. Ownership tracking is performed at the DTLS secure session layer. Pointer equality comparison is used to determine whether RTCP holds an independent SSL object. If it holds an independent SSL object, a release operation is performed. When the number of ICE components decreases from 2 to 1, the TURN relay resource destruction process is triggered, and deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms are executed. During the ICE candidate verification process, single-component bypass logic is executed based on the ICE component count. When the component count is 1, the absence of RTCP candidates is tolerated. An ICE checklist is created based on the RTP candidates, and remote candidates with component identifiers greater than 1 are automatically filtered. In the remote address setting function, dual-mode synchronization is performed according to the RTCP channel type. In the standard independent port mode, the RTCP port is derived from the RTP port, and in the single-port multiplexing mode, RTCP directly shares the RTP address.

2. The method according to claim 1, characterized in that, The dynamic adjustment of the ICE component count based on the RTCP channel type obtained from the decision includes: Register a component count change interface in the ICE engine; the component count change interface is used to receive the target component count parameter. When an ICE session exists and the current number of components is different from the target number of components, atomically update the ICE component number field maintained in the RTP instance; Retain the current ICE role, destroy the original ICE session, and rebuild a new ICE session with the target number of components.

3. The method according to claim 1, characterized in that, The step of performing socket dual-mode management according to the RTCP channel type includes: In the standard standalone port state path, create a standalone UDP socket and bind it to the RTP local port plus one, and register the RTCP component candidate address with the ICE framework; In a single-port multiplexed path, a double-close protection detection is performed, and the close operation is only performed when RTCP currently holds an independent socket and that socket is not equal to the RTP socket; Point the RTCP socket descriptor to the RTP socket descriptor to achieve port multiplexing.

4. The method according to claim 1, characterized in that, The step of performing ownership tracking at the DTLS secure session layer, and determining whether RTCP holds an independent SSL object through pointer equivalence comparison, includes: In the DTLS session termination function, an equality comparison is performed between the SSL object pointer of RTCP and the SSL object pointer of RTP. When the two pointers are not equal, it is determined that RTCP holds an independent SSL object, and normal release is performed; When the two pointers are equal, it is determined that the RTCP shares the SSL object of RTP, and only the null pointer is set without calling the release function; Inject the same decision logic into the DTLS renegotiation path, and perform independent key renegotiation on RTCP only when the two pointers are not equal.

5. The method according to claim 1, characterized in that, The process of triggering the TURN relay resource destruction when the number of ICE components decreases from 2 to 1 includes: The pre-test checks whether the number of ICE components is 1 and whether the RTCP TURN socket is not empty; Release the RTP instance-level exclusive lock to avoid cross-waiting with the underlying protocol stack group lock; Call the TURN socket asynchronous destruction interface to trigger the TURN state transition; After reacquiring the instance lock, the system blocks and waits for the TURN state to transition to the completion state through a condition variable timeout waiting mechanism.

6. The method according to claim 1, characterized in that, The execution of single-component bypass logic during ICE candidate verification includes: In the ICE remote candidate startup function, adaptive logic is implemented based on the digital segment of the ICE component. When the number of components is greater than 1, a warning is issued and the process terminates if there is a lack of RTCP candidates; When the number of components is 1, the absence of RTCP candidates is tolerated, and the creation of the ICE checklist is allowed based solely on RTP candidates. In single-port reuse mode, remote candidates with component identifiers greater than 1 are automatically skipped to avoid injecting invalid candidates into the ICE framework.

7. The method according to claim 1, characterized in that, The step of performing dual-mode synchronization based on the RTCP channel type in the remote address setting function includes: In standard independent port mode, the RTCP remote port is automatically set to the RTP remote port plus one, and the RTCP local port is synchronously set to the RTP local port plus one. In single-port multiplexing mode, the RTCP remote address is set to the same address and port as the RTP remote address, and the RTCP local address is set to the same address and port as the RTP local address. Type detection is injected into the NAT symmetric RTP learning path, and the RTCP remote address is updated and port increment derivation is performed only in the standard independent port state through NAT address learning. During the channel file descriptor registration process, independent RTCP file descriptors are not registered in single-port multiplexing mode.

8. A port multiplexing session lifecycle management device, characterized in that, The device includes: The state machine definition unit is used to define the RTCP channel type enumeration state machine, which includes a disabled state, a standard independent port state, and a single-port multiplexing state. The SDP decision unit is used to parse the RTCP multiplexing attribute in the remote media description at the SIP session description protocol processing layer, combine the local endpoint configuration to determine the RTCP channel type, and inject the RTP instance through the attribute setting interface. The ICE component adjustment unit is used to dynamically adjust the ICE component count based on the RTCP channel type obtained from the decision. When it is determined to be a single-port multiplexing state, the number of ICE components is set to 1; when it is determined to be a standard independent port state, the number of ICE components is set to 2. The socket management unit is used to perform dual-mode socket management according to the RTCP channel type. In the standard independent port mode, it creates an independent UDP socket, and in the single-port multiplexing mode, it points the RTCP socket to the RTP socket and performs double-close protection detection. The DTLS tracing unit is used to perform ownership tracing at the DTLS secure session layer. It determines whether RTCP holds an independent SSL object by comparing pointers, and performs a release operation if it holds an independent SSL object. The TURN destruction unit is used to trigger the TURN relay resource destruction process when the number of ICE components decreases from 2 to 1, and to perform deadlock avoidance, asynchronous destruction interface calls and timeout waiting mechanisms. The ICE bypass unit is used to execute single-component bypass logic based on the ICE component count during the ICE candidate verification process. When the component count is 1, it tolerates the absence of RTCP candidates, creates an ICE checklist based on RTP candidates, and automatically filters remote candidates with component identifiers greater than 1. The address synchronization unit is used to perform dual-mode synchronization based on the RTCP channel type in the remote address setting function. In the standard independent port mode, the RTCP port is derived from the RTP port, and in the single-port multiplexing mode, the RTCP directly shares the RTP address.

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.

Images