A method and device for managing SIP terminal inbound registration and a storage medium

Abstract

The application belongs to the field of Internet protocol communication, and particularly relates to a SIP terminal inbound registration management method and device and a storage medium, which comprises the following steps: receiving a SIP inbound registration request and performing in series; performing registration permission bitmap checking, source IP address checking, terminal identification checking and transmission protocol type checking on the SIP inbound registration request; replacing old contacts in the same type and the same terminal, and deleting contacts in mutually exclusive terminal types; finding registered contacts under the same AoR, and expelling old contacts with the same address; if the number of non-self-developed terminal contacts reaches the upper limit of the general quota, and the OPTIONS health probe alive timeout counter of the non-self-developed terminal is greater than a preset value, deleting the contacts corresponding to the non-self-developed terminal; and then deleting the contacts in the order of expiration until the requirement is met. The scheme can eliminate the deficiencies of the existing SIP registration management technology in terms of multi-dimensional security, terminal perception, proxy penetration and zombie cleaning.

Description

Technical Field

[0001] This application belongs to the field of Internet Protocol communication technology, specifically relating to a SIP terminal inbound registration and control method, device and storage medium. Background Technology

[0002] In VoIP (Voice over Internet Protocol) communication systems, inbound registration using the Session Initiation Protocol (SIP) is the primary step in establishing a communication link. A single user account (Address of Record, AoR) may simultaneously have registered contacts across multiple terminal types, including desktop phones, mobile clients, web browsers, and tablet applications. As enterprise unified communications deployments become increasingly complex, existing SIP registration mechanisms exhibit the following technical shortcomings: The registration security verification dimension is too simple: Traditional SIP engines usually only perform basic digest authentication on inbound registration requests, which makes it easy for unauthorized devices to complete the registration, creating security risks.

[0003] Unaware of terminal type and inefficient quota management: Existing solutions apply a uniform maximum contact limit to all contacts under the same AoR, which cannot implement differentiated quota strategies based on terminal type, resulting in wasted contact resources and chaotic call routing.

[0004] Contact identification distortion in proxy-based scenarios: In OnSite proxy deployment mode, all terminal registration requests are routed through the proxy gateway, and the source address is uniformly changed to the proxy address. Traditional contact identification mechanisms based on source IP completely fail in this scenario, leading to duplicate contact accumulation and erroneous eviction.

[0005] Zombie contacts remain active for extended periods: After a terminal experiences an abnormal disconnection, its registered contacts are retained until their expiration time. During this period, the contact continues to occupy quotas and may cause calls to be routed to unreachable terminals, severely impacting communication quality.

[0006] In summary, existing SIP registration and control technologies have significant shortcomings in terms of multi-dimensional security, endpoint awareness, proxy penetration, and botnet removal, and a more comprehensive solution is urgently needed. Summary of the Invention

[0007] To overcome the shortcomings of existing SIP registration and control technologies in terms of multi-dimensional security, terminal awareness, proxy penetration, and botnet removal, this application provides a SIP terminal inbound registration and control method, the method comprising: Receive SIP inbound registration requests and route them to the AoR serialization task processor for serial execution; The SIP inbound registration request is validated using a registration permission bitmap. If the validation passes, it is determined whether the SIP inbound registration request is an OnSite proxy request. If not, the source IP address, terminal identifier, and transport protocol type of the SIP inbound registration request are validated. If yes, the terminal identifier of the SIP inbound registration request is validated. Based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals. Remove duplicates from existing contacts of the same type and on the same device, and delete contacts on mutually exclusive device types. Find registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, extract the registered username, terminal private network address and port, and proxy public network address and port as the address to be matched, and remove old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, extract the source IP address as the address to be matched, and remove old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, extract the host address and port portion as the address to be matched, and remove old contacts with the same address. If the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota, the number of contacts to be deleted is calculated. If the OPTIONS health detection timeout counter of the non-self-developed terminal is greater than the preset value, the contacts corresponding to the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, the contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met.

[0008] In one possible implementation, the step of performing registration permission bitmap verification on the SIP inbound registration request includes: If the SIP inbound registration request comes from a non-self-developed terminal, the SIP inbound registration request is verified through a pre-configured general registration permission bitmap. The general registration permission bitmap has 2 bits, which control the registration permission of extensions and analog trunks respectively. If all bits of the general registration permission bitmap are 0, registration of non-self-developed terminals is prohibited. If the SIP inbound registration request comes from a self-developed terminal, perform a bitwise AND operation between the terminal type of the self-developed terminal and the pre-configured terminal registration permission bitmap. The terminal registration permission bitmap has 5 bits, which respectively control the registration permission of mobile terminal, desktop terminal, web terminal, tablet terminal and dynamic CRM terminal. If the operation result is all 0, the self-developed terminal registration is prohibited.

[0009] In one possible implementation, the verification of the source IP address, terminal identifier, and transport protocol type of the SIP inbound registration request includes: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check whether the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration. The terminal identifier verification for the SIP inbound registration request includes: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

[0010] In one possible implementation, the process of deduplicating and replacing old contacts in the same type and on the same terminal includes: Parse the custom device tag header field in the SIP inbound registration request and construct a callback data structure containing the current terminal type and device tag; Scan registered contacts under the same AoR to identify registered contacts belonging to the same terminal type as the SIP inbound registration request. Perform a case-insensitive exact comparison on the device tags of registered contacts of the same type and the SIP inbound registration request. If there is a complete match, call the location service deletion interface to remove the old contact and increment the deletion counter.

[0011] In one possible implementation, deleting a contact in a mutually exclusive terminal type includes: Construct a set of mutually exclusive terminals containing the terminal types to which SIP inbound registration requests belong; Perform a bitwise OR operation on mutually exclusive terminal types to generate a judgment mask; Perform a bitwise AND operation between the terminal type of the registered contacts under the same AoR and the judgment mask. If the result is not 0, delete the corresponding registered contacts.

[0012] In one possible implementation, the method further includes: If the SIP inbound registration request is an OnSite proxy request, automatically suppress the reporting of registration failure events; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally.

[0013] Secondly, embodiments of this application provide a SIP terminal inbound registration and control device, the device comprising: The receiving module is used to receive SIP inbound registration requests and route the SIP inbound registration requests to the AoR serialization task processor for serial execution. The verification module is used to perform registration permission bitmap verification on SIP inbound registration requests. After passing the verification, it determines whether the SIP inbound registration request is an OnSite proxy request. If not, it verifies the source IP address, terminal identifier, and transmission protocol type of the SIP inbound registration request. If yes, it verifies the terminal identifier of the SIP inbound registration request. Based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals. The first contact deletion module is used to remove duplicates from old contacts of the same type and on the same terminal, and to delete contacts on mutually exclusive terminal types. The second contact deletion module is used to find registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, it extracts the registered username, terminal private network address and port, and proxy public network address and port as the address to be matched, and removes old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, it extracts the source IP address as the address to be matched, and removes old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, it extracts the host address and port portion as the address to be matched, and removes old contacts with the same address. The third contact deletion module is used to calculate the number of contacts to be deleted if the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota. When the OPTIONS health detection timeout counter of a non-self-developed terminal is greater than a preset value, the corresponding contacts of the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, the contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met.

[0014] In one possible implementation, the verification module is specifically used for: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check whether the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration. The terminal identifier verification for the SIP inbound registration request includes: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

[0015] In one possible implementation, the device further includes an event reporting module, specifically used for: If the SIP inbound registration request is an OnSite proxy request, automatically suppress the reporting of registration failure events; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally.

[0016] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described SIP terminal inbound registration and control methods.

[0017] This application provides a SIP terminal inbound registration control method, comprising: receiving a SIP inbound registration request; routing the SIP inbound registration request to an AoR serialization task processor for serial execution; performing registration permission bitmap verification on the SIP inbound registration request; after passing the verification, determining whether the SIP inbound registration request is an OnSite proxy request; if not, performing source IP address verification, terminal identifier verification, and transmission protocol type verification on the SIP inbound registration request; if yes, performing terminal identifier verification on the SIP inbound registration request; wherein, based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals; deduplicating and replacing old contacts in the same type and terminal, and deleting contacts in mutually exclusive terminal types; searching for registered contacts under the same AoR, and if the SIP inbound registration request is valid, the method is considered valid. If the request is an OnSite proxy request, the registered username, terminal private network address and port, and proxy public network address and port are extracted as the address identifier to be matched, and old contacts of the same terminal under the same proxy are expelled. If the SIP inbound registration request is an SBC / FQND proxy request, the source IP address is extracted as the address identifier to be matched, and old contacts of the same terminal are expelled. If the SIP inbound registration request is a direct connection request, the host address and port portion is extracted as the address identifier to be matched, and old contacts of the same address are expelled. If the number of contacts of a non-self-developed terminal reaches the upper limit of the general device quota, the number of contacts to be deleted is calculated. When the OPTIONS health probe timeout counter of a non-self-developed terminal is greater than a preset value, the contacts corresponding to the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met. This solution can eliminate the shortcomings of existing SIP registration control technologies in terms of multi-dimensional security, terminal awareness, proxy penetration, and zombie cleanup. Attached Figure Description

[0018] Figure 1 This application provides a method for controlling the inbound registration of SIP terminals. Figure 2 A timing diagram for REGISTER request inbound and serialization scheduling; Figure 3 A sequence diagram for a five-layer cascaded security guard system; Figure 4 A sequence diagram for terminal type-aware quota control; Figure 5 Find the eviction sequence diagram for the contact person at the same address; Figure 6 Timing diagram for pre-eviction of unreachable terminals; Figure 7 Write a sequence diagram for contacts and event notifications. Detailed Implementation

[0019] In VoIP (Voice over Internet Protocol) communication systems, inbound registration using the Session Initiation Protocol (SIP) is the primary step in establishing a communication link. A single user account (Address of Record, AoR) may simultaneously have registered contacts across multiple terminal types, including desktop phones, mobile clients, web browsers, and tablet applications. As enterprise unified communications deployments become increasingly complex, existing SIP registration mechanisms exhibit the following technical shortcomings: The registration security verification dimension is too simple: Traditional SIP engines usually only perform basic digest authentication on inbound registration requests, which makes it easy for unauthorized devices to complete the registration, creating security risks.

[0020] Unaware of terminal type and inefficient quota management: Existing solutions apply a uniform maximum contact limit to all contacts under the same AoR, which cannot implement differentiated quota strategies based on terminal type, resulting in wasted contact resources and chaotic call routing.

[0021] Contact identification distortion in proxy-based scenarios: In OnSite proxy deployment mode, all terminal registration requests are routed through the proxy gateway, and the source address is uniformly changed to the proxy address. Traditional contact identification mechanisms based on source IP completely fail in this scenario, leading to duplicate contact accumulation and erroneous eviction.

[0022] Zombie contacts remain active for extended periods: After a terminal experiences an abnormal disconnection, its registered contacts are retained until their expiration time. During this period, the contact continues to occupy quotas and may cause calls to be routed to unreachable terminals, severely impacting communication quality.

[0023] In summary, existing SIP registration and control technologies have significant shortcomings in terms of multi-dimensional security, endpoint awareness, proxy penetration, and botnet removal, and a more comprehensive solution is urgently needed.

[0024] Firstly, see [the following] Figure 1 This application provides a method for controlling SIP terminal inbound registration, the method comprising: S101 receives the SIP inbound registration request and routes it to the AoR serialization task processor for serial execution.

[0025] All registration processing tasks are routed via AoR key-value to serialization task processors in 59 buckets of reference-counted object containers for serialization execution. A global exclusive control lock protects the atomicity of the "lookup or create" operation, ensuring that concurrent REGISTER requests within the same AoR are processed serially and eliminating race conditions.

[0026] S102, perform registration permission bitmap verification on the SIP inbound registration request. If the verification passes, determine whether the SIP inbound registration request is an OnSite proxy request. If not, perform source IP address verification, terminal identifier verification, and transport protocol type verification on the SIP inbound registration request. If yes, perform terminal identifier verification on the SIP inbound registration request.

[0027] Specifically, based on the terminal identifier carried in the SIP inbound registration request, the terminals are distinguished into self-developed terminals and non-self-developed terminals, and a general equipment quota limit is pre-configured for non-self-developed terminals.

[0028] If the SIP inbound registration request comes from a non-self-developed terminal, the SIP inbound registration request is verified through a pre-configured general registration permission bitmap. The general registration permission bitmap has 2 bits, which control the registration permission of extensions and analog trunks respectively. If all bits of the general registration permission bitmap are 0, registration of non-self-developed terminals is prohibited. If the SIP inbound registration request comes from a self-developed terminal, perform a bitwise AND operation between the terminal type of the self-developed terminal and the pre-configured terminal registration permission bitmap. The terminal registration permission bitmap has 5 bits, which respectively control the registration permission of mobile terminal, desktop terminal, web terminal, tablet terminal and dynamic CRM terminal (Customer Relationship Management). If the operation result is all 0, the self-developed terminal registration is prohibited.

[0029] The meaning of passing the verification is that, for non-self-developed terminals, at least one bit of the general registration permission bitmap is 1, and for self-developed terminals, the terminal type matches one of mobile terminal, desktop terminal, web terminal, tablet terminal, or dynamic CRM terminal, so that the result of the bitwise AND operation is not all 0.

[0030] Registration permission bitmap verification is only the first step; further verifications are required, specifically: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check if the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration.

[0031] For OnSite proxy requests, the source address of the SIP inbound registration request will become the proxy address. Therefore, only endpoint identifier whitelist filtering is performed, including: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

[0032] This application addresses dual-NIC deployment scenarios. At startup, it uses a socket ioctl system call to obtain the local IP addresses of the primary NIC (eth0) and secondary NIC (eth0:1), and calculates the range of each network segment based on the subnet mask configured at the endpoints. When a registration request arrives, the system matches the request source IP address against the network segments of both the primary and secondary NICs. First, it combines the local IP address with the subnet mask in CIDR (Classless Inter-Domain Routing) format for network segment comparison. Only when the source address falls into either local network segment is it considered an internal network registration and allowed; REGISTER requests from external networks are directly blocked and a 403 error is returned. This layer also supports IPv6 dual-stack scenarios. When an IPv6 format source address is detected, it automatically switches to IPv6 address segment matching logic, traversing a comma-separated list of IPv6 prefixes for prefix comparison.

[0033] The next layer is IP address range restriction verification. The system maintains four independent IP permission lists (permit1~permit4), each supporting CIDR-formatted IPv4 and IPv6 address range configurations. After extracting the source address of the REGISTER request, it sequentially performs a matching operation with the four permission lists—if any one list matches, the request is approved; if none matches, registration is rejected. When the request carries the real source address header field (SourceAddr) for proxy forwarding, the system prioritizes using this header field value to replace the transport layer source address for matching, ensuring that the terminal's real address can still be correctly identified after forwarding through intermediate proxies such as SBCs (Session Border Controllers).

[0034] The fourth layer of verification is the User-Agent whitelist filtering. The system maintains a configurable User-Agent prefix whitelist, storing multiple allowed terminal identifier prefixes separated by commas. After extracting the User-Agent header field value from the REGISTER request, the whitelist string is split into independent entries by commas, and a case-insensitive prefix matching (strncasecmp) is performed on each entry. If no whitelist entry is matched, registration is rejected. This layer only applies to third-party SIP phones; self-developed terminals are automatically exempt.

[0035] The fifth layer is the transport protocol consistency check. The system records the pre-configured transport protocol type (UDP / TCP / TLS / WSS / WS) of the endpoint and parses the actual transport parameters used from the Contact URI in the REGISTER request. The parsing logic first checks the transport parameter value in the URI. If it is not explicitly carried, it infers the protocol based on the URI protocol prefix (sips: defaults to TLS, others default to UDP). Finally, it performs a precise string comparison between the inferred protocol and the endpoint configuration value. If they do not match, registration is rejected. This layer effectively prevents registration attacks that attempt to launch through unauthorized transport channels. Requests relayed through the OnSite proxy automatically skip this layer of verification.

[0036] If any of the above verification layers fails, the registration process will be terminated and the corresponding SIP error response code (403 Forbidden) will be returned.

[0037] S103, perform duplicate replacement on old contacts of the same type and terminal, and delete contacts of mutually exclusive terminal types.

[0038] Parse the custom device tag header field in the SIP inbound registration request and construct a callback data structure containing the current terminal type and device tag; Scan registered contacts under the same AoR to identify registered contacts belonging to the same terminal type as the SIP inbound registration request. Perform a case-insensitive exact comparison on the device tags of registered contacts of the same type and the SIP inbound registration request. If there is a complete match, call the location service deletion interface to remove the old contact and increment the deletion counter.

[0039] The system parses the custom device marker header field (Device-Mark) in the request, constructs a callback data structure containing the current terminal type and device marker, and scans all registered contacts under the same AoR using a reference-counted object container's traversal callback function. Within the callback function, a dual check is performed on each contact: first, URI terminal type matching confirms they belong to the same terminal type group; then, a case-insensitive exact comparison of the device marker (strcasecmp) is performed. If the device marker matches exactly, the location service deletion interface is called to remove the old contact in place and increment the deletion counter; otherwise, the current counter is incremented. This mechanism prevents contact accumulation caused by multiple registrations of the same physical device due to network switching or other reasons.

[0040] The above-mentioned deletion of contacts in mutually exclusive terminal types can specifically include: Construct a set of mutually exclusive terminals containing the terminal types to which SIP inbound registration requests belong; Perform a bitwise OR operation on mutually exclusive terminal types to generate a judgment mask; Perform a bitwise AND operation between the terminal type of the registered contacts under the same AoR and the judgment mask. If the result is not 0, delete the corresponding registered contacts.

[0041] The system predefines mutually exclusive terminal type pairs—desktop client (LINKUS_PC) and web desktop client (WEB_PC) are mutually exclusive. When a desktop client initiates registration, the terminal type field to be deleted in the callback data structure is set to a bitwise OR of the two types (LINKUS_PC | WEB_PC). The callback function iterates through the contacts and deletes them if they belong to either mutually exclusive type. When a web desktop client initiates registration, a symmetrical operation is performed. This mutual exclusion mechanism ensures that at any given time, only one of the desktop and web desktop clients is alive under the same AoR, eliminating the problem of residual contacts when users switch between the two desktop clients.

[0042] For example, if the terminal type of the SIP inbound registration request is a desktop client, the mutually exclusive terminal set consists of desktop clients and web desktop clients. Desktop clients are represented as 0b01, and web desktop clients are represented as 0b10. The judgment mask is constructed as 0b11. If there are contact 1 (0b00), contact 2 (0b01), and contact 3 (0b10) under the same AoR, after performing a bitwise AND operation with the judgment mask, the result for contact 1 is 0, so no eviction is needed; the result for contact 2 is non-zero, so eviction is needed; and the result for contact 3 is non-zero, so eviction is needed. As can be seen from the results, not only can eviction of mutually exclusive terminal types be achieved, but also eviction of terminals of the same type can be achieved.

[0043] S104: Locate registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, extract the registered username, terminal private network address and port, and proxy public network address and port as the address identifier to be matched, and expel old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, extract the source IP address as the address identifier to be matched, and expel old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, extract the host address and port portion as the address identifier to be matched, and expel old contacts with the same address.

[0044] Before adding a new contact, if a contact already exists under AoR, a multi-source address matching eviction process is performed to prevent duplicate contact accumulation caused by the same physical terminal registering with different URIs. The system automatically selects three differentiated matching strategies based on the registration source and compares them one by one through the traversal callback function of a reference-counting object container: OnSite proxy scenario: The system retrieves a custom SIP header field named "OnSiteUUID" from the REGISTER request. This header field carries six fields separated by vertical bars. The system parses and extracts the following fields in sequence: Proxy Unique Identifier (UUID), Terminal Private Network Address and Port (phone_ip:port), Transport Protocol Type, Proxy Public Network Address and Port (public_ip:port), and Registered Username (user). Each field is then persisted to the corresponding member variable in the contact details structure (registrar_contact_details).

[0045] During the contact lookup phase (registrar_find_contact callback), when a request carrying the OnSite header field is detected and the contact object already stores OnSite information, the system skips the standard PJSIP URI comparison logic. Instead, it performs three strncmp exact comparisons using a triple consisting of "proxy public IP address and port (onsite_public_ip_port) + terminal private IP address and port (onsite_private_ip_port) + registered username (onsite_user)" as the unique identifier for the contact. If all three match, it returns CMP_MATCH | CMP_STOP. This mechanism accurately identifies duplicate registrations of the same terminal in proxy scenarios, avoiding misjudgments caused by the proxy uniformly rewriting the Contact URI.

[0046] SBC / FQDN proxy scenarios: When the `sbc_real_ip_port` field of the contact object is not empty (indicating that it was registered through an SBC proxy), the real address extracted from the `SourceAddr` header field in the request is compared using the `strncmp` prefix; if a match is found, the contact is deleted. This strategy solves the problem of accurate identification when multiple terminals share the same proxy exit address in an SBC scenario.

[0047] Direct connection scenario: When the contact is neither an OnSite source nor an SBC source, extract the host address and port portion (host:port) from the contact URI using sscanf formatting after "@" and before ";", compare it with the source address and port of the inbound request using strcmp, and delete it if they match.

[0048] S105, if the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota, calculate the number of contacts to be deleted. When the OPTIONS health detection timeout counter of the non-self-developed terminal is greater than the preset value, delete the contacts corresponding to the non-self-developed terminal. If the number of contacts to be deleted is still not met after deletion, delete the contacts one by one in order of expiration time according to the expiration time of each contact until the number of contacts to be deleted is met.

[0049] When the number of contacts on a non-self-developed terminal under the same AoR has reached the general device quota limit (max_comm_contacts) and the current request includes adding new contacts, the system performs a double-rule cascading pre-cleanup before writing new contacts: Rule 1 (Health Explorers Exit Overtime) Calculate the number of contacts to be deleted (del_num = number of registered contacts - quota limit + number of new contacts), then initialize a container iterator to traverse all contacts under this AoR. For each contact, obtain its real-time status object (contact_status) through the configuration framework's search interface, and check the OPTIONS health probe timeout counter (timeoutcount). The timeout counter is reset to zero when the contact responds normally, and incremented otherwise. Skip contacts from self-developed terminals (filtered by URI terminal type matching). If the timeout count of a non-self-developed terminal is strictly greater than 1 (i.e., more than two consecutive probes without response), it is determined to be an unreachable terminal. Immediately call the location service deletion interface to remove the contact and disconnect it from the container, synchronously publish a deregistration management event (SIPUnRegister) to notify the upper-layer system, and decrement the del_num counter.

[0050] Rule 2 (Most Recently Expired Eviction) If del_num is still greater than zero after the rule traversal is completed (i.e., the number of unreachable terminals is insufficient to release the required quota), the system calls the excess contact deletion function—initializing a new container iterator, traversing all non-self-developed terminal contacts, finding the contact with the closest expiration time to the current time through the millisecond-level time difference comparison of expiration_time (ast_tvdiff_ms), deleting it and unlinking it from the container, and repeating the process until del_num returns to zero.

[0051] The dual-rule cascading ensures that zombie contacts that have been confirmed as unreachable are removed first, while retaining the registration status of healthy contacts with sufficient validity period to the greatest extent possible.

[0052] This application provides a SIP terminal inbound registration control method, comprising: receiving a SIP inbound registration request; routing the SIP inbound registration request to an AoR serialization task processor for serial execution; performing registration permission bitmap verification on the SIP inbound registration request; after passing the verification, determining whether the SIP inbound registration request is an OnSite proxy request; if not, performing source IP address verification, terminal identifier verification, and transmission protocol type verification on the SIP inbound registration request; if yes, performing terminal identifier verification on the SIP inbound registration request; wherein, based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals; deduplicating and replacing old contacts in the same type and terminal, and deleting contacts in mutually exclusive terminal types; searching for registered contacts under the same AoR, and if the SIP inbound registration request is valid, the method is considered valid. If the request is an OnSite proxy request, the registered username, terminal private network address and port, and proxy public network address and port are extracted as the address identifier to be matched, and old contacts of the same terminal under the same proxy are expelled. If the SIP inbound registration request is an SBC / FQND proxy request, the source IP address is extracted as the address identifier to be matched, and old contacts of the same terminal are expelled. If the SIP inbound registration request is a direct connection request, the host address and port portion is extracted as the address identifier to be matched, and old contacts of the same address are expelled. If the number of contacts of a non-self-developed terminal reaches the upper limit of the general device quota, the number of contacts to be deleted is calculated. When the OPTIONS health probe timeout counter of a non-self-developed terminal is greater than a preset value, the contacts corresponding to the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met. This solution can eliminate the shortcomings of existing SIP registration control technologies in terms of multi-dimensional security, terminal awareness, proxy penetration, and zombie cleanup.

[0053] In one example, if the SIP inbound registration request is an OnSite proxy request, the reporting of registration failure events is automatically suppressed; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally. After registration is complete, the system sends a registration event notification to the upper-layer security management system via the inter-process communication interface. The event carries three status codes: registration successful (REG_STATUS_SUCC), account does not exist (REG_STATUS_ACCOUNT_NOT_EXIST), and registration failed (REG_STATUS_FAIL), as well as the terminal's source IP address information. The upper-layer security system then executes IP reputation assessments and automatic blocking policies accordingly.

[0054] Core security linkage strategy: When a request is relayed through the OnSite proxy (with the is_onsite_proxy flag set to true), the system automatically suppresses event reporting in both the "account does not exist" and "registration failed" error handling branches. This is because, in a proxy scenario, the source address of a registration failure is the proxy gateway IP, not the actual attack source IP. Reporting such an event would cause the upper-layer security system to mistakenly blacklist the proxy gateway IP, resulting in a cascading block of registration requests from all legitimate terminals under that proxy, causing a catastrophic chain reaction of interruptions.

[0055] This application's solution begins by receiving a SIP REGISTER request, which is then routed to 59 AoR serializers. A global exclusive lock protects the atomicity of the lookup or creation process, parsing over 20 custom SIP header fields (SourceAddr, Device-Mark, OnSiteUUID, Linkus Type, etc.). Upon receiving a SIP REGISTER request, the first step is a five-layer cascaded security check. The first layer uses a 2-bit general bitmap and a 5-bit terminal bitmap to perform registration permission bitmap verification. If successful, the OnSiteUUID header field is used to determine if it's an OnSite proxy request. If not, all subsequent checks are performed, including a second layer of dual-NIC network segment matching. If successful, a third layer of matching is performed on each of the four permission lists. If any set is matched, a fourth layer of UA whitelist filtering is performed. Finally, a fifth layer of transport protocol consistency verification is performed. If any layer fails, registration fails. If it's an OnSite proxy request, the OnSiteUUID header field six-tuple is parsed, and a fourth layer of UA whitelist filtering is then performed.

[0056] The second step is terminal type-aware quota management. It parses the terminal type enumeration, including mobile, desktop, web desktop, web client, dynamic CRM, and tablet. If a contact of the same type and on the same device is detected, the old contact is deleted and replaced in place. If mutually exclusive terminal types exist, all contacts of mutually exclusive types are deleted. If the current quota is not full (the number of contacts of the current type is less than the quota limit), a contact search is performed to confirm whether a registered contact exists. This search includes three strategies: exact match by triplet, match by SBC real address, and standard PJSIP URI comparison.

[0057] The third step is multi-source same-address eviction. For OnSite proxies, it matches according to the triple format mentioned above and evictions old contacts under the same proxy and terminal. For SBC / FQDN proxies, it matches the source address and real address mentioned above and evictions old contacts with the same physical terminal. For direct connections, it matches the URI address extracted mentioned above and evictions old contacts with the same address.

[0058] The fourth step is a dual-rule cascading pre-eviction process. If the number of contacts for non-self-developed terminals is less than the general quota, the number of contacts to be deleted is calculated by subtracting the quota from the number of registered terminals and adding new contacts. Rule one is health checkup timeout eviction, which includes initializing the container iterator, traversing all contacts, checking if the timeout counter is greater than 1, and finally deleting unreachable terminals and publishing a deregistration event. Rule two is that if the number of contacts to be deleted is still greater than 0, contacts are sorted in ascending order of expiration time, and the contact closest to expiration is deleted, repeating until the number of contacts to be deleted is zero. After rules one and two, new contacts are written to the location service (carrying the OnSite attribute, device tag, and setting the expiration time), and a 200 OK response is constructed (containing the contact header of all valid contacts).

[0059] The fifth step is the registration event RPC linkage, which sends a registration success event to the upper-layer security system and returns a 200 OK response to the terminal. At this point, the registration process is complete.

[0060] See Figure 2 This is a timing diagram of the REGISTER request inbound and serialization scheduling. After the PJSIP receiver and distributor receives the SIP REGISTER request from the SIP terminal, it performs endpoint identification and AoR lookup, and routes the SIP REGISTER request to the AoR serializer. The AoR serializer will parse 20+ custom SIP header fields (SourceAddr, Device-Mark, OnSiteUUID, Linkus Type, etc.).

[0061] See Figure 3The sequence diagram for the five-layer cascaded security guard is as follows: After the AoR serializer submits a security verification request to the five-layer cascaded security verification pipeline, the pipeline first performs a first-layer registration permission bitmap verification using a 5-bit terminal bitmap and a 2-bit general bitmap. For requests carrying the OnSiteUUID, the pipeline sends a detected OnSite proxy request to the OnSite penetration module. The OnSite penetration module performs six-tuple parsing to obtain the UUID, terminal private network address, transport protocol, proxy public network address, and registered username. For non-OnSite proxy requests, four layers of verification are performed: second-layer remote registration blocking, third-layer IP address range restriction, fifth-layer transport protocol consistency comparison, and fourth-layer UA whitelist filtering (only for non-self-developed terminals; self-developed terminals are automatically exempt). All four layers must pass before further processing can proceed. For OnSite proxy requests, only the fourth-layer UA whitelist filtering (only for non-self-developed terminals; self-developed terminals are automatically exempt) is performed. If any layer of verification fails, the five-layer cascaded security verification pipeline will send a verification failure message to the AoR serializer. Then, the AoR serializer will send a registration failure event to the RPC security linkage module. If it is an OnSite proxy request, the event reporting will be automatically suppressed. If it is a direct connection request, the event will be reported and the source IP will be carried.

[0062] See Figure 4 This is the timing diagram for terminal type-aware quota control. The AoR serializer passes the terminal type and device tag to the terminal quota controller. The terminal quota controller parses the terminal type enumeration value from the Contact URI, iterates through the AoR registered contacts, and if the same type + same device tag is matched, the old contact is deleted and replaced with a duplicate. If a mutually exclusive terminal type is detected, all contacts of the mutually exclusive type are deleted. The location service returns the current type count to the terminal quota controller.

[0063] See Figure 5 The sequence diagram for contact lookup and same-address eviction involves the AoR serializer sending a contact lookup request to the OnSite penetration module. The OnSite penetration module then sends matching requests to the location service for exact triple matching in OnSite proxy scenarios, SourceAddr real address matching in SBC / FQDN scenarios, and standard PJSIP URI comparison in direct connection scenarios. The OnSite penetration module receives the contact matching results returned by the location service. The AoR serializer also sends multi-source same-address eviction requests to the contact conflict resolver. The contact conflict resolver then performs eviction based on triple formatting matching from the OnSite source, prefix matching from the SBC source, and URI extraction matching from the direct connection source.

[0064] See Figure 6The sequence diagram for the pre-eviction of unreachable terminals is as follows: the AoR serializer triggers the contact conflict resolver to perform a pre-eviction check. The contact conflict resolver then performs the pre-eviction according to two rules: the first rule is to traverse all contacts, check if the timeoutcount is greater than 1, and delete the unreachable terminal; the second rule is to eviction the most recently expired contact in ascending order of expiration time.

[0065] See Figure 7 The AoR serializer writes a sequence diagram for the contact and event notification, writes the new contact to the location service with the OnSite attribute, device tag, and expiration time, then builds a 200 OK response and sends a registration success event to the RPC security linkage module.

[0066] Compared with existing traditional SIP registration processing schemes, the present invention has the following significant differences and beneficial technical effects: Benefit 1: Registration security protection is upgraded from one dimension to five dimensions, building a defense-in-depth system.

[0067] Traditional solutions typically rely solely on SIP digest authentication. This invention employs a five-layer cascaded pipeline—registration permission bitmap verification, remote registration blocking, IP address range restriction, terminal identifier filtering, and transport protocol consistency verification—to achieve comprehensive, in-depth defense from the account permission layer, network layer, transport layer, and application layer. Each layer operates decoupled and uses a cascaded short-circuit detection mechanism—failure at any layer results in a 403 response terminating subsequent verifications, minimizing processing latency for legitimate registrations while ensuring security. Layers two, three, and five all support automatic bypassing of the OnSite proxy, achieving graceful compatibility between security policies and proxy deployment.

[0068] Benefit 2: Refined quota management based on terminal type eliminates resource waste and routing conflicts.

[0069] Traditional solutions apply indiscriminate quota limits to all contacts within the same AoR, failing to differentiate between terminal types and mutual exclusion relationships. This invention employs a four-pronged approach: terminal type enumeration and parsing, independent quota thresholds for each type, bitwise or cascading expulsion of mutually exclusive types, and case-insensitive deduplication of device tags. This precisely controls the maximum number of registered terminals for each type and automatically handles mutual exclusion conflicts between desktop and web desktop clients, fundamentally eliminating contact backlog, quota waste, and call routing to residual terminals.

[0070] Benefit 3: The OnSite proxy penetration mechanism solves the industry problem of distorted contact identification in proxy scenarios.

[0071] Traditional solutions rely entirely on SIP Contact URIs or request source IPs to identify contacts. In proxy deployment mode, all terminal source addresses become proxy addresses, rendering the identification mechanism completely ineffective. This invention employs a three-pronged approach: custom header field resolution with six tuples, precise matching of triples (public IP address + private IP address + username), and intelligent bypassing at three security layers. This allows for accurate identification, deduplication, and management of each terminal's independent registration status even in proxy scenarios. Simultaneously, an RPC event suppression mechanism prevents misjudgments by upper-layer security systems caused by proxy addresses.

[0072] Benefit 4: The dual-rule cascading pre-eviction mechanism proactively removes zombie contacts, improving quota utilization and communication quality.

[0073] Traditional solutions passively wait for contacts to expire naturally, resulting in unreachable terminals continuously occupying quotas and being incorrectly routed before expiration. This invention, upon triggering a quota check during new registration, prioritizes eviction of unreachable terminals with a health probe timeout counter greater than 1 (Rule 1), followed by eviction of low-value contacts closest to their expiration time (Rule 2). This dual-rule cascading strategy proactively releases quota space, effectively shortening the dwell time of dormant contacts and improving call connection rates and communication service quality.

[0074] Building upon the five-layer cascaded security defense, a terminal reputation scoring mechanism can be introduced. The system calculates a dynamic reputation score based on the terminal's historical registration behavior (including registration frequency, number of authentication failures, distribution of abnormal times, and stability of registration intervals). Terminals with high reputation scores (such as office phones with long-term stable registration) can be marked as "trusted terminals" and skip some low-risk verification layers (such as User-Agent filtering and transmission protocol verification) to reduce processing latency; terminals with low reputation scores trigger additional verification challenges (such as CAPTCHA voice interaction verification) or registration rate limiting policies (such as allowing a maximum of N registration attempts per minute). This approach further optimizes the registration experience for highly trusted terminals while maintaining security.

[0075] When quotas reach their limit and eviction is necessary, in addition to the dual-rule cascading strategy described in this invention, a comprehensive scoring eviction strategy based on multi-dimensional weights can be introduced. A comprehensive value score is calculated for each contact, with evaluation dimensions including: the time since the last successful call (reflecting activity level), OPTIONS round-trip time (RTT) (reflecting network quality), remaining registration validity period (reflecting timeliness), terminal type priority weight (e.g., mobile devices can be set to high priority), and device online duration. The contact with the lowest comprehensive score is selected for eviction, achieving a more refined contact value assessment and intelligent removal than simply sorting by expiration time. This is particularly suitable for complex scenarios in enterprise deployments with diverse terminal types and significant differences in usage patterns.

[0076] The serialization task processor and security guard engine architecture of this invention can be scaled to multi-node cluster deployments. AoR is mapped to a specific master node for processing via distributed consistent hashing, and contact status changes are synchronized to standby nodes using asynchronous message queues. When the master node fails, the standby node takes over registration and management based on replicated contact status and security policy configurations. Layer 5 security policy configurations are uniformly distributed and synchronized in real time through a centralized configuration center, ensuring consistency of security policies across the entire cluster. This scalability approach is particularly suitable for high-availability deployments at the enterprise and carrier levels.

[0077] Secondly, embodiments of this application provide a SIP terminal inbound registration and control device, the device comprising: The receiving module is used to receive SIP inbound registration requests and route the SIP inbound registration requests to the AoR serialization task processor for serial execution. The verification module is used to perform registration permission bitmap verification on SIP inbound registration requests. After passing the verification, it determines whether the SIP inbound registration request is an OnSite proxy request. If not, it verifies the source IP address, terminal identifier, and transmission protocol type of the SIP inbound registration request. If yes, it verifies the terminal identifier of the SIP inbound registration request. Based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals. The first contact deletion module is used to remove duplicates from old contacts of the same type and on the same terminal, and to delete contacts on mutually exclusive terminal types. The second contact deletion module is used to find registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, it extracts the registered username, terminal private network address and port, and proxy public network address and port as the address to be matched, and removes old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, it extracts the source IP address as the address to be matched, and removes old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, it extracts the host address and port portion as the address to be matched, and removes old contacts with the same address. The third contact deletion module is used to calculate the number of contacts to be deleted if the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota. When the OPTIONS health detection timeout counter of a non-self-developed terminal is greater than a preset value, the corresponding contacts of the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, the contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met.

[0078] In one possible implementation, the verification module is specifically used for: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check whether the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration. The terminal identifier verification for the SIP inbound registration request includes: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

[0079] In one possible implementation, the device further includes an event reporting module, specifically used for: If the SIP inbound registration request is an OnSite proxy request, automatically suppress the reporting of registration failure events; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally.

[0080] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described SIP terminal inbound registration and control methods.

[0081] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0082] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0083] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are described simply because they are similar to the method embodiments; relevant parts can be referred to the descriptions of the method embodiments.

[0084] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for controlling the inbound registration of SIP terminals, characterized in that, The method includes: Receive SIP inbound registration requests and route them to the AoR serialization task processor for serial execution; The SIP inbound registration request is validated using a registration permission bitmap. If the validation passes, it is determined whether the SIP inbound registration request is an OnSite proxy request. If not, the source IP address, terminal identifier, and transport protocol type of the SIP inbound registration request are validated. If yes, the terminal identifier of the SIP inbound registration request is validated. Based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals. Remove duplicates from existing contacts of the same type and on the same device, and delete contacts on mutually exclusive device types. Find registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, extract the registered username, terminal private network address and port, and proxy public network address and port as the address to be matched, and remove old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, extract the source IP address as the address to be matched, and remove old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, extract the host address and port portion as the address to be matched, and remove old contacts with the same address. If the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota, the number of contacts to be deleted is calculated. If the OPTIONS health detection timeout counter of the non-self-developed terminal is greater than the preset value, the contacts corresponding to the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, the contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met.

2. The method according to claim 1, characterized in that, The step of performing registration permission bitmap verification on SIP inbound registration requests includes: If the SIP inbound registration request comes from a non-self-developed terminal, the SIP inbound registration request is verified through a pre-configured general registration permission bitmap. The general registration permission bitmap has 2 bits, which control the registration permission of extensions and analog trunks respectively. If all bits of the general registration permission bitmap are 0, registration of non-self-developed terminals is prohibited. If the SIP inbound registration request comes from a self-developed terminal, perform a bitwise AND operation between the terminal type of the self-developed terminal and the pre-configured terminal registration permission bitmap. The terminal registration permission bitmap has 5 bits, which respectively control the registration permission of mobile terminal, desktop terminal, web terminal, tablet terminal and dynamic CRM terminal. If the operation result is all 0, the self-developed terminal registration is prohibited.

3. The method according to claim 1, characterized in that, The process of verifying the source IP address, terminal identifier, and transport protocol type of the SIP inbound registration request includes: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check whether the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration. The terminal identifier verification for the SIP inbound registration request includes: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

4. The method according to claim 1, characterized in that, The process of deduplicating and replacing old contacts in the same type and on the same terminal includes: Parse the custom device tag header field in the SIP inbound registration request and construct a callback data structure containing the current terminal type and device tag; Scan registered contacts under the same AoR to identify registered contacts belonging to the same terminal type as the SIP inbound registration request. Perform a case-insensitive exact comparison on the device tags of registered contacts of the same type and the SIP inbound registration request. If there is a complete match, call the location service deletion interface to remove the old contact and increment the deletion counter.

5. The method according to claim 1, characterized in that, The deletion of contacts in mutually exclusive terminal types includes: Construct a set of mutually exclusive terminals containing the terminal types to which SIP inbound registration requests belong; Perform a bitwise OR operation on mutually exclusive terminal types to generate a judgment mask; Perform a bitwise AND operation between the terminal type of the registered contacts under the same AoR and the judgment mask. If the result is not 0, delete the corresponding registered contacts.

6. The method according to claim 1, characterized in that, The method further includes: If the SIP inbound registration request is an OnSite proxy request, automatically suppress the reporting of registration failure events; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally.

7. A SIP terminal inbound registration and control device, characterized in that, The device includes: The receiving module is used to receive SIP inbound registration requests and route the SIP inbound registration requests to the AoR serialization task processor for serial execution. The verification module is used to perform registration permission bitmap verification on SIP inbound registration requests. After passing the verification, it determines whether the SIP inbound registration request is an OnSite proxy request. If not, it verifies the source IP address, terminal identifier, and transmission protocol type of the SIP inbound registration request. If yes, it verifies the terminal identifier of the SIP inbound registration request. Based on the terminal identifier carried in the SIP inbound registration request, the terminal is distinguished into self-developed terminals and non-self-developed terminals, and a general device quota limit is pre-configured for non-self-developed terminals. The first contact deletion module is used to remove duplicates from old contacts of the same type and on the same terminal, and to delete contacts on mutually exclusive terminal types. The second contact deletion module is used to find registered contacts under the same AoR. If the SIP inbound registration request is an OnSite proxy request, it extracts the registered username, terminal private network address and port, and proxy public network address and port as the address to be matched, and removes old contacts under the same proxy and terminal. If the SIP inbound registration request is an SBC / FQND proxy request, it extracts the source IP address as the address to be matched, and removes old contacts under the same terminal. If the SIP inbound registration request is a direct connection request, it extracts the host address and port portion as the address to be matched, and removes old contacts with the same address. The third contact deletion module is used to calculate the number of contacts to be deleted if the number of contacts on a non-self-developed terminal reaches the upper limit of the general device quota. When the OPTIONS health detection timeout counter of a non-self-developed terminal is greater than a preset value, the corresponding contacts of the non-self-developed terminal are deleted. If the number of contacts to be deleted is still not met after deletion, the contacts are deleted one by one in order of expiration time until the number of contacts to be deleted is met.

8. The apparatus according to claim 7, characterized in that, The verification module is specifically used for: Obtain the primary and secondary network interface card (NIC) IP addresses of the SIP registration server. Combine the primary and secondary NIC IP addresses with the pre-configured subnet mask to calculate the network segment range. If the source address of the SIP inbound registration request falls within the network segment range, allow it. Perform a matching operation between the source address and the preset IP license list. If a match is found, check whether the terminal identifier of the non-self-developed terminal matches the terminal identifier prefix whitelist. If a match is found, obtain the transmission parameters used in the SIP inbound registration request and compare them with the pre-configured transmission protocol type. If they do not match, refuse registration. The terminal identifier verification for the SIP inbound registration request includes: For non-self-developed terminals, the system checks whether the terminal identifier matches the terminal identifier prefix whitelist; if not, registration is rejected.

9. The apparatus according to claim 7, characterized in that, The device also includes an event reporting module, specifically used for: If the SIP inbound registration request is an OnSite proxy request, automatically suppress the reporting of registration failure events; If the SIP inbound registration request is not an OnSite proxy request, a registration failure event should be reported normally.

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 method described in any one of claims 1-6.

Images