This release delivers functional enhancements, improved SIP/SDP traffic handling, UI refinements, increased reliability in dynamic environments, and strengthened security.
Dynamic Infrastructure Addressing: Friendly Hostmap
Hostmap is a built-in SIP3 feature that maps IP addresses to logical network names. Unlike traditional DNS, IP telephony and Unified Communications environments often involve nodes with multiple interfaces and IPs, as well as private addresses internally that appear as public IPs externally (e.g., via NAT). To make these complex relationships easy to understand and analyze, SIP3 uses the Hostmap mechanism, providing clear, human-readable network identification across dynamic infrastructures.
Hostmap has been part of SIP3 for quite some time. The image below shows how Hostmap configuration looks in the SIP3 user interface.
Nodes defined via Hostmap enable more accurate call-leg correlation, display meaningful node names in service interaction diagrams, allow searching across call records by node name, and provide VoIP/UC metrics and statistics aggregated by logical node addresses rather than raw IPs.
Starting with SIP3 Release 2025.3.2, the Enterprise Edition introduces an enhanced Hostmap orchestration mechanism. It improves detection and correlation of IP addresses used in SIP and RTP signaling, including NAT scenarios in dynamically addressed environments.
For example, in cloud environments such as AWS, instances are typically assigned private IP addresses, while public IPs are used for media traffic. The new mechanism correctly handles these scenarios, ensuring accurate SIP and RTP analysis.
In autoscaling infrastructures – where the number of nodes dynamically adjusts to load – Hostmap objects must be created and removed automatically. With frequent IP assignment and release cycles, address conflicts can occur.
As part of this release, a conflict-prevention mechanism has been introduced to handle these cases:
- Media address detection remains accurate at all times
- Hostmap object conflicts are resolved automatically
- Overall system stability is improved in highly dynamic environments
By using Hostmap-driven diagrams, Tier 2 and Tier 3 support teams report a 60% reduction in Mean Time to Repair (MTTR). Because the diagram is generated in real-time from the Hostmap data, there is no “guesswork” about which firewall or proxy a call passed through – the proof is in the visualization.
SDP processing enhancements
SDP (Session Description Protocol) is used to negotiate media parameters between participants during service delivery. SDP does not carry voice or video itself—it describes how media should be exchanged, including IP addresses, ports, codecs, and security attributes.
In VoIP and Unified Communications, SDP is embedded in SIP messages (INVITE and related responses) so endpoints can agree on where and how to send audio and video streams. Accurate SDP processing is critical to reliable service operation.
Endpoints are often located behind NAT and use private IP addresses. Without additional mechanisms, the called party may attempt to send media to an internal IP address, resulting in “one-way audio” or complete silence. To address this, supplemental technologies are used—one of the most common is ICE (Interactive Connectivity Establishment, RFC 8445).
ICE discovers all viable media paths between endpoints. It works by gathering candidates: the device collects all possible addresses, including its local IP, a public IP discovered via STUN, and relay addresses provided by TURN. These candidates are exchanged within SIP messages as part of the SDP body.
Endpoints then perform connectivity checks by sending small test packets to determine which path actually works. Based on the results, the most suitable and highest-priority route is selected for RTP media transmission.
During operation of SIP3-based solutions, certain SDP processing scenarios were identified where data representation required improvement.
With SIP3 Release 2025.3.2:
- SDP parsing capabilities have been enhanced
- Robust handling of ICE candidates has been implemented
These changes eliminate edge cases in signaling processing and improve the stability and accuracy of SIP/SDP analysis in complex network topologies.
UDF deployment process enhancement
UDF (User Defined Functions) is a SIP3 feature that allows custom processing and data-correction logic to be embedded directly into the processing pipeline. UDF enables engineers – during deployment or live operation – to add custom metrics, define calculation logic, and implement automated analysis tailored to the specific VoIP/UC service environment.
UDFs are engineer-authored programs. Detailed documentation and examples are available in the official SIP3 documentation: https://docs.sip3.io/docs/features/UserDefinedFunctions.html
The UDF functionality allows different functions to be deployed to different traffic-processing instances of SIP3 Salto. This enables more flexible and targeted traffic handling. Multiple UDFs can be loaded, and multiple SIP3 Salto instances can run in parallel, allowing processing logic to scale and adapt to the environment.
In SIP3 Release 2025.3.2:
- The UDF deployment process has been improved
- Execution control for user-defined functions has been added
- Data integrity and deterministic call processing are enforced
These changes significantly increase system reliability, eliminating inconsistent SIP transaction handling when large numbers of UDFs are in use.
CORS policies enhancement
OAuth2 support in SIP3 is a critical capability for delivering enterprise-grade security.
- Instead of managing local user accounts, SIP3 integrates with your existing Identity Provider (IdP), such as Keycloak, Okta, Azure Active Directory, or Google.
- Single Sign-On (SSO) lets users access the SIP3 console using their corporate credentials, eliminating the need for additional passwords.
- OAuth/OIDC also supports group attribute mapping. For example, users in the VoIP_Admins group in Active Directory can be automatically granted administrator privileges in SIP3.
OAuth2 enables seamless integration of the SIP3 VoIP/UC monitoring and troubleshooting platform into an organization’s existing access management ecosystem.
To integrate SIP3 authentication with external services via OAuth2, proper implementation of CORS (Cross-Origin Resource Sharing) is required.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web applications access resources from other domains using specific HTTP headers, preventing unauthorized access to data.
In some SIP3 deployments, specific edge cases related to CORS behavior were identified.
In SIP3 Release 2025.3.2:
- CORS policies have been reviewed and adjusted;
- Security of interactions between the user interface, the authentication system, and external OAuth2 services has been strengthened;
- Potential integration issues in browser-based scenarios have been resolved.
OAuth2 in SIP3 is not only about security—it’s also about usability. Properly configured CORS (Cross-Origin Resource Sharing) combined with OAuth2 ensures that the browser can securely interact with APIs without request blocking issues. This gives engineers confidence that the interface will remain available during critical incidents, without failures caused by access control errors.
UX for Captain updates
Architecturally, SIP3 is a multi-component system. One of its key components is the SIP3 Captain traffic capture agent. In commercial deployments, this typically means dozens or even hundreds of Captain instances distributed across the infrastructure. As a result, long-term operation raises practical questions about how to manage and update these distributed components efficiently.
The traditional approach recommended by SIP3 in such scenarios is automation with Ansible, which sequentially executes API calls against distributed components. Using API-based control is a solid and flexible option and can also be integrated with other automation frameworks beyond Ansible.
To monitor components, their configuration, and operational status, SIP3 provides a dedicated Components page in the UI.
In SIP3 Release 2025.3.2, the Enterprise edition introduces the ability to update SIP3 Captain agents directly from the user interface.
By using the Restart button on the Components page—while holding the Cmd/Ctrl key—Salto sends a control command to the Captain agent that initiates the SIP3 Captain package upgrade process.
This is a small improvement, but it simplifies and accelerates SIP3 maintenance workflows in specific operational scenarios.
Empowered Custom Search
From the very beginning, SIP3 has offered two types of search for communication transactions—one designed for experts (such as Tier 2 and Tier 3 support) and another tailored for frontline help desk staff (Tier 1 support).
The first, Advanced Search, is an expert-level interface inspired by tools like Wireshark, featuring a powerful query bar with advanced syntax. The second, Simple Search, uses a set of straightforward input fields designed for ease of use, allowing staff without specialized training to work effectively.
Several years ago, our team introduced a configurable Custom Search interface. It allows administrators to build a tailored UI that matches the specifics of their services, enabling support teams to work faster and more efficiently. Our goal has always been to make analysis simple, intuitive, and—most importantly—fast, even when dealing with large volumes of communication data.
Custom Search has become widely adopted among SIP3 customers, combining the clean simplicity of Simple Search with the power and flexibility of Advanced Search.
Starting with SIP3 Release 2025.3.2, Custom Search can now include an advanced query bar similar to Advanced Search. You can also configure a custom set of fields displayed in the results table, and the CSV export has been updated to correctly include all fields.
Commercial SIP3 customers can now equip their support teams even more effectively and reduce the routine workload on experts. This delivers not only direct cost savings, but also higher customer satisfaction—users get answers immediately, without long and frustrating wait times.
Visual correlation of service transactions
VoIP/UC service delivery infrastructures differ from company to company. They vary in the number of interconnects, service delivery models, IVR and AI components, and billing architectures.
One of SIP3’s core capabilities is building a complete end-to-end service chain—and its visual diagram—from individual call segments (legs or hops). These fully correlated calls enable support and engineering teams to quickly analyze interactions and gain clear insight into how a service is delivered.
In a typical workflow, the user searches by defined criteria—calling number, called number, time range, and other parameters—and receives a list of service transactions. From this list, the user opens the relevant calls. Each call opens in a separate window, and with a simple key press, multiple calls can be merged into a single Сall Flow and viewed together in one window.
When is this useful? We highlight two key scenarios:
- An expert identifies a new correlation attribute and assembles a more complete interaction diagram of the infrastructure nodes involved in a specific call.
- A VoIP engineer merges multiple calls into a single diagram to compare scenarios—highlighting common patterns, differences, and timing characteristics. As an added benefit, multiple calls can be exported together into a single PCAP file for further analysis by colleagues or partners.
In Release 2025.3.2, the functionality for correlating call legs where the called party did not answer has also been improved.
With this update, engineers can work even more efficiently and comfortably when analyzing real-world call scenarios.
Additional User Interface improvements
Significant effort have been applied to optimize and refine the User Interface. In this release, you’ll see the results of extensive work by the team, including updates to configuration table rendering, improvements to the call list table, clearer labels in Custom Search input fields, enhancements to the login dialog, and the addition of a Hostmap refresh button that no longer requires a browser page reload.
Display of SIP messages that do not fully comply with standards has also been improved.
Environmental Improvements
During the SIP3 software update, the following security vulnerabilities were identified and resolved:
CVE-2025-67735
This vulnerability was caused by insufficient neutralization of special characters in application-layer protocols (in this case, HTTP), allowing manipulation of message syntax. It is a typical input validation flaw that demonstrates how low-level weaknesses in network traffic handling can lead to security issues in distributed systems.
CVE-2025-11965
From a security perspective, this vulnerability allows bypassing an intended data protection mechanism, which may result in unintended disclosure of sensitive information such as configuration files, keys, or source code without authentication. It is classified as “Files or directories accessible to external parties” and rated as medium severity, as it is remotely exploitable with low attack complexity and no privileges required, while potentially compromising application confidentiality.
CVE-2025-11966
This vulnerability occurs because file and directory names are inserted into generated HTML pages without proper escaping of special characters. An attacker can create or rename a file to include embedded HTML or JavaScript. When another user browses such a directory, the malicious script executes in the context of a trusted site, potentially leading to session theft or other client-side attacks.
CVE-2025-58057
This issue is caused by improper handling of highly compressed input data in decoders (including BrotliDecoder and certain others). When processing specially crafted malicious input, the decompression logic repeatedly allocates memory buffers without adequate limits. As a result, the application may consume excessive amounts of RAM, potentially exhausting all available memory and triggering an OutOfMemoryError, leading to a Denial of Service (DoS) condition.
CVE-2025-58056
This vulnerability is a form of HTTP Request Smuggling discovered in Netty’s HTTP codec, a framework widely used to build Java-based network servers and clients. The issue arises from incorrect parsing of chunked HTTP/1.1 requests: Netty accepts a single LF (Line Feed) as the chunk-size line terminator instead of the required CRLF (Carriage Return + Line Feed) defined by the HTTP specification.
This deviation from the standard allows an attacker to craft specially formed requests that are interpreted differently by intermediary proxies and the backend server. As a result, a proxy may treat the input as a single request, while Netty splits it into multiple requests, creating conditions for request smuggling attacks.
CVE-2025-8671
This vulnerability class highlights a mismatch between network protocol specifications and internal server implementations. When stream state handling does not strictly follow the HTTP/2 specification (RFC 9113), limits on the number of active requests can be bypassed. This enables attacks that create “phantom” workloads, overloading the server beyond its intended capacity and potentially leading to a denial of service.
CVE-2025-55163
This vulnerability falls under CWE-770: Allocation of Resources Without Limits or Throttling. Due to improper frame handling, the server fails to enforce resource limits and continues to consume CPU time and memory on an endless stream of “phantom” requests. Exploiting this logic flaw can cause significant service degradation and ultimately result in a denial of service for legitimate users.