A dedicated, actively-maintained TSG_OLAP Flink streaming job (galaxy/tsg_olap/sip-rtp-correlation, 200+ commits through late 2024) fuses one-way SIP signaling records with their corresponding RTP media-stream records into unified bidirectional VoIP call records in real time, keyed by address/session state with configurable expiry -- a production system for reconstructing complete VoIP call metadata (parties, duration/state) from separately-captured signaling and media flows.

A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.

A MESA Lab experiment re-identifies individual users across time solely from which domains they visit, using one-hot/frequency "domain access vectors" (Jaccard, overlap-coefficient, cosine, Euclidean) computed against real production HTTP logs pulled from a ClickHouse table named tsg_galaxy_v3.connection_record_log_http_domain. The best-performing configuration (Alexa top 100-10000 domain list, overlap coefficient) distinguished the same user's adjacent-hour sessions from other users' sessions with high separation (~0.19 vs ~0.88 average difference).

The galaxy/tsg_olap/log-stream-voip-relation repo is a Flink/Kafka streaming job (VoIpRelationTopology) that correlates SIP signaling flows with their corresponding RTP media flows across VSYS (virtual-system) boundaries, reconstructing complete VoIP call sessions from separately-observed signaling and media traffic.

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.

The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author 郑超, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.

An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').