A method and system for gsm signaling for unmanned convenience store monitoring system

Abstract

The application relates to a national standard signaling method and system for an unmanned convenience store monitoring system, wherein a signaling gateway service receives a user HTTP request, converts the request into a standard SIP signaling and forwards the request to a signaling server; the signaling server analyzes signaling priorities, adds the signaling to a corresponding processing queue according to rules, and after the signaling client analyzes the signaling, adaptively selects a transmission protocol according to the characteristics of a monitoring device, generates a device control instruction with a traceable ID and sends the instruction to the monitoring device; the monitoring device executes an operation to generate response data with a traceable ID and feeds back the data to the signaling client; the signaling client generates a SIP response signaling with the traceable ID and feeds back the signaling to the signaling server; the signaling server forwards the response signaling to the gateway, the gateway converts the response signaling into an HTTP response and returns the response to the user, and meanwhile, stores full-link logs associated with the traceable ID. The application realizes signaling standardization, priority scheduling and full-link traceability, improves system compatibility, response efficiency, operation convenience and safety, and adapts to cross-platform collaboration requirements.

Description

Technical Field

[0001] This invention belongs to the field of unmanned convenience store monitoring technology, and in particular relates to a national standard signaling method and system for unmanned convenience store monitoring systems. Background Technology

[0002] With the rapid development of new retail formats, unmanned convenience stores have become an important direction for the digital transformation of the retail industry due to their advantages such as 24-hour operation, low labor costs, and high space utilization. As the core supporting module of unmanned convenience stores, the monitoring system needs to realize functions such as tracking personnel movement, protecting merchandise security, monitoring equipment status, and issuing early warnings of abnormal behavior. The transmission, processing, and management of signaling are the key technological foundations for ensuring the efficient operation of the monitoring system.

[0003] Currently, the signaling interaction of unmanned convenience store monitoring systems mainly relies on traditional non-standard protocols or general communication protocols, which exposes several technical bottlenecks in practical applications. Specific problems are as follows:

[0004] I. There is no unified standard for signaling interaction, resulting in poor compatibility and scalability:

[0005] Existing unmanned convenience store monitoring systems mostly use proprietary signaling protocols defined by equipment manufacturers. There is a lack of unified signaling formats and interaction rules between monitoring devices such as cameras and AI analysis boxes from different brands. For example, some manufacturers encapsulate real-time video call signaling in binary format, while others encapsulate anomaly warning signaling in XML format. This necessitates the development of numerous protocol conversion interfaces when multiple devices are working collaboratively, increasing system development and maintenance costs and making them prone to failures such as signaling parsing failures and data loss due to interface compatibility issues. Furthermore, when adding monitoring equipment to an unmanned convenience store, the signaling interaction logic must be redesigned, resulting in extremely poor system scalability and making it difficult to meet the rapid iteration needs of stores.

[0006] II. Lack of signaling priority scheduling, resulting in delayed response to critical monitoring requirements:

[0007] The signaling types in unmanned convenience store monitoring systems are diverse, with different signals corresponding to varying real-time requirements. For example, signals such as abnormal merchandise theft alerts and device offline alarms require millisecond-level responses to avoid property loss or system paralysis; signals such as historical video playback queries and device parameter configurations have lower real-time requirements. However, existing systems lack a signaling priority scheduling mechanism, and all signals are processed using a first-in-first-out queue mode. This results in high-priority signals being blocked by low-priority signals. For instance, during peak periods when a large number of playback query signals are queued, abnormal alert signals cannot be processed in a timely manner, missing the optimal intervention opportunity and increasing the security risks and operational losses of unmanned convenience stores.

[0008] 3. Insufficient traceability across the entire signaling chain, resulting in low efficiency in fault diagnosis:

[0009] The signaling interaction of the unmanned convenience store monitoring system involves multiple stages: user request, gateway conversion, server distribution, client execution, and device response. An anomaly in any stage can cause monitoring failure, such as real-time video buffering or failure to push alerts. However, the existing system lacks a signaling traceability mechanism: firstly, signaling does not carry a unique identifier during transmission, making it impossible to associate request-processing-response data across the entire chain. When signaling is lost or parsed incorrectly, it's impossible to pinpoint the stage where the anomaly occurred, such as gateway conversion failure or server distribution timeout. Secondly, signaling logs only record data from certain stages, such as only storing server-side reception logs and lacking client execution logs. Furthermore, the log formats are inconsistent, requiring data retrieval across multiple modules during troubleshooting, with an average troubleshooting time exceeding two hours, severely impacting system maintenance efficiency.

[0010] IV. Insufficient security and reliability of signaling transmission, resulting in a high risk of data leakage and loss:

[0011] The monitoring data from unmanned convenience stores includes sensitive information such as staff portraits, product displays, and consumer behavior. Signaling transmission must ensure data confidentiality and integrity. Simultaneously, the monitoring system needs to operate continuously 24 / 7, requiring signaling transmission to withstand network fluctuations. Existing systems have significant security and reliability shortcomings: First, signaling is often transmitted in plaintext or with weak encryption, making it vulnerable to illegal interception and parsing, posing a risk of sensitive data leakage. Second, transmission protocols are not adapted to the communication characteristics of different devices. Third, there is a lack of self-healing mechanisms for link failures; when the main transmission channel is interrupted, it cannot automatically switch to a backup channel, leading to signaling transmission interruption and monitoring function paralysis.

[0012] V. Poor compatibility with industry standards, making cross-platform collaboration difficult:

[0013] With the integration of smart cities and security systems, unmanned convenience store monitoring systems need to achieve data interoperability with third-party platforms such as the Skynet platform and chain brand cloud monitoring centers. However, the existing system signaling does not comply with relevant communication and security standards, requiring third-party platforms to customize and develop compatible interfaces to receive signaling data. This not only increases platform integration costs but also poses compliance risks during cross-platform data collaboration due to non-standard signaling formats that do not meet data compliance requirements, making it difficult to integrate into a unified urban security and retail supervision system.

[0014] In summary, current unmanned convenience store monitoring systems have significant technical deficiencies in signaling standards, priority scheduling, traceability mechanisms, security and reliability, and industry adaptability. There is an urgent need to improve existing signaling methods to address these technical pain points and ensure the stable, secure, and efficient operation of unmanned convenience store monitoring systems. Summary of the Invention

[0015] The purpose of this invention is to provide a national standard signaling method and system for unmanned convenience store monitoring systems, in order to solve the technical problems existing in current unmanned convenience store monitoring systems in terms of signaling standards, priority scheduling, traceability mechanisms, security and reliability, and industry adaptability.

[0016] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0017] Firstly, a national standard signaling method for monitoring systems in unmanned convenience stores is provided, including the following steps:

[0018] S1: The signaling gateway service receives HTTP requests initiated by users, converts them into standard SIP signaling with priority identifiers, embeds a unique signaling traceability ID, and then forwards them to the signaling server.

[0019] S2: The signaling server receives SIP signaling and parses the header field to obtain its priority. According to the preset scheduling rules, it adds the SIP signaling to the corresponding priority processing queue.

[0020] S3: The signaling server extracts SIP signaling from the priority processing queue, queries the preset device registry to match the corresponding signaling client, and verifies the connection status between the signaling client and the monitoring device;

[0021] S4: If the connection is normal, the signaling server will send SIP signaling to the matching signaling client and record the signaling distribution log; if the connection is abnormal, the disconnection reconnection mechanism will be triggered.

[0022] S5: After receiving SIP signaling, the signaling client parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol according to the communication characteristics of the monitoring equipment, and generates device control instructions with traceability ID;

[0023] S6: The signaling client sends the device control command to the monitoring device. After the monitoring device performs the operation, it generates response data and sends it back to the signaling client, carrying the traceability ID in the response data.

[0024] S7: After receiving the response data, the signaling client generates a SIP response signaling containing the source ID and sends it back to the signaling server;

[0025] S8: The signaling server records the signaling response log and forwards the SIP response signaling to the signaling gateway service; the signaling gateway service converts the SIP response signaling into an HTTP response and returns it to the user, while storing the signaling interaction full-link log with the source ID in the database.

[0026] Preferably, the specific process of step S1 is as follows:

[0027] S11: The signaling gateway service receives HTTP requests initiated by users, including monitoring operation instructions, target device identifier (deviceId), and request priority identifier;

[0028] S12: The signaling gateway service converts HTTP requests into standard SIP signaling according to preset field mapping rules;

[0029] S13: Generate a unique signaling traceability ID and forward the SIP signaling with the traceability ID and priority tag to the signaling server.

[0030] Preferably, the specific process of step S2 is as follows:

[0031] S21: The signaling server receives SIP signaling carrying a unique signaling traceability ID and a custom priority header field X-Signaling-Priority through a preset SIP protocol port;

[0032] S22: Perform basic format verification on the received SIP signaling, extract the Call-ID, From, and To fields from the signaling header field, match them with the preset whitelist of the signaling gateway service, and exclude illegal signaling;

[0033] S23: After the verification is successful, the signaling server traverses the header field list of SIP signaling, locates the custom priority header field X-Signaling-Priority, and reads the field value of the X-Signaling-Priority header field;

[0034] S24: The signaling server performs priority mapping based on the parsed X-Signaling-Priority field value;

[0035] S25: The signaling server adds the SIP signaling after priority determination to the corresponding priority processing queue according to the rule of prioritizing high priority and sorting the same priority by reception time.

[0036] Preferably, in step S3, the signaling server extracts SIP signaling from the priority processing queue and queries the preset device registry to match the corresponding signaling client. The specific process is as follows:

[0037] S31: The signaling server calls the queue scheduling module to schedule the three independent priority processing queues (high, medium, and low) according to the rule that high-priority signaling is processed first and signaling of the same priority is sorted by reception time.

[0038] S32: The signaling server uses the temporarily stored deviceId as the search keyword to query the preset distributed device registry;

[0039] Perform deviceId matching. If a unique associated record is found, extract the core data from that record, including the signaling client ID, device IP, communication protocol type, and list of supported functions.

[0040] Preferably, the specific process for verifying the connection status between the signaling client and the monitoring device in step S3 is as follows:

[0041] Based on the signaling client ID extracted from the device registry, the signaling server queries the real-time online status of the signaling client through a heartbeat detection mechanism: the signaling client sends a heartbeat packet containing the client ID, device connection status code, and source ID at specified time intervals, and the server updates the signaling client status cache pool in real time; if the heartbeat interval does not exceed the preset timeout threshold, the status is determined to be online, and the signaling client is confirmed as a matching target; if the heartbeat interval exceeds the timeout threshold, the status is determined to be offline.

[0042] Preferably, the specific process by which the signaling server sends SIP signaling to the matching signaling client in step S4 is as follows:

[0043] S41: After determining the matching signaling client, the signaling server verifies the integrity of the SIP signaling to be sent again, and verifies the logical consistency between the message body and the header field. After all verifications are successful, step S42 is executed.

[0044] S42: Determine the delivery strategy based on signaling priority and the communication characteristics of the signaling client;

[0045] S43: The signaling server calls the protocol adaptation module to encapsulate the SIP signaling according to the signaling client communication protocol recorded in the device registry.

[0046] If it is a TCP protocol, the SIP signaling is encapsulated in TCP byte stream format and a message length prefix is ​​added to ensure that the signaling client can parse it completely;

[0047] If it is a UDP protocol, the SIP signaling is encapsulated in the UDP datagram format, and the signaling exceeding the MTU is split into multiple fragments. Each fragment is given a fragment sequence number and a total fragment count identifier.

[0048] S44: Transmit encapsulated SIP signaling through an encrypted channel. The encryption key is a session key generated by the signaling server and the signaling client through a specified key negotiation protocol during connection initialization.

[0049] S45: The signaling server sends encapsulated SIP signaling through the IP address and port of the signaling client, and simultaneously starts link monitoring: monitors the network latency and packet loss rate of the transmission link in real time, and if the corresponding threshold is exceeded, it temporarily switches to the backup transmission channel.

[0050] Preferably, in step S5, after the signaling client receives the SIP signaling, it parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol according to the communication characteristics of the monitoring device, and generates device control instructions with traceability IDs. The specific process is as follows:

[0051] S51: The signaling client receives SIP signaling from the signaling server through a preset port, and decrypts the signaling using an algorithm negotiated with the signaling server to obtain the original SIP signaling content.

[0052] S52: The signaling client verifies the structural integrity of the SIP signaling, extracts the signaling source ID from the signaling header field, and verifies consistency by calculating the overall hash value of the SIP signaling. If all these steps pass, proceed to step S53.

[0053] S53: The signaling client parses the message body of the SIP signaling, extracts the core operation instructions, and reads the signaling source ID in the signaling header field, binds the two and stores them in the local cache;

[0054] S54: The signaling client reads the device type identifier configured locally to determine the type of the currently associated monitoring device;

[0055] Select the protocol according to the preset device type-transmission protocol mapping rules:

[0056] If the device type is CAM, the default protocol is TCP; if the device type is AIBOX, the default protocol is UDP.

[0057] S55: The signaling client calls the corresponding instruction generation module according to the type of operation instruction to convert the abstract operation instruction in SIP signaling into a specific control instruction that the monitoring device can directly execute: for real-time video on demand instructions, generate RTSP protocol PLAY instructions; for AI anomaly detection instructions, generate custom binary instructions; and forcibly embed the signaling traceability ID in the generated device control instructions.

[0058] S56: Encapsulate the control command with traceability ID at the protocol layer according to the selected transmission protocol:

[0059] TCP encapsulation: Add a 4-byte length prefix and organize according to byte stream format;

[0060] UDP encapsulation: If the instruction length exceeds the MTU, it is split in the format of fragment sequence number + total number of fragments + source ID + fragment data.

[0061] Preferably, the specific process by which the signaling client sends the device control command to the monitoring device in step S6, and the monitoring device generates response data after performing the operation, is as follows:

[0062] S61: After receiving the control command, the monitoring device parses and extracts the embedded traceability ID, and verifies the legitimacy of the command source by comparing it with the locally stored signaling client whitelist.

[0063] S62: The monitoring equipment executes the corresponding operation according to the instruction type, and records key nodes in real time during the process;

[0064] S63: After the monitoring device performs the operation, it generates response data in a preset format and forcibly embeds the traceability ID;

[0065] S64: The monitoring device sends response data back to the signaling client using the same transmission protocol as the received instruction.

[0066] Preferably, the specific process of generating SIP response signaling containing the source ID after the signaling client receives the response data in step S7 is as follows:

[0067] S71: After receiving the response data from the monitoring device, the signaling client performs an integrity check according to the transmission protocol type;

[0068] S72: Extract the traceability ID embedded in the monitoring device from the response data and compare it with the locally cached instruction-traceability ID mapping table:

[0069] If they match, confirm the correlation between the response data and the original control command, and proceed to the next step of processing;

[0070] If they are inconsistent, a source ID mismatch error log is generated, and an error message with the correct source ID is sent to the signaling server.

[0071] S73: The signaling client calls the corresponding parsing module based on the original format of the response data to extract the relevant core business fields;

[0072] S74: Map the extracted core business fields to a standardized signaling structure.

[0073] Secondly, a national standard signaling system for monitoring unmanned convenience stores is provided, including a signaling gateway service (sip-gateway), a signaling server (sip-server), a signaling client (sip-client), monitoring equipment, and a database;

[0074] The signaling gateway service module sip-gateway is used to receive HTTP requests initiated by users, convert the HTTP requests into standard SIP signaling with priority identifiers according to preset field mapping rules, embed a unique signaling traceability ID, and then forward it to the signaling server module.

[0075] The signaling server (sip-server) communicates with the sip-gateway. It receives SIP signaling, parses the header fields to obtain the priority, and adds the SIP signaling to the corresponding priority processing queue according to preset scheduling rules. It then extracts SIP signaling from the priority processing queue, queries the preset device registry to match the corresponding signaling client (sip-client), and verifies the connection status between the sip-client and the monitoring device. It also records signaling response logs and forwards SIP response signaling to the sip-gateway.

[0076] The signaling client (sip-client) communicates with the sip-server and monitoring equipment. It receives SIP signaling, parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol according to the communication characteristics of the monitoring equipment, generates device control instructions with traceability IDs, sends the device control instructions to the monitoring equipment, receives the response data generated by the monitoring equipment after it performs the operation, generates SIP response signaling with traceability IDs, and feeds it back to the sip-server.

[0077] The monitoring equipment, selected from cameras, access control systems, and AI analysis boxes, communicates with the signaling client module to receive device control commands and execute corresponding operations, generate response data and carry traceability IDs in the response data, and feed the response data back to the signaling client module;

[0078] The database, connected to the SIP-gateway, is used for the entire chain of associated traceability ID storage, signaling interaction, and daily communication.

[0079] Logs, the entire link log includes request logs, transformation logs, scheduling logs, distribution logs, and response logs.

[0080] The beneficial effects of this invention include:

[0081] 1. By converting user HTTP requests into standard SI signaling through the signaling gateway service and maintaining a consistent signaling format throughout the entire link, the proprietary protocol barriers between different brands of monitoring equipment are broken down. On the one hand, this enables multiple types of devices to work collaboratively based on a unified signaling format, reducing the development cost of protocol conversion interfaces and improving device access compatibility. On the other hand, when new monitoring devices are added to the system, they can be quickly integrated simply by following preset signaling mapping rules, significantly improving the scalability of the unmanned convenience store monitoring system and meeting the iterative needs of store business.

[0082] 2. By embedding priority identifiers in SIP signaling and adopting a scheduling rule of prioritizing high-priority signals and sorting signals of the same priority by time, signaling with different real-time requirements is processed differently. For example, critical signaling such as AI anomaly warnings can skip the low-priority replay query signaling queue and directly enter the processing flow, reducing response latency significantly compared to the traditional first-in-first-out (FIFO) mode. Operations with lower real-time requirements are queued in an orderly manner to avoid consuming critical resources. This mechanism ensures that emergency events such as safety warnings and equipment failures in unmanned convenience stores are handled promptly, reducing operational risks.

[0083] 3. This invention embeds a unique traceability ID during the signaling generation stage and associates this ID with log records throughout the entire process of request-transformation-scheduling-distribution-execution-response, forming a complete signaling trajectory chain. When the system experiences anomalies such as video stream interruption or command execution failure, maintenance personnel can retrieve the entire link log with a single click using the traceability ID, quickly locating the point where the anomaly occurred. This significantly reduces the average troubleshooting time and greatly improves system maintenance efficiency.

[0084] 4. The system adaptively selects the TCP / UDP protocol based on the communication characteristics of different monitoring devices and encrypts the transmission channel using national cryptographic algorithms to ensure the confidentiality and integrity of signaling data, reducing the risk of sensitive information leakage. Simultaneously, through link monitoring and backup channel switching mechanisms, the system automatically switches to the backup channel when the main transmission link experiences high latency or packet loss, improving the signaling transmission success rate and ensuring the stable operation of the unmanned convenience store monitoring system. Attached Figure Description

[0085] Figure 1 This is a flowchart illustrating a national standard signaling method for a monitoring system of unmanned convenience stores according to the present invention.

[0086] Figure 2 This is a schematic diagram of the architecture of a national standard signaling system for monitoring unmanned convenience stores according to the present invention. Detailed Implementation

[0087] The following is in conjunction with the appendix Figures 1-2 The present invention will be further described in detail below:

[0088] Example 1

[0089] See appendix Figure 1 As shown, a national standard signaling method for a monitoring system of unmanned convenience stores includes the following steps:

[0090] S1: The signaling gateway service receives HTTP requests initiated by users and converts them into standard SIP signaling with priority identifiers according to preset field mapping rules. During the conversion process, the transactionId (unique request ID) is defined and sent together with the X-Trace-ID to prevent duplicate execution and add a mechanism to prevent request replay, such as timestamp + signature. After embedding the unique signaling traceability ID, it is forwarded to the signaling server.

[0091] S2: The signaling server receives SIP signaling and parses the header field to obtain its priority. According to the preset scheduling rules, it adds the SIP signaling to the corresponding priority processing queue.

[0092] S3: The signaling server extracts SIP signaling from the priority processing queue, queries the preset device registry to match the corresponding signaling client, and verifies the connection status between the signaling client and the monitoring device through a heartbeat detection mechanism. In the heartbeat detection mechanism, the signaling client sends a heartbeat packet containing the client ID, device connection status code, and traceability ID every 5-30 seconds. The monitoring devices include cameras, AI analysis boxes, etc.

[0093] S4: If the connection is normal, the signaling server will send SIP signaling to the matching signaling client and record the signaling distribution log;

[0094] If a connection error occurs, the disconnection and reconnection mechanism will be triggered, and the reconnection result will be fed back to the signaling client.

[0095] S5: After receiving SIP signaling, the signaling client parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol based on the communication characteristics of the monitoring equipment, and generates device control instructions with traceability IDs. In the monitoring equipment, the camera supports the TCP protocol, and the AI ​​analysis box supports the UDP protocol.

[0096] S6: The signaling client sends the device control command to the monitoring device. After the monitoring device performs the operation, it generates response data and feeds it back to the signaling client. The response data includes the RTSP address, device status information, playback history list, AI anomaly analysis results, and carries the traceability ID in the response data.

[0097] S7: After receiving the response data, the signaling client generates a SIP response signaling containing the source ID and sends it back to the signaling server.

[0098] S8: The signaling server records signaling response logs including the source ID, response time, and response result, and forwards the SIP response signaling to the signaling gateway service. The signaling gateway service converts the SIP response signaling into an HTTP response with the source ID and response log summary embedded and returns it to the user. At the same time, it stores the full-link signaling interaction logs, including request logs, transformation logs, scheduling logs, distribution logs, and response logs, along with the source ID, in the database.

[0099] In this embodiment, the specific process of step S1 is as follows:

[0100] S11: The signaling gateway service receives HTTP requests initiated by users, including monitoring operation instructions, target device identifier (deviceId), and request priority identifier. Monitoring operation instructions include real-time video on demand, video playback on demand, device information query, device status query, playback history record retrieval, playback speed adjustment, playback pause / resume, playback drag, video recording download, and AI anomaly alert.

[0101] The request priority indicators include high, medium, and low. AI anomaly warnings are marked as high priority by default, real-time video on demand is marked as medium priority, and playback-related operations are marked as low priority.

[0102] S12: The signaling gateway service converts HTTP requests into SIP signaling conforming to the GB / T28181 standard according to the preset field mapping rules, namely, mapping the target device identifier deviceId of the HTTP request to the SIP signaling To header field, mapping the operation instruction to the SIP message body parameter, and mapping the priority identifier to the custom header field X-Signaling-Priority.

[0103] S13: Generate a unique signaling traceability ID in the format GW-[Gateway IP]-[Timestamp]-[Random 6-character string], embed it in the SIP signaling header field, and then forward the SIP signaling with the traceability ID and priority marker to the signaling server.

[0104] In another embodiment of this example, a ZLM service, namely ZLMediaKit (commonly referred to as ZLM), is also provided. ZLM is an open-source, high-performance streaming media server primarily focused on the real-time transmission, forwarding, and management of video and audio streams. It includes a local ZLM and a cloud ZLM. The local ZLM mainly handles historical video storage and internal streaming. The remote ZLM provides streaming services to external platforms.

[0105] Example 2

[0106] Based on Example 1, the specific process of step S2 is as follows:

[0107] S21: The signaling server receives SIP signaling forwarded by the signaling gateway service through a preset SIP protocol port, which is 5060 / TCP by default and supports 5061 / TLS encrypted port. This signaling carries a unique signaling source ID and a custom priority header field X-Signaling-Priority.

[0108] S22: The signaling server performs basic format verification on the received SIP signaling to verify whether it conforms to the standard SIP signaling structure of GB / T28181, which includes a start line, header field, message body separator, and message body. At the same time, it extracts the Call-ID, From, and To fields from the signaling header field and matches them with the whitelist of legal gateway IPs and identifiers stored in the signaling gateway service to exclude illegal signaling. If the verification fails, an illegal signaling format log with a traceability ID is generated and fed back to the signaling gateway service to terminate the subsequent process.

[0109] S23: After the verification is successful, the signaling server traverses the header field list of SIP signaling, locates the custom priority header field X-Signaling-Priority, which is mapped by the signaling gateway service from the priority identifier of the HTTP request. The server reads the field value of the X-Signaling-Priority header field, which only supports three preset enumeration values: High (high priority), Medium (medium priority), and Low (low priority).

[0110] S24: The signaling server performs priority mapping based on the parsed X-Signaling-Priority field value:

[0111] When the field value is "High", it is determined to be of high priority and corresponds to AI anomaly warning signaling.

[0112] When the field value is Medium, it is determined to be of medium priority, corresponding to real-time video-on-demand signaling;

[0113] When the field value is Low, it is determined to be of low priority, which includes playback-related signaling such as playback speed adjustment and video download.

[0114] S25: The signaling server processes SIP signaling according to the rule of prioritizing high priority and sorting by reception time for the same priority. After determining the priority, the SIP signaling is added to the corresponding priority processing queue, which includes three independent queues: high, medium and low. Each queue adopts a FIFO first-in-first-out mechanism. At the same time, it records priority scheduling logs, including storing the legitimate gateway IP and identifier, to complete the entire priority resolution process and provide scheduling basis for the subsequent device matching and connection verification process.

[0115] In step S3, the signaling server extracts SIP signaling from the priority processing queue and queries the preset device registry to match the corresponding signaling client. The specific process is as follows:

[0116] S31: The signaling server calls the queue scheduling module to schedule three independent priority processing queues (high, medium, and low) according to the rule of prioritizing high-priority signaling and sorting signaling of the same priority by reception time. It prioritizes extracting SIP signaling from the head of the high-priority queue. If there is no signaling to be processed in the high-priority queue, it extracts the signaling from the head of the medium-priority and low-priority queues in turn to ensure that key signaling such as AI anomaly warnings are given priority in processing resources.

[0117] When extracting SIP signaling, the unique signaling source ID in the signaling header field is read synchronously. The format is GW-[Gateway IP]-[Timestamp]-[Random 6-character], and a signaling extraction log is generated, including the source ID, extraction queue type, extraction time, and brief signaling identifier. The source ID is associated and stored in the signaling source database to provide a basis for anomaly tracing in the subsequent matching process. At the same time, the deviceId field in the signaling, i.e., the target monitoring device identifier, is temporarily stored as the core retrieval condition for subsequent device registry queries.

[0118] S32: The signaling server uses the temporarily stored deviceId as the search keyword to query the preset distributed device registry. This registry stores the association information between the signaling client and the monitoring device, including the signaling client ID, the monitoring device identifier deviceId, the device IP address, the communication protocol type TCP / UDP, the list of supported functions, and the online status of the signaling client.

[0119] First, perform an exact match for deviceId. If a unique associated record is found, that is, a single deviceId corresponds to a unique signaling client ID, then extract the core data such as the signaling client ID, device IP, communication protocol type, and function support list from that record, and then proceed to the subsequent status verification of the signaling client.

[0120] If an abnormal situation occurs where a single deviceId corresponds to multiple signaling client IDs due to reasons such as device registry synchronization delay, the query module automatically filters the signaling client records with the latest online status, takes the last heartbeat time field in the registry as the standard, takes the record with the latest timestamp, and generates a multi-client matching abnormal log with traceability ID, recording the number of abnormal records and the filtering criteria.

[0121] If no record matching deviceId is found, the query module generates a device unregistered log with a traceability ID and sends it to the signaling gateway service. The gateway then returns an HTTP response to the user indicating that the target device does not exist, terminating the subsequent matching process.

[0122] The specific process of verifying the connection status between the signaling client and the monitoring device through the heartbeat detection mechanism in step S3 is as follows:

[0123] Based on the signaling client ID extracted from the device registry, the signaling server uses a heartbeat detection mechanism to query the real-time online status of that signaling client: The signaling client sends a heartbeat packet containing the client ID, device connection status code, and source ID every 5-30 seconds, and the server updates the client status cache in real time. If the heartbeat interval does not exceed the preset timeout threshold (default 3 times the heartbeat period), the status is determined to be online, and the signaling client is confirmed as a matching target. If the heartbeat interval exceeds the timeout threshold, the status is determined to be offline.

[0124] Example 3

[0125] Based on Embodiment 1 or Embodiment 2, the specific process of the signaling server sending SIP signaling to the matching signaling client in step S4 is as follows:

[0126] S41: After identifying the matching signaling client, the signaling server re-verifies the integrity of the SIP signaling to be sent. It focuses on checking whether the key fields in the signaling header, including the signaling source ID, deviceId, and X-Signaling-Priority, exist and are in a valid format. At the same time, it verifies the logical consistency between the message body and the header fields, such as whether the message body of the AI ​​anomaly warning signaling contains necessary parameters such as anomaly type and time. If there are any missing or inconsistent fields, a signaling integrity verification failure log with the source ID is generated, the sending is terminated, and feedback is sent to the signaling gateway service.

[0127] S42: Obtain the signaling priority and communication characteristics of the signaling client from the TCP / UDP protocol type retrieved from the device registry, and determine the delivery strategy:

[0128] High-priority signaling, such as AI anomaly warnings, adopts an immediate delivery + confirmation mechanism, requiring the signaling client to return a receipt confirmation within 100ms;

[0129] For high-priority signaling such as real-time video on demand, an immediate delivery + timeout retransmission mechanism is adopted. If no receiving response is received within 500ms, it will be automatically retransmitted once.

[0130] Low-priority signaling such as playback dragging uses a batch delivery + delayed confirmation mechanism, which can be combined with other low-priority signaling from the same client to reduce communication overhead.

[0131] S43: The signaling server calls the protocol adaptation module to encapsulate the SIP signaling according to the signaling client communication protocol (TCP or UDP) recorded in the device registry.

[0132] If it is a TCP protocol, such as for camera devices, encapsulate the SIP signaling in TCP byte stream format and add a 4-byte message length prefix to ensure that the signaling client can completely parse it;

[0133] If it is a UDP protocol, such as an AI analysis box, the SIP signaling is encapsulated in UDP datagram format, and the signaling exceeding the default maximum transmission unit (MTU) of 1500 bytes is split into multiple fragments. Each fragment is given a fragment sequence number and a total fragment count identifier to ensure the integrity of the reassembly.

[0134] S44: Encapsulated signaling is transmitted through an encrypted channel based on the national cryptographic SM4 algorithm. The encryption key is a session key generated by the signaling server and the signaling client through the GB / T38635-2020 key negotiation protocol during the initial connection, ensuring that the signaling data is not tampered with or leaked during transmission.

[0135] S45: The signaling server sends encapsulated signaling through the IP address and port of the signaling client obtained from the device registry, and simultaneously starts link monitoring: real-time monitoring of network latency (high-priority signaling requires latency <50ms) and packet loss rate (required <0.01%) of the transmission link. If the threshold is exceeded, it temporarily switches to the backup transmission channel, such as switching to wired Ethernet when the main channel is 5G.

[0136] In this embodiment, after the signaling client receives the SIP signaling in step S5, it parses the operation instructions and traceability ID in the signaling. Based on the communication characteristics of the monitoring device (the camera supports the TCP protocol and the AI ​​analysis box supports the UDP protocol), the client adaptively selects the transmission protocol and generates device control instructions with traceability IDs. The specific process is as follows:

[0137] S51: The signaling client receives SIP signaling from the signaling server through a preset port (TCP port 5062 by default, UDP port 5063 by default), and decrypts the signaling using the national cryptographic SM4 algorithm negotiated with the signaling server to obtain the original SIP signaling content.

[0138] S52: The signaling client verifies the structural integrity of the SIP signaling, checking whether it contains header fields, message body, and delimiters. At the same time, it extracts the signaling traceability ID from the signaling header field, calculates the overall hash value of the SIP signaling using the SM3 algorithm, and compares it with the hash check value attached by the signaling server when it is sent. If they do not match, the signaling is determined to be corrupted, a signaling corruption log with traceability ID is generated, and the signaling server is notified and a retransmission is requested.

[0139] S53: After the verification is successful, the signaling client parses the message body of the SIP signaling and extracts the core operation instructions, such as the instruction code PLAY_LIVE for real-time video on demand and the instruction code DETECT_ABNORMAL for AI anomaly detection. At the same time, it reads the signaling traceability ID in the signaling header field (which is consistent with the traceability ID generated in step S1), binds the two and stores them in the local cache. The cache duration is consistent with the signaling processing cycle to ensure that they can be associated throughout the process.

[0140] S54: The signaling client reads the device type identifier configured locally. The camera is marked as CAM and the AI ​​analysis box is marked as AIBOX. This matches the classification in the device registry, and the client determines the type of the currently associated monitoring device.

[0141] Select the protocol according to the preset device type-transmission protocol mapping rules:

[0142] If the device type is CAM (camera), the default protocol is TCP, because cameras need to transmit continuous video streams, and TCP's reliable transmission characteristics can reduce video stuttering caused by packet loss.

[0143] If the device type is AIBOX (AI Analysis Box), the UDP protocol is selected by default because AI Analysis Box mainly deals with sudden early warning information, and the low latency of UDP can speed up the early warning response.

[0144] The current network packet loss rate is obtained through real-time network monitoring. If the camera detects that the current network packet loss rate is less than 0.005%, it can temporarily switch to the UDP protocol to reduce transmission latency. If the warning information sent by the AI ​​analysis box exceeds the length of the UDP MTU (1500 bytes), it will automatically switch to the TCP protocol to ensure complete transmission.

[0145] S55: The signaling client calls the corresponding instruction generation module based on the type of operation instruction to convert the abstract operation instruction in the SIP signaling into a specific control instruction that the monitoring device can directly execute.

[0146] For real-time video-on-demand commands, generate PLAY commands in the RTSP protocol, format: PLAYrtsp: / / [device IP]:554 / stream1RTSP / 1.0;

[0147] For AI anomaly detection commands, generate custom binary commands that include detection type and sensitivity parameters, such as DETECT;TYPE=THEFT;LEVEL=HIGH.

[0148] Forcefully embed the signaling traceability ID into the generated device control commands, specifically as follows:

[0149] For example, RTSP text-based instructions add the extended field X-Trace-ID:[Source ID] to the header;

[0150] The binary instruction reserves 16 bytes in the protocol header to store the traceability ID;

[0151] S56: Encapsulate control commands with traceability IDs at the protocol layer according to the transport protocol TCP or UDP.

[0152] TCP encapsulation: Add a 4-byte length prefix (to identify the total number of bytes in the instruction), and organize it according to the byte stream format;

[0153] UDP encapsulation: If the instruction length exceeds the MTU, it is split in the format of fragment sequence number + total number of fragments + traceability ID + fragment data to ensure that the integrity can be verified through the traceability ID during reassembly.

[0154] Example 4

[0155] Based on Embodiment 1, Embodiment 2, or Embodiment 3, the specific process by which the signaling client in step S6 sends the device control command to the monitoring device, and the monitoring device generates response data after executing the operation, is as follows:

[0156] S61: After receiving a control command, the monitoring device parses and extracts the embedded traceability ID. It then verifies the legitimacy of the command's source by comparing it with a locally stored signaling client whitelist, such as checking if the signaling client IP is in the authorized list.

[0157] For text-based commands, such as the PLAY command in RTSP: check if the syntax conforms to the protocol specifications, such as whether it contains the correct URL and parameters.

[0158] For binary instructions, such as AI detection instructions: CRC check is used to confirm that the instruction has not been tampered with. If the check fails, the instruction is discarded and an invalid instruction response with traceability ID is generated.

[0159] S62: The monitoring equipment executes the corresponding operation based on the instruction type, and records key nodes associated with the traceability ID in real time during the process.

[0160] Real-time video on demand: The camera starts the streaming media encoder, generates an RTSP stream according to negotiated parameters including bitrate and resolution, binds a temporary port and generates a unique stream address, such as "rtsp: / / 192.168.1.100:554 / live?traceId=xxx";

[0161] AI Anomaly Detection: Analyzes real-time video streams and records timestamps, region coordinates, and confidence levels of abnormal events;

[0162] Playback history query: The storage device retrieves a list of matching video files based on the time range parameters in the command, including the file name, start and end time, and file size.

[0163] S63: After the monitoring device performs the operation, it generates response data in a preset format and forcibly embeds the traceability ID.

[0164] RTSP address response: Encapsulated in JSON format;

[0165] AI anomaly analysis results: Encapsulated in XML format, including anomaly type, time, screenshot URL, etc.

[0166] S64: The monitoring device sends response data back to the signaling client using the same transport protocol as the received command, TCP / UDP.

[0167] In a TCP scenario, response data is sent in a format of length prefix + data content to ensure that the signaling client can fully parse it.

[0168] In UDP scenarios: If the response data is too large (more than 1500 bytes), it will be automatically fragmented for transmission. Each fragment carries a traceability ID and fragment sequence number to facilitate reassembly by the signaling client.

[0169] The specific process of generating SIP response signaling containing the source ID after the signaling client receives the response data in step S7 is as follows:

[0170] S71: After receiving the response data from the monitoring device, the signaling client first performs an integrity check based on the transmission protocol type:

[0171] For TCP transmission responses: verify that the data length matches the header prefix identifier to ensure no bytes are lost;

[0172] For UDP fragmented transmission response: reconstruct complete data by using the fragment sequence number and the total number of fragments, and then verify that the data has not been tampered with by using the built-in CRC checksum;

[0173] S72: Extract the traceability ID embedded in the monitoring device from the response data. This traceability ID is consistent with the traceability ID of the control command sent by the signaling client. Compare this traceability ID with the locally cached command-traceability ID mapping table.

[0174] If they match, confirm the correlation between the response data and the original control command, and proceed to the next step of processing;

[0175] If there is a discrepancy, such as if the traceability ID is tampered with during network transmission, a traceability ID mismatch exception log is generated, including the incorrect traceability ID, the correct traceability ID, and the response data digest. An error message with the correct traceability ID is then sent to the signaling server.

[0176] S73: The signaling client calls the corresponding parsing module based on the original format of the response data (JSON / XML / binary) to extract the core business fields:

[0177] For real-time video-on-demand responses: extract fields such as rtspUrl and expireTime;

[0178] AI anomaly analysis response: Extract fields such as eventType, timestamp, and snapshotUrl;

[0179] Response to device status: Extract fields such as deviceStatus, cpuUsage, and networkSpeed;

[0180] S74: Map the extracted core business fields to a standardized signaling structure:

[0181] Signaling start line: Set the response status code. Success is 200 OK, failure is 4xx / 5xx, such as 486 BusyHere for device busy.

[0182] Standard header field: populates required fields such as Via (record signaling path), From (signaling client identifier), To (signaling server identifier), and Call-ID (session identifier);

[0183] Custom extended header fields: Add an X-Trace-ID header field, fill in the verified traceability ID; add an X-Device-Type header field, identify the monitoring device type, such as CAM or AIBOX.

[0184] A national standard signaling system for monitoring unmanned convenience stores, see [link / reference]. Figure 2 The system comprises a signaling gateway service (sip-gateway), a signaling server (sip-server), a signaling client (sip-client), monitoring devices, and a database. The signaling gateway service module (sip-gateway) receives HTTP requests from users, converts them into standard SIP signaling with priority identifiers according to preset field mapping rules, embeds a unique signaling traceability ID, and forwards it to the signaling server module. The signaling server (sip-server), communicating with the sip-gateway, receives SIP signaling, parses its header fields to obtain its priority, adds the SIP signaling to the corresponding priority processing queue according to preset scheduling rules, extracts SIP signaling from the priority processing queue, queries a preset device registry to match the corresponding signaling client (sip-client), and verifies the connection status between the signaling client (sip-client) and the monitoring device; it also records signaling response logs and forwards SIP response signaling to the sip-gateway.

[0185] The signaling client (SIP-client) communicates with the SIP-server and monitoring devices. It receives SIP signaling, parses the operation instructions and traceability IDs within the signaling, adaptively selects the transmission protocol based on the communication characteristics of the monitoring devices, generates device control instructions with traceability IDs, sends these instructions to the monitoring devices, and receives response data generated by the monitoring devices after execution of operations. It then generates SIP response signaling containing traceability IDs and sends it back to the SIP-server. The monitoring devices, selected from cameras, access control systems, and AI analysis boxes, communicate with the signaling client module. They receive device control instructions, execute corresponding operations, generate response data carrying traceability IDs, and send the response data back to the signaling client module. The database, communicating with the SIP-gateway, stores the entire signaling interaction log, including request logs, transformation logs, scheduling logs, distribution logs, and response logs, associated with the traceability IDs.

Claims

1. A national standard signaling method for a monitoring system of unmanned convenience stores, characterized in that, Includes the following steps: S1: The signaling gateway service receives HTTP requests initiated by users, converts them into standard SIP signaling with priority identifiers, embeds a unique signaling traceability ID, and then forwards them to the signaling server. S2: The signaling server receives SIP signaling and parses the header field to obtain its priority. According to the preset scheduling rules, it adds the SIP signaling to the corresponding priority processing queue. S3: The signaling server extracts SIP signaling from the priority processing queue, queries the preset device registry to match the corresponding signaling client, and verifies the connection status between the signaling client and the monitoring device; S4: If the connection is normal, the signaling server will send SIP signaling to the matching signaling client and record the signaling distribution log; if the connection is abnormal, the disconnection reconnection mechanism will be triggered. S5: After receiving SIP signaling, the signaling client parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol according to the communication characteristics of the monitoring equipment, and generates device control instructions with traceability ID; S6: The signaling client sends the device control command to the monitoring device. After the monitoring device performs the operation, it generates response data and sends it back to the signaling client, carrying the traceability ID in the response data. S7: After receiving the response data, the signaling client generates a SIP response signaling containing the source ID and sends it back to the signaling server; S8: The signaling server records the signaling response log and forwards the SIP response signaling to the signaling gateway service; The signaling gateway service converts SIP response signaling into HTTP response and returns it to the user, while storing the signaling interaction end-to-end logs with the source ID in the database.

2. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, The specific process of step S1 is as follows: S11: The signaling gateway service receives HTTP requests initiated by users, including monitoring operation instructions, target device identifier (deviceId), and request priority identifier; S12: The signaling gateway service converts HTTP requests into standard SIP signaling according to preset field mapping rules; S13: Generate a unique signaling traceability ID and forward the SIP signaling with the traceability ID and priority tag to the signaling server.

3. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, The specific process of step S2 is as follows: S21: The signaling server receives SIP signaling carrying a unique signaling traceability ID and a custom priority header field X-Signaling-Priority through a preset SIP protocol port; S22: Perform basic format verification on the received SIP signaling, extract the Call-ID, From, and To fields from the signaling header field, match them with the preset whitelist of the signaling gateway service, and exclude illegal signaling; S23: After the verification is successful, the signaling server traverses the header field list of SIP signaling, locates the custom priority header field X-Signaling-Priority, and reads the field value of the X-Signaling-Priority header field; S24: The signaling server performs priority mapping based on the parsed X-Signaling-Priority field value; S25: The signaling server adds the SIP signaling after priority determination to the corresponding priority processing queue according to the rule of prioritizing high priority and sorting the same priority by reception time.

4. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 3, characterized in that, In step S3, the signaling server extracts SIP signaling from the priority processing queue and queries the preset device registry to match the corresponding signaling client. The specific process is as follows: S31: The signaling server calls the queue scheduling module to schedule the three independent priority processing queues (high, medium, and low) according to the rule that high-priority signaling is processed first and signaling of the same priority is sorted by reception time. S32: The signaling server uses the temporarily stored deviceId as the search keyword to query the preset distributed device registry; Perform deviceId matching. If a unique associated record is found, extract the core data from that record, including the signaling client ID, device IP, communication protocol type, and list of supported functions.

5. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 4, characterized in that, The specific process for verifying the connection status between the signaling client and the monitoring device in step S3 is as follows: Based on the signaling client ID extracted from the device registry, the signaling server queries the real-time online status of the signaling client through a heartbeat detection mechanism: the signaling client sends a heartbeat packet containing the client ID, device connection status code, and source ID at specified time intervals, and the server updates the signaling client status cache pool in real time; if the heartbeat interval does not exceed the preset timeout threshold, the status is determined to be online, and the signaling client is confirmed as a matching target; if the heartbeat interval exceeds the timeout threshold, the status is determined to be offline.

6. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, The specific process of the signaling server sending SIP signaling to the matching signaling client in step S4 is as follows: S41: After determining the matching signaling client, the signaling server verifies the integrity of the SIP signaling to be sent again, and verifies the logical consistency between the message body and the header field. After all verifications are successful, step S42 is executed. S42: Determine the delivery strategy based on signaling priority and the communication characteristics of the signaling client; S43: The signaling server calls the protocol adaptation module to encapsulate the SIP signaling according to the signaling client communication protocol recorded in the device registry. If it is a TCP protocol, the SIP signaling is encapsulated in TCP byte stream format and a message length prefix is ​​added to ensure that the signaling client can parse it completely; If it is a UDP protocol, the SIP signaling is encapsulated in the UDP datagram format, and the signaling exceeding the MTU is split into multiple fragments. Each fragment is given a fragment sequence number and a total fragment count identifier. S44: Transmit encapsulated SIP signaling through an encrypted channel. The encryption key is a session key generated by the signaling server and the signaling client through a specified key negotiation protocol during connection initialization. S45: The signaling server sends encapsulated SIP signaling through the IP address and port of the signaling client, and simultaneously starts link monitoring: monitors the network latency and packet loss rate of the transmission link in real time, and if the corresponding threshold is exceeded, it temporarily switches to the backup transmission channel.

7. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, In step S5, after the signaling client receives the SIP signaling, it parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol based on the communication characteristics of the monitoring device, and generates device control instructions with traceability IDs. The specific process is as follows: S51: The signaling client receives SIP signaling from the signaling server through a preset port, and decrypts the signaling using an algorithm negotiated with the signaling server to obtain the original SIP signaling content. S52: The signaling client verifies the structural integrity of the SIP signaling, extracts the signaling source ID from the signaling header field, and verifies consistency by calculating the overall hash value of the SIP signaling. If all these steps pass, proceed to step S53. S53: The signaling client parses the message body of the SIP signaling, extracts the core operation instructions, and reads the signaling source ID in the signaling header field, binds the two and stores them in the local cache; S54: The signaling client reads the device type identifier configured locally to determine the type of the currently associated monitoring device; Select the protocol according to the preset device type-transmission protocol mapping rules: If the device type is CAM, the default protocol is TCP; if the device type is AIBOX, the default protocol is UDP. S55: The signaling client calls the corresponding instruction generation module according to the type of operation instruction to convert the abstract operation instruction in SIP signaling into a specific control instruction that the monitoring device can directly execute: for real-time video on demand instructions, generate RTSP protocol PLAY instructions; for AI anomaly detection instructions, generate custom binary instructions; and forcibly embed the signaling traceability ID in the generated device control instructions. S56: Encapsulate the control command with traceability ID at the protocol layer according to the selected transmission protocol: TCP encapsulation: Add a 4-byte length prefix and organize according to byte stream format; UDP encapsulation: If the instruction length exceeds the MTU, it is split in the format of fragment sequence number + total number of fragments + source ID + fragment data.

8. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, The specific process of the signaling client sending device control commands to the monitoring device in step S6, and the monitoring device generating response data after executing the operation, is as follows: S61: After receiving the control command, the monitoring equipment parses and extracts the embedded traceability ID, and verifies the legality of the command source by comparing it with the signaling client whitelist stored locally. S62: The monitoring equipment executes the corresponding operation according to the instruction type, and records key nodes in real time during the process; S63: After the monitoring device performs the operation, it generates response data in a preset format and forcibly embeds the traceability ID; S64: The monitoring device sends response data back to the signaling client using the same transmission protocol as the received instruction.

9. The national standard signaling method for a monitoring system of unmanned convenience stores according to claim 1, characterized in that, The specific process of generating SIP response signaling containing the source ID after the signaling client receives the response data in step S7 is as follows: S71: After receiving the response data from the monitoring device, the signaling client performs an integrity check according to the transmission protocol type; S72: Extract the traceability ID embedded in the monitoring device from the response data and compare it with the locally cached instruction-traceability ID mapping table: If they match, confirm the correlation between the response data and the original control command, and proceed to the next step of processing; If they are inconsistent, a source ID mismatch error log is generated, and an error message with the correct source ID is sent to the signaling server. S73: The signaling client calls the corresponding parsing module based on the original format of the response data to extract the relevant core business fields; S74: Map the extracted core business fields to a standardized SIP response signaling structure.

10. A national standard signaling system for monitoring unmanned convenience stores, characterized in that, This includes the signaling gateway service (SIP-gateway), the signaling server (SIP-server), the signaling client (SIP-client), monitoring equipment, and a database. The signaling gateway service module sip-gateway is used to receive HTTP requests initiated by users, convert the HTTP requests into standard SIP signaling with priority identifiers according to preset field mapping rules, embed a unique signaling traceability ID, and then forward it to the signaling server module. The signaling server, sip-server, communicates with sip-gateway and is used to receive SIP signaling, parse the header field to obtain its priority, and add the SIP signaling to the corresponding priority processing queue according to the preset scheduling rules. It extracts SIP signaling from the priority processing queue, queries the preset device registry to match the corresponding signaling client sip-client, and verifies the connection status between the signaling client sip-client and the monitoring device; it is also used to record signaling response logs and forward SIP response signaling to sip-gateway; The signaling client (sip-client) communicates with the sip-server and monitoring equipment. It receives SIP signaling, parses the operation instructions and traceability ID in the signaling, adaptively selects the transmission protocol according to the communication characteristics of the monitoring equipment, generates device control instructions with traceability IDs, and sends the device control instructions to the monitoring equipment. Receive response data generated after the monitoring equipment performs an operation, generate SIP response signaling containing the traceability ID, and send it back to the sip-server; The monitoring equipment, selected from cameras, access control systems, and AI analysis boxes, communicates with the signaling client module to receive device control commands and execute corresponding operations, generate response data and carry traceability IDs in the response data, and feed the response data back to the signaling client module; The database, which communicates with the SIP-gateway, is used to associate traceability IDs and store the full-link logs of signaling interactions. The full-link logs include request logs, transformation logs, scheduling logs, distribution logs, and response logs.

Images