Release Overview
Version 2025.3.1 delivers expanded signalling-protocol analytics, enhanced media-stream processing, and upgraded RTP/RTCP quality visualization. These improvements boost the accuracy of complex telecom analysis, streamline the workflow for engineers and analysts, and extend SIP3’s automation capabilities.
This release places special emphasis on reliable handling of SIP and SIP-I messages, call-termination logic, and UDF support in the commercial edition of SIP3.
Changes and improvements
1. Improved ISUP message handling in SIP-I (SIP3 commercial version)
Extended support has been added for the clear, readable display of ISUP (ISDN User Part) fields embedded in SIP-I messages. SIP-I – SIP with ISUP encapsulation – is an extension of the SIP protocol that allows ISUP data to be carried inside SIP messages. It’s used in scenarios where traditional and mobile telephony networks (SS7, ISDN) need to interoperate with modern voice and video over IP (SIP) networks.
SIP-I was created to enable a smooth transition from legacy TDM/SS7 systems to IP-based telephony. It solves a key challenge: transporting the ISUP signalling protocol over IP without losing any information or altering its operational behavior.
SIP-I is a regular SIP dialogue in which:
- Within INVITE, UPDATE, BYE, and other messages, the ISUP body (IAM, ACM, ANM, REL, RLC, etc.) is transmitted in the body (application/ISUP);
- The SIP layer provides routing, transactions, dialogs, and IP transport;
- ISUP information continues to control the call logic and relays PSTN end-to-end semantics.
Typical scheme:
PSTN (SS7) – media gateway – SIP-I – Softswitch / Contact Center – IVR / ACD
SIP-I is widely used by telecom service providers. It allows modern contact centers and operators to preserve legacy call-control logic and migrate intelligent SS7 services into VoIP environments. SIP-I is also commonly used for interconnection between telecom operators and wholesale carriers.
An example fragment of a SIP-I message:
Content-Type: application/ISUP; version=ITU Content-Disposition: signal;handling=required <original ISUP message in binary or hex representation>
ISUP contains extensive call handling information, such as:
- call category,
- release cause,
- routing parameters between networks,
- subscriber data, and entry points.
The full ISUP specification contains more than 130 parameters, but in real-world deployments, 80-90% of use cases rely on roughly 20-30 key fields.
SIP3 has long supported SIP-I with embedded ISUP, but the new release significantly improves this functionality. Nested ISUP fields are now parsed more accurately and presented in a clear, human-readable format.
This allows engineers to:
- Diagnose inter-network interactions (SIP-SS7),
- Identify causes of failures,
- Compare SIP calls with TDM traffic,
- Conduct quality and route audits.
SIP3 UDF also supports traffic orchestration – including dynamic routing, switching, blocking, and advanced statistical collection.
Based on publicly available data, inter-network calls account for roughly 40-70% of all call traffic, and 10–50% of those inter-network calls use SIP-I. That may not sound significant at first, but in the U.S. this translates to approximately 2–10 billion SIP-I messages per day, and 1-4 billion per day in Europe.
Comprehensive SIP-I analysis – something SIP3 makes fast and straightforward – gives service providers clear visibility into what is actually happening at network boundaries and in interactions with the PSTN. This directly affects revenue assurance, service quality, and overall business stability.
The subject is important enough that we’ll likely publish a dedicated deep dive, but the key point is this: the latest SIP3 release already incorporates significantly improved mechanisms for processing ISUP encapsulated inside SIP.
2. Support for processing SIP messages with empty user parts in From/To headers
SIP3 can now correctly process messages in which the mandatory SIP From and To headers contain invalid URIs with an empty or missing user part.
Example of an erroneous message:
From: <sip:10.11.12.13:5060;user=phone>;tag=3997885528
The correct format (according to RFC 3261):
From: "Alice" <sip:alice@example.com>;tag=3997885528 To: <sip:bob@example.com>
Empty user-parts are not prohibited, but they create real problems in analytics and monitoring:
- Loss of subscriber identification (it is impossible to determine who actually called)
- Difficulties in call correlation and tracking
- Deterioration in fraud detection
- Decrease in the effectiveness of Voice Quality Monitoring
Although the absence of a user part doesn’t violate the RFC, in real networks these messages usually appear because of specific device configurations and are generally uncommon – most often caused by misconfigurations. SIP3 now surfaces such calls clearly so engineers can immediately spot the missing user part and diagnose the issue.
Configuration in SIP3 Salto
Configuration in SIP3 Salto has a new parameter:
sip.allow_empty_user = true | false (false by default)
If true is set then:
- The call is assembled even with From/To errors,
- SIP transactions are reconstructed,
- the UI displays problematic messages.
This new capability is especially valuable when diagnosing malfunctioning SIP clients, ATAs, SBCs, and gateways.
The business impact of something as small as an empty From/To header can be significant:
- Revenue Assurance Risk – Missing caller/callee IDs make billing validation difficult, create CDR mismatches, and lead to lost minutes and commissions. The potential revenue impact is 3-15%.
- Higher Support Costs – Ambiguous call records complicate troubleshooting, increase engineering workload, and drive up SLA penalties.
- Fraud Exposure – Anonymous or “identity-less” calls make fraud detection harder and can result in direct financial losses.
- Lower Customer Experience Quality – Without proper subscriber identification, it’s impossible to prioritize traffic, personalize handling, or maintain stable FCR – driving higher churn.
- Reputational Damage – Poor routing transparency can be perceived as “gray” traffic, undermining partner trust and worsening inter-carrier terms.
3. Adding all SIP transactions to call processing (UDF, commercial version)
User Defined Functions (UDFs) have been significantly enhanced: they can now process all SIP transaction types, not just initial requests like INVITE and REGISTER.
UDF documentation:
https://sip3.io/docs/features/UserDefinedFunctions.html
What is a SIP transaction?
According to RFC 3261, a transaction = request + associated responses.
Examples:
- INVITE – 100/180/200
- REGISTER – 401/200
- BYE – 200
Example: REFER processing
REFER is used to:
- redirect calls,
- implement call transfers,
- initiate linked calls.
Standards:
Now the UDF in SIP3 can:
- track REFER,
- build a correlation between the original call and the redirected one,
- generate additional fields and metrics for advanced search.
User interface (Commercial version)
The UI includes:
- Creating and editing UDFs,
- selecting Salto for execution,
- displaying the download status,
- viewing execution errors.
4. Case-insensitive processing of SIP headers in sip.message
SIP headers are now processed in a case-insensitive manner.
Examples of different spellings of the same header:
P-Preferred-Identity p-preferred-identity P-PREFERRED-IDENTITY P-Preferred-IDENTITY
SIP Headers Overview
Mandatory SIP Headers (RFC 3261):
-
- Via
- From
- To
- Call-ID
- CSeq
- Max-Forwards
Key headings for IMS and carrier networks:
-
- P-Preferred-Identity
- P-Asserted-Identity
- P-Charging-Vector
- P-Access-Network-Info
- Contact
- Record-Route / Route
- Authorization / Proxy-Authorization
Use in SIP3:
-
- building call processing logic,
- generating quality metrics,
- extended logic in UDF (commercial version).
5. Adjustments to SDP processing
The SDP parser has been improved:
- improved processing of media session descriptions,
- improved support for complex SDPs (multiple m-lines, ICE attributes, complex fmtp),
- more accurate identification of media parameters.
SDP fragment example:
m=audio 40000 RTP/AVP 0 8 18 c=IN IP4 192.168.10.10 a=rtcp:40001
6. Improved RTPR (RTP/RTCP) post-processing
What is RTP/RTCP?
- RTP – media transmission (voice, video).
- RTCP – quality control (loss, latency, jitter).
What’s improved
The RTP/RTCP module has been extensively redesigned:
- improved display of media streams when changing ports/addresses,
- improved RTP to SIP correlation based on SDP,
- correct operation with non-standard VoIP gateways.
Media stream addresses are transmitted in SDP and appear in messages:
- INVITE,
- 200 OK,
- UPDATE / RE-INVITE.
7. New RTP/RTCP quality visualization
The interface for displaying video stream quality has been completely updated.
New features:
- continuous quality gradient for the entire call duration,
- display of loss, jitter, and RTCP metrics,
- switching between absolute and relative time,
- dividing the display by node:
- top panel – node A statistics,
- center panel – visual quality gradient,
- bottom panel – node B statistics.
These enhancements make it faster to pinpoint quality degradation, identify loss points, and determine exactly which media stream was affected.
Conclusion
The SIP3 2025.3.1 release delivers major improvements across SIP, SIP-I, RTP, and RTCP analysis -making network diagnostics more accurate, more transparent, and more actionable. Enhanced UDF automation, upgraded media-stream visualization, and significantly improved ISUP handling all make SIP3 an even more powerful tool for telecom providers and integrators.