Audiocodes tunneling

VoIPmonitor Configuration for Audiocodes Tunneling

This guide explains how to configure VoIPmonitor to process packets that are tunneled from an Audiocodes Session Border Controller (SBC). This specific setup is for capturing data sent through the Audiocodes tunnel and differs from the standard configuration for capturing direct network traffic.

Overview

AudioCodes tunneling allows AudioCodes Session Border Controllers (SBCs) to encapsulate and forward SIP/RTP packets to VoIPmonitor, instead of using traditional network port mirroring (SPAN).

The setup involves two components:

1. AudioCodes SBC Configuration - Configure the AudioCodes device to forward packets to VoIPmonitor
2. VoIPmonitor Server Configuration - Configure VoIPmonitor to receive and process the tunneled packets

Important Use Case: TLS Decryption

AudioCodes tunneling is particularly useful for monitoring encrypted SIP over TLS traffic that uses Perfect Forward Secrecy (PFS) cipher suites like ECDHE.

When an AudioCodes SBC terminates TLS connections, it can:

• Decrypt the TLS-encrypted SIP signaling internally
• Forward the decrypted (clear-text) SIP packets to VoIPmonitor using the "debug call recording" feature
• Eliminate the need for SSL key logger injection or private key access

This approach is ideal when:

• Your AudioCodes SBC uses modern cipher suites (TLS 1.3, ECDHE) where private key decryption is impossible
• You cannot inject SSL key logger libraries into the SBC (closed appliance)
• You want centralized decryption at the SBC layer rather than at the VoIPmonitor sensor

For a comprehensive guide on all TLS decryption methods, including when to use AudioCodes tunneling vs SSL Key Logger, see TLS Decryption Guide.

Step 1: Configure the AudioCodes SBC

On the AudioCodes device, you need to enable the packet forwarding feature and configure it to send packets to the VoIPmonitor server.

• • Required Settings (AudioCodes Device):**

Access the AudioCodes SBC configuration interface (web GUI or CLI) and locate the following setting:

• Debug Recording Server (or equivalent log/mirroring server setting)
• Set this to the IP address of your VoIPmonitor server
• The AudioCodes SBC will then encapsulate SIP/RTP packets and send them to this IP address

The exact configuration steps vary by AudioCodes model and firmware. Refer to the AudioCodes documentation for:

• "Configuring the Debug Recording Server"
• "Log server configuration"
• "Session mirroring"

• • Network Ports Used by AudioCodes:**

By default, AudioCodes uses the following port for forwarding packets:

• UDP/TCP 925 (Default port)

You can configure a different port if needed, but ensure it matches the VoIPmonitor configuration (see Step 2).

Important: This method is preferred over traditional SPAN mirroring when:

• The AudioCodes SBC and VoIPmonitor sensor are on different network segments
• You need to avoid configuring switch-level SPAN ports
• You want more control over which traffic is forwarded

Step 2: Configure VoIPmonitor to Receive Tunneled Data

To enable the processing of data from an Audiocodes tunnel, the following options must be enabled in the sniffer's configuration file (voipmonitor.conf).

audiocodes           = yes
# The main switch that activates the Audiocodes tunnel processing feature.

# Next, define the ports on which the sniffer will listen for incoming tunneled data.
# These must match the port configured on the AudioCodes SBC.
# Choose the transport protocol (UDP/TCP) used by your Audiocodes SBC and enable the corresponding option.
udp_port_audiocodes  = 925
tcp_port_audiocodes  = 925

1. Ensure your firewall allows these ports (default: 925)

Special Options for RTP/RTCP Handling

These options address scenarios where VoIPmonitor can see both 'pure' (non-encapsulated) network packets and packets encapsulated within the Audiocodes tunnel for the same call. They allow you to specify which packets should be assigned to the final CDR, preventing data duplication.

audiocodes_rtp  = no/yes/only/only_for_audiocodes_sip
audiocodes_rtcp = no/yes/only/only_for_audiocodes_sip

The values for these options mean:

• no - Disables processing of RTP/RTCP packets that arrive encapsulated in the Audiocodes tunnel.
• yes - Enables processing of RTP/RTCP packets from the tunnel. This is the default value.
• only - Assigns only RTP/RTCP packets that are encapsulated in the Audiocodes tunnel to the call/CDR. Any pure (non-encapsulated) packets for the same call, if also seen by the sniffer, will be ignored.
• only_for_audiocodes_sip - Tunneled RTP/RTCP packets are assigned to a CDR only if the SIP signaling for that call was also delivered through the Audiocodes tunnel.

Common Scenarios and Troubleshooting

Problem: Mixed RTP Streams (RTP + SRTP)

When the sniffer captures traffic where plain SRTP is received via the Audiocodes tunnel alongside other traffic (e.g., mirrored traffic on a SPAN port), the resulting RTP streams can become mixed or incorrectly correlated. This happens because VoIPmonitor sees both the encapsulated packets from the tunnel and the pure packets on the network interface.

Solution:

To ensure RTP packets from the Audiocodes tunnel are correctly assigned only to those calls that also use AudioCodes SIP signaling, use the following configuration in your voipmonitor.conf:

[general]
audiocodes          = yes
audiocodes_rtp      = only_for_audiocodes_sip
audiocodes_rtcp     = only_for_audiocodes_sip

This configuration ensures that:

• Only RTP/RTCP packets from the AudioCodes tunnel are used for calls where the SIP signaling also came through the tunnel
• Pure (non-encapsulated) packets seen on the wire are not mixed with tunnel packets
• The correct association between tunnel RTP and tunnel SIP is maintained

When to Use Each Option:

• Use yes (default) when you only capture from the AudioCodes tunnel and no other traffic
• Use only when you want to EXCLUSIVELY use tunnel RTP for ALL calls (ignore any pure packets)
• Use no when you want to ignore tunnel RTP and use only pure packets
• Use only_for_audiocodes_sip when you have mixed traffic (tunnel + pure) and want to ensure correct pairing between tunnel RTP and tunnel SIP (this is the recommended setting for most mixed-capture scenarios)

Known Limitations

IP Addresses Logged as 0.0.0.0

In certain scenarios with AudioCodes tunneling, you may observe that some IP addresses are logged as 0.0.0.0 in the CDR view. This occurs when RTP packets that arrive through the AudioCodes tunnel do not contain the full IP header information that VoIPmonitor expects (the IP data is stripped out by the AudioCodes encapsulation format).

• Behavior: The system logs 0.0.0.0 because the necessary IP address information is not present in the RTP packet structure as received
• Root Cause: This is a technical limitation of how certain AudioCodes tunneling protocols encapsulate RTP data
• Is This Fixable? Currently, this is expected behavior and cannot be resolved by configuration changes. A fix would require code-level changes to implement specific handling for this encapsulation type
• Impact: While the IP column may show 0.0.0.0, the SIP signaling information (including correct IPs from Contact/From/To headers) and the actual call recording functionality remain intact. This is primarily a display limitation affecting the IP field for RTP streams only

If this limitation is affecting your reporting or analysis workflows significantly, please consider the following workarounds:

• Use SIP-based filtering and IP information (Contact, From, To headers) for call identification instead of relying solely on RTP IP addresses
• Check the SIP History tab in the CDR view to see the actual IP addresses from signaling packets
• Contact VoIPmonitor support to inquire about future development plans for this specific AudioCodes encapsulation case

Performance Impact on the SBC

When using AudioCodes tunneling, it is important to assess the performance impact on the AudioCodes SBC itself, particularly in high-traffic environments.

Monitoring SBC Performance

To determine if tunneling affects your AudioCodes SBC performance:

1. Check the current baseline: Monitor SBC CPU usage and network load before enabling tunneling 2. Enable the tunneling feature via UDP on the SBC 3. Monitor the SBC's CPU and network load during normal operation

You can perform this performance test without configuring a VoIPmonitor listener to isolate the SBC's performance impact from the sensor's processing load.

Refer to the AudioCodes SBC documentation for specific instructions on enabling tunneling and monitoring performance metrics.

AI Summary for RAG

Summary: This guide covers the complete setup for AudioCodes tunneling between AudioCodes Session Border Controllers (SBCs) and VoIPmonitor. It explains both sides of the configuration: (1) configuring the AudioCodes SBC's "Debug Recording Server" setting to forward packets to VoIPmonitor's IP address using UDP/TCP port 925 by default, and (2) configuring VoIPmonitor to receive and process tunneled packets by enabling audiocodes= yes and setting udp_port_audiocodes/tcp_port_audiocodes. The guide also explains handling RTP/RTCP packet assignment when both tunnel and pure traffic are available (audiocodes_rtp options: yes, no, only, only_for_audiocodes_sip), monitoring SBC performance impact, and known limitations including that IP addresses may appear as 0.0.0.0 when RTP packets from AudioCodes tunneling lack IP headers (this is expected behavior due to encapsulation format and cannot be fixed by configuration).

IMPORTANT TLS DECRYPTION USE CASE: AudioCodes tunneling is a specific solution for monitoring encrypted SIP over TLS traffic, particularly when the SBC uses Perfect Forward Secrecy (PFS) cipher suites like ECDHE where private key decryption is impossible. The AudioCodes SBC terminates TLS connections, decrypts the traffic internally, and forwards clear-text SIP packets to VoIPmonitor using the "debug call recording" feature. This eliminates the need for SSL key logger injection (LD_PRELOAD) or access to the SBC's private key. This method is ideal when you have an AudioCodes SBC, cannot inject libraries into a closed appliance, or want centralized decryption at the SBC layer. For comparison with other TLS decryption methods (Private Key, SSL Key Logger, Ribbon SBC, HEP), see the Tls documentation.

Keywords: audiocodes, tunnel, SBC, debugging recording server, configuration, port setup, udp, tcp, rtp, rtcp, mixed streams, only_for_audiocodes_sip, encapsulation, span port, mirroring, performance impact, CPU load, network load, TLS, TLS decryption, ECDHE, perfect forward secrecy, PFS, SIP over TLS, encrypted SIP, clear-text, decrypt, SBC decryption, method 4, debug call recording, tls 1.3, ssl key logger alternative, 0.0.0.0, known limitations, IP header, missing IP

Key Questions:

• How to configure AudioCodes SBC to forward packets to VoIPmonitor?
• Where to configure the Debug Recording Server on AudioCodes devices?
• Which network ports are required for AudioCodes tunneling to VoIPmonitor?
• How to configure VoIPmonitor to receive AudioCodes tunneled data?
• What port does AudioCodes use for packet forwarding (default)?
• How to fix mixed RTP streams when capturing both AudioCodes tunnel and regular traffic?
• What is the difference between audiocodes_rtp options (yes, no, only, only_for_audiocodes_sip)?
• When should I use audiocodes_rtp = only_for_audiocodes_sip?
• What is the performance impact of AudioCodes tunneling on the SBC?
• Can AudioCodes tunneling decrypt TLS-encrypted SIP with ECDHE ciphers?
• How to monitor encrypted SIP over TLS from an AudioCodes SBC without SSL key logger?
• What is the "debug call recording" feature on AudioCodes SBCs?
• When to use AudioCodes tunneling vs SSL Key Logger for TLS decryption?
• How does AudioCodes SBC handle Perfect Forward Secrecy (PFS) cipher suites?
• Why are IP addresses logged as 0.0.0.0 with AudioCodes tunneling?
• Can I fix the 0.0.0.0 IP issue by configuring AudioCodes tunneling?