A method and system for adaptive endpoint recognition of sip inbound requests

Abstract

The application discloses a SIP inbound request adaptive endpoint identification method and system, and belongs to the technical field of VoIP communication. The method comprises the following steps: constructing a double-track ACL structure containing a main matching ACL and a pre-matching ACL for each relay endpoint; selecting an activated cascaded matching strategy set from a cloud end or a SBC strategy set or a local strategy set according to a deployment mode identifier, performing matching step by step according to priority, performing matching operation based on an inbound request feature and an endpoint identification object field and a corresponding ACL, and terminating and returning a result as soon as the first successful matching is achieved. Meanwhile, DNS adaptive resolution is realized through cooperation of an initial analysis thread, a periodic refreshing thread and a timer daemon thread, and domain name entries in the ACL are dynamically maintained and atomically updated. Through multi-dimensional cascaded matching and dynamic DNS resolution, the application eliminates endpoint identification ambiguity under complex deployment, ensures real-time synchronization of matching rules, and significantly improves the accuracy and stability of an IPBX system inbound route.

Description

Technical Field

[0001] This invention relates to the field of Voice over Internet Protocol (VoIP) communication technology, specifically to an adaptive endpoint identification method and system for SIP inbound requests. Background Technology

[0002] In modern enterprise unified communications and cloud communications platforms, a single IP PBX (Internet Protocol Private Branch Exchange) typically needs to simultaneously connect to dozens of Session Initiation Protocol (SIP) trunk lines from different Internet Telephony Service Providers (ITSPs) to enable external call access and outgoing calls. The deployment of these trunk lines is diverse and complex. For example, multiple ITSPs may share the same data center, leading to overlapping source IP address ranges; proxy forwarding via a Session Border Controller (SBC) may uniformly replace the source IP address of all inbound requests with the proxy address; or load balancing via the Domain Name System (DNS) may cause dynamic rotation of the underlying IP address pool. These complex network topologies pose a significant challenge to the identification of SIP inbound request endpoints in the IPPBX system.

[0003] Traditional SIP engines have the following main problems when identifying inbound request endpoints: 1. Limited endpoint identification dimensions lead to routing ambiguity in multi-relay co-location scenarios. Traditional solutions typically perform single-dimensional matching based solely on the source IP address of inbound requests. When traffic from multiple different trunk lines originates from the same ITSP or shares the same IP address range, the system cannot distinguish which specific trunk endpoint configuration the request should belong to based on a single source IP address, resulting in calls being incorrectly routed or dropped out.

[0004] Second, the domain name resolution uses a one-time static loading method, and the matching rules become invalid immediately after a DNS change. Many traditional solutions resolve the domain names in the relay configuration to IP addresses once during system initialization and store them permanently in the matching list. Once the ITSP changes its DNS records due to reasons such as load balancing, disaster recovery switching, or content delivery network (CDN) adjustments, the fixed matching rules will not be able to cover the new IP addresses, causing subsequent legitimate inbound requests to be interrupted due to lack of matching.

[0005] Third, endpoint identification capability is completely lost in SBC proxy penetration scenarios. In cloud-based or enterprise-based SBC deployments, after all external SIP requests are processed by the SBC, their transport layer source IP addresses are uniformly replaced with the SBC's address. The traditional one-dimensional matching mechanism that relies entirely on the transport layer source IP completely fails in this scenario, making it impossible to distinguish between different relay providers that actually initiate the requests behind the SBC.

[0006] Fourth, the unified matching logic used in cloud and on-premises deployments results in insufficient adaptability and accuracy. The inbound request characteristics of cloud deployments (emphasizing SBC port routing and DID number routing) and on-premises deployments (emphasizing direct IP matching and multi-WAN port binding) differ significantly. Traditional engines employ a single, fixed matching strategy, which cannot be optimized for different deployment modes and struggles to simultaneously achieve optimal matching accuracy in both scenarios.

[0007] In summary, there is an urgent need for a SIP inbound request endpoint identification scheme that can adapt to complex deployment environments and has high matching accuracy and high reliability. Summary of the Invention

[0008] This invention aims to overcome the problems of routing ambiguity, identification failure, and poor adaptability in the prior art, and provides a method and system for adaptive endpoint identification of SIP inbound requests based on multi-policy cascading matching and dynamic DNS resolution.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides an adaptive endpoint identification method for SIP inbound requests, comprising the following steps: Step 1: Build an endpoint identification object for each trunk endpoint configured in the IP PBX system. The endpoint identification object contains multiple matching fields related to endpoint identification, and create a dual-track ACL structure for each endpoint identification object, which contains at least one main matching access control list (ACL) and one pre-matching ACL. Step 2: In response to receiving a SIP inbound request, obtain the IPPBX system's preset deployment mode identifier. The deployment mode identifier is used to characterize whether the system is currently deployed in the cloud, in a Session Border Controller (SBC) deployment scenario, or in a local direct connection deployment scenario. Step 3: Based on the deployment mode identifier, select one set from the pre-configured set of multiple cascading matching strategies as the currently active cascading matching strategy set; wherein, the multiple cascading matching strategy sets include at least a first strategy set applicable to cloud or SBC deployment scenarios and a second strategy set applicable to local direct connection deployment scenarios; Step 4: Execute each level of matching strategy in descending order of priority according to the preset priority in the activated cascading matching strategy set. Each level of matching strategy is based on at least one feature information extracted from the SIP inbound request and performs matching calculations with the corresponding matching fields of each endpoint identification object and the corresponding main matching ACL or pre-matching ACL. Step 5: When a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, the subsequent cascading matching process is terminated, and the matched endpoint identification object is returned to complete the endpoint identification of the inbound request.

[0010] Furthermore, the first policy set (applicable to cloud or SBC deployment scenarios) includes six policy levels in descending order of priority, as follows: Level 1 strategy: Extract the SBC port number of the SIP inbound request, match it with the port field of the endpoint identification object, and verify that the source IP address of the request matches the pre-matched ACL; Second-level strategy: Extract the called number and real source address of the SIP inbound request, verify that the called number matches the DID number list of the endpoint identification object, and that the real source address matches the pre-matched ACL; Level 3 strategy: When the Level 2 strategy fails, perform DID suffix fuzzy matching, comparing the last character of the called number's suffix with the entries in the DID (Direct Inward Dialing) number list; Level 4 strategy: Only verify that the source IP address of the request matches the pre-matched ACL; Level 5 strategy: Extract the Contact header address and port of the SIP inbound request, and verify that the Contact header address matches the main matching ACL and that the Contact header port matches the port field of the object; Level 6 Strategy: Verify that the transport protocol type of the SIP inbound request matches the transport protocol type field of the endpoint identification object, and verify that the source IP address of the request matches the primary matching ACL.

[0011] Furthermore, the second policy set (applicable to local direct-connection deployment scenarios) includes five policy levels in descending order of priority, as follows: Level 1 strategy: Extract the username and source IP address of the SIP inbound request, verify that the username matches the username field of the endpoint identification object, the source IP address matches the main matching ACL, and verify that the called number matches the DID number list when the DID number list is not empty. Second-level strategy: Extract the local interface IP address of the SIP inbound request, verify that the local interface IP address matches the interface IP binding field of the endpoint identification object, the source IP address matches the main matching ACL, and the Contact port matches the port field of the object; Level 3 strategy: Verify that the source IP address matches the main matching ACL and that the Contact port matches the port field of the object; Level 4 strategy: Only verify if the source IP address matches the primary ACL; Level 5 strategy: Extract the complete URI address from the Contact header field of the SIP inbound request and verify that the URI address matches the main matching ACL.

[0012] Furthermore, the method also includes a DNS adaptive resolution step, including: Start the initial resolution consumer thread, which is used to retrieve domain name entries from the initial resolution task queue, perform DNS resolution, and update the resolved IP address to the main matching ACL or pre-matching ACL of the corresponding endpoint identification object; Start a periodic refresh thread, which, after being woken up by a condition variable, iterates through the domain name entries in the periodic refresh task queue, re-executes DNS resolution, and atomically updates the corresponding primary matching ACL. Start a configurable timer daemon thread, which is used to wake up the periodic refresh thread at a preset period using a condition variable.

[0013] Furthermore, the DNS resolution process also includes a protocol-aware multi-address resolution process: Based on the transport protocol type field configured in the endpoint identification object, construct the corresponding DNS SRV (ServiceRecord) record query name; If the transport protocol type is DNS NAPTR (Naming Authority Pointer), then the SRV record queries for UDP (User Datagram Protocol), TCP (Transmission Control Protocol), and TLS (Transport Layer Security) will be attempted in the order of preset priority. The SRV record is parsed to obtain one or more target domain names and ports. Then, the A or AAAA record is queried on the target domain name to obtain one or more IP addresses. Update one or more IP addresses to the corresponding primary match ACL or pre-match ACL using atomic operations.

[0014] Furthermore, before atomically updating the corresponding ACL, the periodic refresh thread first saves the pointer of the current ACL to the corresponding historical version ACL field; if the DNS re-resolution fails this time, the update operation is not performed, and the pointer in the historical version ACL field is retained to ensure that the matching rules remain valid.

[0015] Furthermore, the method also includes a dynamic update step for matching rules to ensure hot reload safety, including: When a system configuration change triggers a module reload, the current primary matching ACL pointer and pre-matching ACL pointer of each endpoint identification object are saved to the corresponding historical version ACL field. Submit the new matching field entries to the initial parsing task queue, and perform deduplication verification on the initial parsing task queue and the periodic refresh task queue before submission; After the task is submitted, a condition variable signal is sent to wake up the initial parsing consumer thread, ensuring that the new configuration takes effect in a timely manner.

[0016] In a second aspect, the present invention provides an adaptive endpoint identification system for SIP inbound requests, used to implement the method described above, the system comprising: The object configuration module is configured to build an endpoint identification object containing multiple fields for each relay endpoint and create a corresponding dual-track ACL structure consisting of a main matching ACL and a pre-matching ACL. The pattern recognition module is configured to obtain the system's preset deployment mode identifier in response to a SIP inbound request; The strategy selection module is configured to select one set of cascading matching strategies as the active cascading matching strategy set from multiple sets of cascading matching strategies based on the deployment mode identifier; The policy execution engine is configured to execute each level of matching policy in descending order of priority from the pre-set priority in the set of activated cascading matching policies. Each level of matching policy is based on at least one feature information extracted from the SIP inbound request and performs matching operations with the corresponding matching field of each endpoint identification object and the corresponding main matching ACL or pre-matching ACL. The result determination module is configured to terminate the subsequent cascading matching process and return the matched endpoint identification object when a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, so as to complete the endpoint identification of the inbound request.

[0017] In another aspect, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement an adaptive endpoint identification method for any of the SIP inbound requests described above.

[0018] In another aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements an adaptive endpoint identification method for any of the SIP inbound requests described above.

[0019] Compared with the prior art, the present invention has the following significant beneficial technical effects: 1. Eliminate endpoint identification ambiguity in complex deployments: Through deployment mode-aware multi-strategy cascading matching, it integrates multi-dimensional information such as SBC port, DID number (including fuzzy matching of suffixes), trunk username, local interface binding, and transmission protocol type. This enables the system to accurately and uniquely identify the target trunk endpoint in complex scenarios such as cloud SBC proxy, multiple trunk co-location, or local multi-WAN access, greatly reducing the probability of routing errors and call loss.

[0020] 2. Resolving communication interruptions caused by domain name changes: A dynamic DNS resolution architecture with three threads working together enables continuous and automatic updates of matching rules. The system can automatically detect changes in ITSP's DNS records and update the ACL in an atomic manner. At the same time, a historical version ACL retention mechanism provides rollback capability in case of update failure, ensuring a smooth transition and zero interruption of communication services during DNS changes.

[0021] 3. Effectively penetrate SBC proxies for endpoint identification: Through an innovative dual-track ACL model, the SBC proxy address (pre-match ACL) is managed separately from the actual address range of the relay provider (primary match ACL). Combined with custom SIP header field resolution technology, the system can accurately distinguish inbound requests from different backend ITSPs under the unified source IP representation of the SBC proxy, solving the identification blind spot of traditional solutions in this scenario.

[0022] 4. Improve routing compatibility in international relay scenarios: By introducing a fuzzy matching mechanism for the suffix of DID numbers, the system can automatically ignore the prefix information such as country codes or international area codes added by ITSPs before the incoming call number, accurately match the local DID number configuration, and significantly improve the routing success rate and compatibility in cross-international operator communication scenarios.

[0023] 5. Ensure service continuity during configuration changes: Through a dynamic update mechanism for matching rules with hot reload security, when the system configuration changes, the current rules are saved first, and then deduplication verification and new rule loading are performed. This ensures that the endpoint identification service for inbound requests is not interrupted throughout the entire reload process, improving the system's operational reliability and availability. Attached Figure Description

[0024] Figure 1 A flowchart illustrating an adaptive endpoint identification method for SIP inbound requests provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of an adaptive endpoint identification system for SIP inbound requests provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0026] With the deep integration of enterprise unified communications and cloud communication technologies, IP PBXs, as core voice switching platforms, are playing an increasingly crucial role in organizations of all sizes. A modern IPPBX system often needs to simultaneously connect to dozens of SIP trunk lines from different Internet Telephone Service Providers (ITSPs) to achieve interconnection with the Public Switched Telephone Network (PSTN) and mobile communication networks. This multi-trunk aggregation architecture allows enterprises to flexibly choose operators, optimize communication costs, and ensure communication reliability through redundant lines.

[0027] However, in complex real-world deployment environments, accurately identifying the trunk endpoint to which each SIP inbound request belongs and correctly routing it to the corresponding call processing link has become a prominent technical challenge for the core routing engine of an IPPBX. On one hand, traditional SIP endpoint identification mechanisms generally employ a single-dimensional matching strategy based on the source IP address, designed for simple, one-to-one network environments. When faced with complex scenarios such as multiple ITSPs sharing the same IP address range, source addresses being uniformly replaced due to forwarding via Session Border Controller (SBC), or ITSPs using domain name load balancing causing dynamic rotation of the IP address pool, this mechanism exposes inherent flaws such as a single matching dimension, severe routing ambiguity, and insufficient adaptability. On the other hand, some systems attempt to introduce static DNS resolution to support domain name access, but the resolution operation is typically performed only once during system initialization. If subsequent ITSP changes its DNS records due to load balancing, disaster recovery switching, or content delivery network (CDN) adjustments, the fixed IP address list becomes out of touch with the actual situation, causing legitimate inbound requests to be rejected due to matching failures, resulting in communication interruptions.

[0028] Existing research and practices mainly focus on the routing and load balancing of SIP signaling, such as allocating requests among multiple SIP servers through round-robin mechanisms or selecting call routes based on the resource usage of trunk equipment. While these solutions improve system capacity and resource utilization to some extent, their core focus is on load distribution for outbound calls, rather than endpoint identification for inbound requests. Furthermore, some work has introduced P2P network concepts into SIP media transmission to reduce the burden on centralized servers; however, its distributed architecture weakens the controllability and manageability of the communication system, making it difficult to directly apply to enterprise-level IPPBX core routing scenarios where high accuracy in endpoint identification and operational certainty are required.

[0029] In summary, there is an urgent need to propose a SIP inbound request endpoint identification scheme that can adaptively perceive deployment modes, integrate multi-dimensional matching factors, and has dynamic DNS tracking capabilities. This scheme can eliminate routing ambiguity under complex topologies while ensuring that matching rules are synchronized with the network environment in real time, thereby comprehensively improving the inbound routing accuracy, operation and maintenance convenience, and service continuity of the IPPBX system.

[0030] The following is combined with Figure 1 The flowchart below provides a detailed explanation of the method of the present invention.

[0031] A first aspect of the present invention provides an adaptive endpoint identification method for SIP inbound requests, comprising the following steps: S1. Construct an endpoint identification object for each trunk endpoint configured in the IP PBX system. The endpoint identification object contains multiple matching fields related to endpoint identification. Create a dual-track ACL structure for each endpoint identification object, which contains at least one primary matching access control list (ACL) and one pre-matching ACL. S2. In response to receiving a SIP inbound request, obtain the preset deployment mode identifier of the IPPBX system. The deployment mode identifier is used to characterize whether the system is currently in a cloud deployment scenario, a session border controller (SBC) deployment scenario, or a local direct connection deployment scenario. S3. Based on the deployment mode identifier, select one set from the pre-configured set of multiple cascading matching strategies as the currently active cascading matching strategy set; wherein, the multiple cascading matching strategy sets include at least a first strategy set applicable to cloud or SBC deployment scenarios and a second strategy set applicable to local direct connection deployment scenarios; S4. Execute each level of matching strategy in descending order of priority from the preset priority in the activated cascading matching strategy set. Each level of matching strategy is based on at least one feature information extracted from the SIP inbound request and performs matching operations with the corresponding matching field of each endpoint identification object and the corresponding main matching ACL or pre-matching ACL. S5. When a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, the subsequent cascading matching process is terminated, and the matched endpoint identification object is returned to complete the endpoint identification of the inbound request.

[0032] This embodiment covers the complete closed-loop process of SIP inbound request endpoint identification. For example, in one implementation, the IPPBX system loads the configuration information of all trunk endpoints through a configuration persistence framework at startup, instantiating an endpoint identification object for each trunk endpoint. This object contains more than twelve configuration fields, including endpoint_name, username, matchstr, port, tsptype, didsetting, prematch, sbcport, peertype, interfaceip_bind, and srvlookup.

[0033] In this invention, the Access Control List (ACL) is a set of rule data structure used to store and match IP address information. Each ACL consists of one or more rule nodes, and each rule node contains at least one address matching pattern and one action identifier. The address matching pattern supports a single IP address (e.g., "192.168.1.100"), IP address ranges in Classless Inter-Domain Routing (CIDR) format (e.g., "10.0.0.0 / 24"), and a list of IP addresses obtained after domain name resolution. The action identifier includes two basic types: "permit" and "deny".

[0034] In a preferred embodiment of the present invention, both the primary matching ACL and the pre-matching ACL employ a "deny semantic inversion" matching mode. Specifically, the system adds the IP addresses or address ranges to be matched as "deny" rules to the ACL. Simultaneously, the ACL is configured with an implicit default rule that returns "permit" for all addresses not matched by the deny rule. When matching the source IP address of an inbound request, the system calls the ACL's matching operation function to compare the source IP address sequentially with each rule node in the ACL. If the source IP address matches (i.e., conforms to) any of the deny rules' address matching patterns, the matching operation function returns a "hit" result, indicating a successful match; if the source IP address does not match any deny rule, it returns a "miss" result due to the implicit default rule. This inverted semantic design makes ACL management more intuitive—only "legal" address ranges need to be considered and added, without explicitly configuring complex combinations of "allow" and "deny" lists, thus simplifying the complexity of relay endpoint configuration.

[0035] A dual-track ACL structure refers to each endpoint identification object simultaneously holding two functionally independent ACL linked lists: a main matching ACL and a pre-matching ACL. The main matching ACL stores IP address ranges representing the actual communication addresses of ITSP relay providers, parsed from the original match field (matchstr) of the relay configuration. It is primarily used for matching strategies in local direct-connection deployment scenarios. The pre-matching ACL stores IP address ranges representing the actual source addresses of relays in SBC proxy scenarios, parsed from the pre-match field (prematch) of the relay configuration. It is specifically used for matching strategies of inbound requests forwarded via SBC proxies. By storing address information from two different sources in two independent ACLs, the system can accurately select the corresponding ACL for matching operations in different deployment scenarios and matching strategies. This structurally decouples the association between the transport layer source IP and the actual relay provider address, providing a data structure foundation for endpoint identification through SBC proxies.

[0036] In a specific implementation of this invention, the ACL is organized using a singly linked list data structure, with each list node corresponding to one rule. The matching operation employs a sequential traversal, comparing each rule sequentially from the head node until a rule is matched or the end of the list is reached. Those skilled in the art will understand that in other embodiments, the ACL can also be implemented using arrays, hash tables, balanced binary trees, or other data structures suitable for fast lookups; these alternative implementations should all fall within the protection scope of this invention.

[0037] The above method initializes two independent ACL linked lists for this object: the main matching ACL stores the ITSP direct IP address range obtained from matchstr resolution, and the pre-matching ACL stores the real source address range for SBC proxy scenarios obtained from prematch resolution. Both ACLs adopt the "deny semantic inversion" matching mode, that is, the address to be matched is appended with a deny rule, combined with the implicit permit-all default rule, and the ACL matching operation function determines whether the source address of the inbound request is matched. When inbound requests of non-registered types such as SIPINVITE, OPTIONS, and MESSAGE arrive at the core routing engine, the system first reads the global deployment mode identifier, which can be preset through configuration files, environment variables, or database parameters. According to the identifier value, the system selects the first policy set (cloud / SBC deployment) or the second policy set (local direct connection deployment) from the preset policy library as the currently active policy set. The cascading matching engine then calls the processing function corresponding to each matching policy level in the priority order defined in the policy set. Each policy level extracts specific characteristic information (such as source IP, SBC port, DID number, username, transport protocol type, local interface IP, etc.) from the inbound request and performs matching calculations against the corresponding fields and associated ACLs of all endpoint identification objects. Once a policy level successfully matches a unique endpoint identification object, the engine immediately short-circuits and terminates subsequent cascading, returning the endpoint_name of that object. The system then routes the request to the corresponding relay processing link based on this name. If no match is found across all policies, a matching failure is returned, and the request is either rejected or enters the default processing flow.

[0038] In the above embodiments, the matching fields of the endpoint identification object may include, but are not limited to: endpoint name (endpoint_name), relay username (username), original matching string (matchstr), contact port number (port), transport protocol type (tsptype, supporting four enumerations: UDP, TCP, TLS, and DNSNAPTR), DID number list (didsetting, comma-separated multi-DID configuration), pre-matching address (prematch), SBC port number (sbcport), peer type (peertype, supporting did_based and port_based enumerations), interface IP binding address (interfaceip_bind), and DNS SRV lookup enable flag (srvlookup). The dual-track ACL structure design decouples the real address information of the relay provider from the SBC proxy address information, enabling the system to accurately distinguish different relay sources through pre-matching ACLs when facing scenarios where the same SBC proxies multiple backend ITSPs. The "deny semantic inversion" matching mode of ACL is an efficient implementation: allowed address ranges are added as deny rules, and the internal logic of the matching function is "a successful match is returned if the deny rule is hit". This method simplifies the rule management logic and avoids the complexity of explicitly maintaining the list of allow rules.

[0039] The method described above integrates endpoint object modeling, deployment scenario awareness, multi-level policy matching, and result return into a self-consistent closed loop. Its key difference from traditional single-dimensional IP matching or fixed-policy methods lies in the introduction of a deployment mode identifier-driven policy set switching mechanism and a multi-factor cascaded short-circuit matching architecture. This mechanism allows the endpoint identification process to no longer rely on single-dimensional information, but instead prioritizes high-precision, highly discriminative matching factors, placing them at the forefront and low-precision, fallback matching factors at the latter. Thus, the system can automatically adapt to the optimal matching path under different deployment topologies—cloud scenarios prioritize the high discriminative characteristics of SBC ports and DID numbers, while local scenarios prioritize the accuracy of usernames and interface bindings—this adaptive capability is built into the engine framework, ensuring that the target endpoint can be located with the highest possible accuracy in any complex environment.

[0040] In some embodiments, the first policy set (applicable to cloud or SBC deployment scenarios) includes the following six levels of policies in descending order of priority: Level 1 strategy: Extract the SBC port number of the SIP inbound request, match it with the port field of the endpoint identification object, and verify that the source IP address of the request matches the pre-matched ACL; Second-level strategy: Extract the called number and real source address of the SIP inbound request, verify that the called number matches the DID number list of the endpoint identification object, and that the real source address matches the pre-matched ACL; Third-level strategy: When the second-level strategy fails, perform DID suffix fuzzy matching, and compare the last character of the suffix of the called number with the entries in the DID number list; Level 4 strategy: Only verify that the source IP address of the request matches the pre-matched ACL; Level 5 strategy: Extract the Contact header address and port of the SIP inbound request, and verify that the Contact header address matches the main matching ACL and that the Contact header port matches the port field of the object; Level 6 Strategy: Verify that the transport protocol type of the SIP inbound request matches the transport protocol type field of the endpoint identification object, and verify that the source IP address of the request matches the primary matching ACL.

[0041] This embodiment specifically defines the six-level cascading structure of the first policy set and its priority order. In one implementation, the system receives an INVITE request forwarded by an SBC proxy. The first-level policy extracts the transport layer destination port (i.e., the SBC forwarding port, such as 5080), traverses all endpoint identification objects, and searches for objects whose sbcport field equals "5080" and whose pre-matched ACL matches. If a unique match exists, it returns immediately; if no match is found or multiple candidates exist, it proceeds to the second level. The second-level policy extracts the called number (such as "2012345678") from the Request-URI, extracts the real source address from the custom SIP header field added by the SBC (such as SourceAddr or X-Forwarded-For), and verifies both DID matching and pre-matched ACL matching. If no match is found, the third-level policy initiates suffix fuzzy matching: for each DID entry in didsetting (such as "12345678"), its length N=8 is taken, and the last 8 digits of the called number are truncated for comparison. The fourth-level strategy, as a fallback, relies solely on the pre-matched ACL for single-dimensional judgment. The fifth-level strategy extracts the address and port from the Contact header field and verifies it together with the main matching ACL and the port field. The sixth-level strategy checks the consistency between the transport protocol type (TCP / TLS) and the tsptype field, and verifies that the source IP matches the main matching ACL.

[0042] In the above embodiment, the algorithm for fuzzy matching of DID suffixes is as follows: Let the incoming called number be D_in, and the didsetting list of the endpoint identification object contain an entry D_cfg. For each D_cfg, calculate its string length N = len(D_cfg). Extract the last N characters of D_in, denoted as D_suffix = substring(D_in, -N). If D_suffix is ​​exactly equal to D_cfg, the suffix is ​​considered to be matched successfully. For example, D_in = "+862012345678", D_cfg = "2012345678", N = 10, D_suffix = "2012345678", which is a successful match. This mechanism effectively solves the compatibility problem caused by international operators dynamically adding country codes (such as +86, 0086) or area code prefixes before the incoming call number, leading to failure in accurate matching.

[0043] In the above embodiments, the priority ranking of the six-level strategy follows the principle of "decreasing distinguishability and decreasing computational complexity". The first-level SBC port matching has the highest distinguishability - forwarding different relays with different ports of the same SBC is the standard practice in cloud deployment, and the comparison of port numbers is an O(1) operation. The second-level DID and real source address joint matching binds the highly distinguishable DID number with the source address, which is suitable for peer-to-peer relay (peertype=did_based) scenarios. The third-level suffix fuzzy matching serves as a supplement to the second level, sacrificing a small amount of accuracy in exchange for robustness to number prefix variants. The fourth to sixth levels are gradually downgraded to single-dimensional or transport layer matching as a fallback strategy to ensure that there is still a matching opportunity in extreme cases. This layered design enables the system to quickly locate the problem using a high-precision strategy when the information is complete, and automatically downgrades to a fallback when the information is missing, thus balancing matching accuracy and system robustness.

[0044] In some embodiments, the second policy set (applicable to local direct connection deployment scenarios) includes the following five levels of policies in descending order of priority: Level 1 strategy: Extract the username and source IP address of the SIP inbound request, verify that the username matches the username field of the endpoint identification object, that the source IP address matches the main matching ACL, and verify that the called number matches the DID number list when the DID number list is not empty; Second-level strategy: Extract the local interface IP address where the SIP inbound request arrives, verify that the local interface IP address matches the interface IP binding field of the endpoint identification object, the source IP address hits the main matching ACL, and the Contact port matches the port field of the object; Level 3 strategy: Verify that the source IP address matches the main matching ACL, and that the Contact port matches the port field of the object; Level 4 strategy: Only verify that the source IP address matches the primary matching ACL; Fifth-level strategy: Extract the complete URI (Uniform Resource Identifier) ​​address from the Contact header field of the SIP inbound request, and verify that the URI address matches the main matching ACL.

[0045] This embodiment specifically defines the five-level cascading structure of the second policy set and its priority order. In one implementation, the system is deployed locally within an enterprise and directly connected to different ITSPs via multiple WAN interfaces. The first-level policy extracts the username portion from the From header field of the inbound request, performs a case-insensitive comparison with the username field, and verifies that the source IP matches the primary matching ACL; if didsetting is not empty, an additional DID number comparison is performed to improve accuracy. The second-level policy targets IP Multimedia Subsystem (IMS) trunk scenarios deployed over multiple WANs: it extracts the local interface IP where the request arrives, compares it with the interfaceip_bind field, and verifies that the source IP matches the primary matching ACL and the Contact port. The third-level policy downgrades to a combined matching of the source IP and the Contact port, suitable for scenarios where the same IP is used to distinguish multiple trunks via different ports. The fourth-level policy relies solely on the primary matching ACL for single-dimensional matching of the source IP, serving as a primary fallback. The fifth-level policy extracts the complete URI address from the Contact header field for ACL matching, handling edge scenarios where the Contact address does not match the transport layer source address.

[0046] In the above embodiments, username verification in the first-level strategy takes precedence over other strategies because the username is the most distinctive identifier in the registration relay scenario—ITSPs typically assign unique usernames during user registration, making impersonation difficult. The interface IP binding in the second-level strategy resolves routing ambiguity issues when the same ITSP accesses from different interfaces in a multi-WAN environment. For example, if an ITSP provides two relay lines, accessing WAN1 (IP 192.168.1.100) and WAN2 (IP 192.168.2.100) respectively, the interfaceip_bind field is used to differentiate them, ensuring that inbound requests are routed to the correct relay configuration. The third to fifth levels progressively reduce dimensionality, providing a backup matching capability when information is incomplete.

[0047] In the above embodiments, the parallel design of the two policy sets reflects a deep understanding of the differences in characteristics across different deployment scenarios. The core characteristic of the cloud / SBC scenario is the distortion of source IP information (replaced by the SBC). Therefore, the first policy set highly relies on proxy layer information such as the SBC port, the real source address in the custom header field, and the DID number. The core characteristic of the local direct connection scenario is the authenticity and reliability of the source IP information. Therefore, the second policy set prioritizes features strongly associated with physical access, such as usernames and interface bindings. The two policy sets are maintained independently and activated on demand, avoiding the dilemma of a single policy failing to address all aspects of different scenarios in traditional solutions.

[0048] In some embodiments, the method further includes a DNS adaptive resolution step: The initial resolution consumer thread is started to retrieve domain name entries from the initial resolution task queue, perform DNS resolution, and update the resolved IP address to the main matching ACL or the pre-matching ACL of the corresponding endpoint identification object; Start a periodic refresh thread, which, after being woken up by a condition variable, iterates through the domain name entries in the periodic refresh task queue, re-executes DNS resolution, and atomically updates the corresponding primary matching ACL. Start a configurable timer daemon thread to wake up the periodic refresh thread at a preset period using the condition variable.

[0049] This embodiment covers a three-threaded collaborative architecture for adaptive DNS resolution. In one implementation, the endpoint identification module creates three threads upon loading: an initial resolution consumer thread, a periodic refresh thread, and a configurable timer daemon thread. The initial resolution task queue is a static mutex linked list, storing all matching field entries (matchstr or prematch) to be resolved. The initial resolution consumer thread retrieves entries from the queue, calls the DNS resolution processor to perform resolution, and adds the obtained IP address to the corresponding primary matching ACL or prematch ACL. After resolution, non-IP format domain name entries are removed from the initial resolution task queue and inserted into the periodic refresh task queue. The periodic refresh thread blocks and waits for a condition variable signal using pthread_cond_wait. The configurable timer daemon thread runs at a preset period (minimum 10 seconds, configurable), sending pthread_cond_signal to wake up the periodic refresh thread at the end of each period. After being woken up, the periodic refresh thread traverses all domain name entries in the periodic refresh task queue, calls the DNS resolution processor to re-resolve each entry, and updates the corresponding ACL with atomic operations.

[0050] In the above embodiments, the division of responsibilities among the three threads follows a "producer-consumer" and "timed triggering-on-demand execution" design pattern. The initial resolution consumer thread is dedicated to handling batch resolution tasks during the startup phase, avoiding blocking the main thread. The periodic refresh thread adopts a condition variable-driven blocking-wake-up mechanism, rather than busy-wait polling, consuming almost no CPU resources when there are no refresh tasks. The configurable timer daemon thread grants administrator control over the refresh cycle, supporting flexible adjustment of the refresh frequency based on the DNS TTL policies of different ITSPs.

[0051] The above embodiments transform DNS resolution from a one-time static loading to continuous dynamic tracking, essentially introducing an adaptive mechanism for matching rules that synchronizes with the time-varying network environment. In traditional solutions, DNS resolution results are fixed as static snapshots, and the accumulated deviation from the actual network state over time eventually leads to matching failure. This invention, through periodic re-resolution by a periodic refresh thread, controls the "phase difference" between the matching rules and DNS records to within one refresh cycle. The retention of historical ACL versions (see below) further ensures that rules are not lost when re-resolution fails, achieving a smooth transition of DNS updates with zero interruption. This design allows the system to automatically follow ITSP load balancing switches, disaster recovery switches, or CDN node adjustments without manual intervention, fundamentally eliminating the risk of communication interruption caused by DNS changes.

[0052] In some embodiments, the DNS resolution step further includes a protocol-aware multi-address resolution process: Construct the corresponding DNS SRV record query name based on the transport protocol type field configured in the endpoint identification object; If the transport protocol type is DNSNAPTR, then SRV record queries for UDP, TCP, and TLS will be attempted in sequence according to a preset priority order. The SRV record is parsed to obtain one or more target domain names and ports. Then, the target domain name is queried for A or AAAA records to obtain one or more IP addresses. Update one or more IP addresses to the corresponding primary match ACL or pre-match ACL using atomic operations.

[0053] This embodiment details the protocol-aware multi-address resolution process. In one implementation, the DNS resolver first reads the tsptype field of the endpoint identification object. If tsptype is UDP, a query name "_sip._udp.<domain name>" is constructed; if it is TCP, "_sip._tcp.<domain name>" is constructed; if it is TLS, "_sips._tcp.<domain name>" is constructed; if it is DNSNAPTR, the above three SRV queries are cascaded in the order of UDP→TCP→TLS, and the first one to return a successful result is considered valid. The response returned by the SRV query contains one or more target domain names and their corresponding port numbers. For each target domain name, an A record query (to obtain the IPv4 address) or an AAAA record query (to obtain the IPv6 address) is performed. The resolution process supports automatic identification of the IPv6 format through square brackets "[]" in the address string, and can be configured to resolve only IPv4 or support dual stack through the compile-time options AST_AF_INET or AST_AF_UNSPEC. Finally, all resolved IP addresses are appended to the corresponding ACLs atomically.

[0054] In the above embodiments, the protocol-aware SRV query follows the RFC 3263 (Locating SIP Servers) specification, ensuring full compatibility with standard SIP infrastructure. The cascading attempt mechanism (UDP→TCP→TLS) automatically takes effect when tsptype is DNSNAPTR, eliminating the need for administrators to manually specify the fallback protocol and reducing configuration complexity. Multi-address resolution capability enables the system to obtain the complete IP addresses of all available nodes in the load balancing cluster, rather than just the first result, improving the coverage completeness of the matching rules.

[0055] In the above embodiments, the specific implementation of atomic ACL update is as follows: when constructing a new ACL linked list, the current ACL pointer is first saved to the historical version field (oldmatches or oldprematches), then new linked list nodes are created and the resolved IP addresses are added one by one, and finally the object's main ACL pointer is atomically pointed to the new linked list. This process ensures that at any point during the update, the inbound request matching operation always sees a complete and consistent ACL version (old version or new version), and there will be no intermediate state of partial linked list updates.

[0056] In some embodiments, before atomically updating the corresponding ACL, the periodic refresh thread first saves the pointer of the current ACL to the corresponding historical version ACL field; if the DNS re-resolution fails, the update operation is not performed, and the pointer in the historical version ACL field is retained to ensure that the matching rules remain valid.

[0057] This embodiment defines the atomic update and failure rollback mechanism for the periodic refresh thread. In one implementation, when the periodic refresh thread performs a re-resolution on a domain name entry, it first obtains the current primary matching ACL pointer of the endpoint identifier associated with the entry and saves it to the `oldmatches` field. Then, it calls the DNS resolver to perform a network query. If the query is successful and a list of IP addresses is obtained, a new ACL linked list is constructed based on this list. The primary matching ACL pointer is then updated to the new linked list, and finally, the memory of the old linked list pointed to by `oldmatches` is released. If an exception occurs during the DNS query, such as a network timeout, no response from the DNS server, or a return of an empty result, the thread does not perform the pointer update operation, retains the original pointer saved in `oldmatches`, and records the failure event in the system log. The original ACL linked list continues to be effective, ensuring that inbound request matching is not affected.

[0058] In the above embodiments, the historical version ACL field acts as a "safety fallback anchor." This mechanism avoids the risk of matching rules being cleared or corrupted due to re-resolution failures during network instability or temporary ITSP DNS service outages. For example, if an ITSP's DNS server experiences a brief downtime, without a fallback mechanism, re-resolution failures could lead to the ACL of the corresponding relay being cleared, causing all inbound requests to that relay to be rejected during this period. In this invention, however, the system only records the failure and retains the original rules, attempting to update again after the DNS service recovers in the next refresh cycle. The entire process is completely transparent to upper-layer call services.

[0059] In some embodiments, the method further includes a dynamic update step for matching rules to ensure hot reload safety: When a system configuration change triggers a module reload, the current primary matching ACL pointer and pre-matching ACL pointer of each endpoint identification object are saved to the corresponding historical version ACL field. The new matching field entry is submitted to the initial parsing task queue, and deduplication verification is performed on the initial parsing task queue and the periodic refresh task queue before submission; After the task is submitted, a condition variable signal is sent to wake up the initial parsing consumer thread, ensuring that the new configuration takes effect in a timely manner.

[0060] This embodiment covers the security update process under a hot reload configuration scenario. In one implementation, an administrator modifies the `matchstr` field of a relay endpoint (e.g., changing the IP address to a domain name) via a web interface or command-line interface, triggering the endpoint identification module reload in the configuration persistence framework. The module's registration entry function first iterates through all affected endpoint identification objects, performing pointer copy operations from `matches→oldmatches` and `prematches→oldprematches`. Subsequently, it performs deduplication verification on the matching field entries to be submitted—traversing the monitoring list to check if entries with the same identifier and type (`match / prematch`) already exist, avoiding duplicate resolution that could lead to ACL bloat. After successful verification, the new entry is submitted to the initial resolution task queue, and a condition variable signal is immediately sent to wake up the initial resolution consumer thread. Once awakened, the consumer thread retrieves the new entry from the queue, performs DNS resolution, and updates the ACL according to the aforementioned atomic update process.

[0061] In the above embodiments, the order of saving pointers first and then submitting them is crucial. If a new task is submitted first and the historical version is saved only after parsing, a time window exists where the old ACL has been released but the new ACL has not yet been built. Inbound requests arriving at this time will face missing matching rules. This invention saves the currently valid pointer to the historical version field first, ensuring that throughout the entire reload process—from when the old rule is marked as "historical" to when the new rule is fully effective—inbound requests can always be matched based on a valid ACL version. The deduplication mechanism prevents the same domain name from being added to the resolution queue multiple times due to duplicate configuration saving or administrator misoperation, avoiding unnecessary DNS query overhead and ACL list node redundancy.

[0062] In the above embodiments, the hot reload security mechanism and the aforementioned periodic refresh mechanism together constitute a reliability assurance system for the entire lifecycle of matching rules. The periodic refresh mechanism handles dynamic update scenarios where "rule content changes with the external environment," while the hot reload mechanism handles static update scenarios where "rule source changes with management intent." Both follow the core pattern of "saving history → building a new version → atomic switching," ensuring that the endpoint identification service remains continuous, consistent, and effective regardless of the reason for rule changes.

[0063] refer to Figure 2 To facilitate understanding of the second aspect of the invention, an adaptive endpoint identification system for SIP inbound requests is provided, comprising: The object configuration module 110 is configured to build an endpoint identification object containing multiple fields for each relay endpoint and create a corresponding dual-track ACL structure of a main matching ACL and a pre-matching ACL; The pattern recognition module 120 is configured to obtain the system's preset deployment mode identifier in response to a SIP inbound request; The strategy selection module 130 is configured to select one set as the active cascading matching strategy set from multiple sets of cascading matching strategies based on the deployment mode identifier; The policy execution engine 140 is configured to execute each level of matching policy in descending order of priority from the preset priority in the activated cascading matching policy set. Each level of matching policy is based on at least one feature information extracted from the SIP inbound request and performs matching operations with the corresponding matching field of each endpoint identification object and the corresponding main matching ACL or the pre-matching ACL. The result determination module 150 is configured to terminate the subsequent cascading matching process and return the matched endpoint identification object when a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, so as to complete the endpoint identification of the inbound request.

[0064] like Figure 2 As shown, the system includes: an object configuration module 110, a pattern recognition module 120, a strategy selection module 130, a strategy execution engine 140, and a result determination module 150. The strategy execution engine 140 internally contains multi-level matching strategies in priority order; the result determination module 150 is used to determine whether the matching result is unique, and based on the determination result, decides whether to return to the endpoint object or continue executing the next level strategy. Solid arrows indicate calls or data transfer relationships between modules, dashed lines indicate the internal logic expansion of a module, and dashed lines with arrows indicate feedback loops.

[0065] In this embodiment, the object configuration module 110 is driven by the configuration persistence framework. It is responsible for loading relay configurations from the database or configuration file and instantiating endpoint identification objects, and initializing two linked list structures, the main matching ACL and the pre-matching ACL, for each object. This module is called during system startup and configuration reload to ensure that the endpoint identification objects and ACL structures remain synchronized with the current configuration.

[0066] The pattern recognition module 120 is triggered by the SIP protocol stack and is invoked when an inbound request arrives. This module reads the global deployment mode identifier, which can be preset through configuration files, environment variables, or database parameters. Its value is used to characterize whether the system is currently deployed in a cloud-based scenario, a session boundary controller-based scenario, or a local direct-connection scenario.

[0067] The strategy selection module 130 internally maintains a policy registry for the first and second policy sets. This module receives a deployment mode identifier value from the pattern recognition module and, based on the preset mapping relationship between the identifier value and the policy sets, returns the corresponding active policy set handle. When the deployment mode identifier indicates a cloud or SBC deployment scenario, it returns the first policy set; when it indicates a local direct-connection deployment scenario, it returns the second policy set.

[0068] The policy execution engine 140, as the system's scheduling core, receives the activation policy set handle and the context information of the current SIP inbound request from the policy selection module. The engine sequentially calls the processing functions corresponding to each matching policy according to the preset priority order within the policy set. Each processing function extracts the feature information required for that policy level (such as SBC port, DID number, username, source IP address, transport protocol type, local interface IP, etc.) from the inbound request, iterates through all endpoint identification objects, and performs matching operations between the extracted feature information and the corresponding matching fields and associated ACLs of the objects. If the processing function of a certain policy level finds at least one matching candidate, the candidate list is passed to the next module.

[0069] The result determination module 150 receives the matching candidate results transmitted by the policy execution engine 140. This module executes short-circuit determination logic: if a certain level of policy returns a unique matching endpoint identifier, the cascading process is immediately terminated, subsequent policy processing functions are not called, and the identifier of the endpoint identifier (such as endpoint_name) is returned to the core routing engine as the final result. If a certain level of policy returns multiple matching candidates or no matching result, a continue execution signal is sent to the policy execution engine 140 to drive the execution of the next priority policy. If no unique match is found after traversing all policies, a matching failure flag is returned.

[0070] In the above embodiments, the object configuration module 110 focuses on the static modeling of endpoint identification objects, the pattern recognition module 120 is responsible for the perception of deployment scenarios, the policy selection module 130 undertakes the adaptation and selection of policy sets, the policy execution engine handles the dynamic process of cascading scheduling, and the result determination module 150 is responsible for the adjudication of short-circuit logic and the return of results. Separating steps four and five into two independent modules—the policy execution engine and the result determination module—decouples the execution logic of cascading traversal from the judgment logic of short-circuit termination, facilitating independent optimization. For example, the policy execution engine 140 can introduce parallel matching optimization, while the result determination module can be expanded to support a complex adjudication mechanism that supports weighted scoring and sorting. This modular design reduces system coupling and improves code maintainability and scalability.

[0071] In some embodiments, such as Figure 3This application also provides an electronic device, including a processor 301, a memory 302, a bus 303, and a computer program stored in the memory. When the processor executes the program, it implements an adaptive endpoint identification method for any of the SIP inbound requests described above. This electronic device can be an IPPBX server, a session boundary controller, a gateway device, or any device with computing and network communication capabilities.

[0072] Furthermore, as an executable solution, the adaptive endpoint identification system for SIP inbound requests can be a computer unit, which can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. The computer unit may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described structure of the computer unit is merely an example and does not constitute a limitation on the computer unit. It may include more or fewer components, or combine certain components, or use different components. For example, the computer unit may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

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

[0074] In some embodiments, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the adaptive endpoint identification method for SIP inbound requests described above in the embodiments of the present invention.

[0075] 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 non-volatile memory, such as hard disk, RAM, 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. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

[0076] Alternative implementation methods It should be understood that the above embodiments are merely illustrative examples of the present invention and not intended to limit the invention. Under the guidance of the inventive concept, those skilled in the art can make several extensions and modifications. Some alternative embodiments are listed below, and these methods should also fall within the protection scope of the present invention.

[0077] Alternative Method 1: Dynamically Adjusting the Priority of an Adaptive Matching Strategy Based on Hit Rate Statistics Building upon the multi-strategy cascaded matching engine, a matching hit rate statistics and adaptive learning mechanism can be further introduced. Specifically, the system maintains a sliding window hit rate counter for each level of the cascaded matching strategy set. This counter counts the proportion of times a strategy at that level successfully matches a unique endpoint identification object within a recent time window (e.g., the last 1000 inbound requests). The system periodically analyzes the hit rate distribution of each strategy (e.g., every hour or after completing a certain number of matching operations).

[0078] When the system detects that the hit rate of a certain matching strategy (e.g., the third-level strategy) is significantly higher than the hit rate of its preceding strategy (e.g., the second-level strategy) over multiple consecutive statistical periods, it automatically elevates the priority of that strategy. For example, it may swap the priority order of the third-level strategy and the second-level strategy. Conversely, if the hit rate of a certain strategy remains below a preset threshold, the system may downgrade its priority.

[0079] This mechanism enables the path length of cascading matching to be dynamically optimized based on the characteristics of actual inbound traffic, reducing unnecessary traversal on inefficient strategies and thus lowering the average endpoint identification latency. This alternative approach is particularly suitable for large-scale deployment scenarios where relay configurations change frequently, such as multi-tenant IPPBX platforms of cloud service providers, where the traffic characteristics of inbound requests may change dynamically with tenant business adjustments.

[0080] Alternative Method 2: Synchronization of Matching Rules and Sharing of DNS Resolution in a Distributed Cluster Environment The three-threaded DNS resolution architecture of this invention can be further extended to multi-node cluster deployment environments. In a cluster deployment, multiple IPPBX server nodes jointly provide communication services and distribute inbound requests through a load balancer. To avoid each node independently executing duplicate DNS queries, which would put query pressure on the ITSP DNS server and create the risk of inconsistent rules within the cluster, a centralized DNS resolution and incremental synchronization mechanism can be introduced.

[0081] Specifically, a master node is elected or pre-designated in the cluster. This master node runs the aforementioned initial resolution consumer thread, periodic refresh thread, and configurable timer daemon thread, and is responsible for the DNS resolution of all relay endpoint domain names. Each slave node does not need to perform DNS queries independently.

[0082] Once the master node completes a DNS resolution and obtains the list of IP addresses, it broadcasts the resolution result—i.e., an ACL list snapshot or its incremental changes—to all slave nodes in real time via a distributed message bus (e.g., a message middleware based on a publish / subscribe pattern). To reduce network transmission overhead, an incremental synchronization method is preferred: the master node compares the current resolution result with the previous resolution result and only encapsulates the changed ACL entries (newly added IP addresses or IP addresses to be deleted) into incremental update messages for broadcast. After receiving the incremental update message, each slave node applies the changes to its local corresponding ACL list in an atomic manner, ensuring that the matching rules of the entire cluster maintain eventual consistency.

[0083] This alternative approach can significantly reduce the total number of queries to the ITSP DNS service in large-scale clusters, reduce the risk of rate limiting or blocking that may be triggered by concurrent queries from multiple nodes, and at the same time ensure the consistency of endpoint identification behavior of all nodes in the cluster.

[0084] Alternative Method 3: Fuzzy Endpoint Identification and Multiple Candidate Ranking Based on Weighted Scoring In the standard implementation, if no uniquely matching endpoint identification object is generated after all multi-level cascading matching strategies have been executed, the system returns a matching failure. However, in some scenarios with ambiguous edges (e.g., two relay endpoints have extremely similar configurations, with only partial overlap in DID numbers), there may be multiple candidate endpoints that cannot be uniquely distinguished by precise rules.

[0085] To address this, a multi-dimensional weighted scoring mechanism can be introduced as a final fallback strategy for cascade matching. After cascade matching is completed, if there are multiple candidate endpoints (i.e., the multi-level strategy generates different matching candidates) or if there are no exact matches but some matches (e.g., the DID suffix is ​​successfully matched but other fields are not completely matched), the system calculates a comprehensive matching score for each candidate endpoint.

[0086] The evaluation dimensions of the comprehensive matching score may include, but are not limited to: IP address matching accuracy: The longer the length of the matched CIDR address block mask (i.e., the more precise the address range), the higher the score for this item.

[0087] Port number matching degree: Full marks are awarded for an exact match of the Contact port or SBC port, and scores decrease for partial matches or no matches.

[0088] DID Number Matching Length Ratio: The higher the ratio of the length of the characters matching the called number with the DID entry to the total length of the called number, the higher the score.

[0089] Endpoint activity: The more recent the time when the relay endpoint successfully established a call, the higher the score, reflecting the probability that the endpoint is currently active and available.

[0090] The system sorts all candidate endpoints in descending order of their overall scores, selects the endpoint with the highest score as the final identification result, and routes the inbound request to that endpoint. This alternative approach provides a "best effort" routing decision for edge-ambiguous scenarios where rules cannot precisely distinguish between them, further improving the system's adaptability and routing success rate in complex, non-standardized deployment environments.

[0091] 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. An adaptive endpoint identification method for SIP inbound requests, characterized in that, Includes the following steps: Step 1: Build an endpoint identification object for each trunk endpoint configured in the IP PBX system. The endpoint identification object contains multiple matching fields related to endpoint identification. Create a dual-track ACL structure for each endpoint identification object, which contains at least one primary matching access control list (ACL) and one pre-matching ACL. Step 2: In response to receiving a SIP inbound request, obtain the preset deployment mode identifier of the IPPBX system. The deployment mode identifier is used to characterize whether the system is currently deployed in a cloud-based scenario, a Session Border Controller (SBC) deployment scenario, or a local direct-connection deployment scenario. Step 3: Based on the deployment mode identifier, select one set from the pre-configured set of multiple cascading matching strategies as the currently active cascading matching strategy set; wherein, the multiple sets of cascading matching strategies include at least a first strategy set applicable to cloud or SBC deployment scenarios and a second strategy set applicable to local direct connection deployment scenarios; Step 4: Execute each level of matching strategy in descending order of priority from the pre-set priority in the activated cascading matching strategy set. Each level of matching strategy is based on at least one feature information extracted from the SIP inbound request and performs matching operations with the corresponding matching field of each endpoint identification object and the corresponding main matching ACL or pre-matching ACL. Step 5: When a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, the subsequent cascading matching process is terminated, and the matched endpoint identification object is returned to complete the endpoint identification of the inbound request.

2. The method according to claim 1, characterized in that, The first set of strategies, ordered from highest to lowest priority, includes: Level 1 strategy: Extract the SBC port number of the SIP inbound request, match it with the port field of the endpoint identification object, and verify that the source IP address of the request matches the pre-matched ACL; Second-level strategy: Extract the called number and real source address of the SIP inbound request, verify that the called number matches the DID number list of the endpoint identification object, and that the real source address matches the pre-matched ACL; Third-level strategy: When the second-level strategy fails, perform DID suffix fuzzy matching, and compare the last character of the suffix of the called number with the entries in the DID number list; Level 4 strategy: Only verify that the source IP address of the request matches the pre-matched ACL; Level 5 strategy: Extract the Contact header address and port of the SIP inbound request, and verify that the Contact header address matches the main matching ACL and that the Contact header port matches the port field of the object; Level 6 Strategy: Verify that the transport protocol type of the SIP inbound request matches the transport protocol type field of the endpoint identification object, and verify that the source IP address of the request matches the primary matching ACL.

3. The method according to claim 1, characterized in that, The second set of strategies, ordered from highest to lowest priority, includes: Level 1 strategy: Extract the username and source IP address of the SIP inbound request, verify that the username matches the username field of the endpoint identification object, that the source IP address matches the main matching ACL, and verify that the called number matches the DID number list when the DID number list is not empty; Second-level strategy: Extract the local interface IP address where the SIP inbound request arrives, verify that the local interface IP address matches the interface IP binding field of the endpoint identification object, the source IP address hits the main matching ACL, and the Contact port matches the port field of the object; Level 3 strategy: Verify that the source IP address matches the main matching ACL, and that the Contact port matches the port field of the object; Level 4 strategy: Only verify that the source IP address matches the primary matching ACL; Fifth-level strategy: Extract the complete URI address from the Contact header field of the SIP inbound request and verify that the URI address matches the main matching ACL.

4. The method according to claim 1, characterized in that, It also includes the DNS adaptive resolution step: The initial resolution consumer thread is started to retrieve domain name entries from the initial resolution task queue, perform DNS resolution, and update the resolved IP address to the main matching ACL or the pre-matching ACL of the corresponding endpoint identification object; Start a periodic refresh thread, which, after being woken up by a condition variable, iterates through the domain name entries in the periodic refresh task queue, re-executes DNS resolution, and atomically updates the corresponding primary matching ACL. Start a configurable timer daemon thread to wake up the periodic refresh thread at a preset period using the condition variable.

5. The method according to claim 4, characterized in that, The DNS resolution step also includes a protocol-aware multi-address resolution process: Construct the corresponding DNS SRV record query name based on the transport protocol type field configured in the endpoint identification object; If the transport protocol type is DNSNAPTR, then SRV record queries for UDP, TCP, and TLS will be attempted in sequence according to a preset priority order. The SRV record is parsed to obtain one or more target domain names and ports. Then, the target domain name is queried for A or AAAA records to obtain one or more IP addresses. Update the one or more IP addresses to the corresponding primary matching ACL or pre-matching ACL using atomic operations.

6. The method according to claim 4, characterized in that, Before atomically updating the corresponding ACL, the periodic refresh thread first saves the pointer of the current ACL to the corresponding historical version ACL field; if the DNS re-resolution fails this time, the update operation is not performed, and the pointer in the historical version ACL field is retained to ensure that the matching rules remain valid.

7. The method according to claim 1, characterized in that, It also includes a dynamic update step for matching rules to ensure hot reload safety: When a system configuration change triggers a module reload, the current primary matching ACL pointer and pre-matching ACL pointer of each endpoint identification object are saved to the corresponding historical version ACL field. The new matching field entry is submitted to the initial parsing task queue, and deduplication verification is performed on the initial parsing task queue and the periodic refresh task queue before submission; After the task is submitted, a condition variable signal is sent to wake up the initial parsing consumer thread, ensuring that the new configuration takes effect in a timely manner.

8. An adaptive endpoint identification system for SIP inbound requests, characterized in that, The system for implementing the method of any one of claims 1 to 7 comprises: The object configuration module is configured to build an endpoint identification object containing multiple fields for each relay endpoint and create a corresponding dual-track ACL structure consisting of a main matching ACL and a pre-matching ACL. The pattern recognition module is configured to obtain the system's preset deployment mode identifier in response to a SIP inbound request; The strategy selection module is configured to select one set as the active cascading matching strategy set from multiple sets of cascading matching strategies based on the deployment mode identifier; The policy execution engine is configured to execute each level of matching policy in descending order of priority from the pre-set priority in the activated cascading matching policy set. Each level of matching policy is based on at least one feature information extracted from the SIP inbound request and performs matching operations with the corresponding matching field of each endpoint identification object and the corresponding main matching ACL or pre-matching ACL. The result determination module is configured to terminate the subsequent cascading matching process and return the matched endpoint identification object when a unique endpoint identification object is successfully matched for the first time in the first-level matching strategy, so as to complete the endpoint identification of the inbound request.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1 to 7.

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

Images