Audiocodes tunneling

From VoIPmonitor.org
Revision as of 08:57, 5 January 2026 by Admin (talk | contribs) (Add performance impact section for SBC)

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.

Basic Tunneling Options

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.
# Choose the transport protocol (UDP/TCP) used by your Audiocodes SBC and enable the corresponding option.
udp_port_audiocodes  = 925
tcp_port_audiocodes  = 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)

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 configuring VoIPmonitor to process packets tunneled from AudioCodes Session Border Controllers (SBCs). It explains how to enable tunnel processing, configure UDP/TCP ports, and handle RTP/RTCP packet assignment when both tunnel and pure traffic are available. Key configurations include audiocodes, udp_port_audiocodes, tcp_port_audiocodes, audiocodes_rtp, and audiocodes_rtcp parameters. The guide also includes information about monitoring SBC performance when using tunneling.

Keywords: audiocodes, tunnel, SBC, rtp, rtcp, mixed streams, only_for_audiocodes_sip, encapsulation, span port, mirroring, performance impact, CPU load, network load

Key Questions:

  • How to configure VoIPmonitor for AudioCodes tunneling?
  • 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)?
  • How to prevent RTP/RTCP packet duplication when both tunnel and pure traffic are visible?
  • When should I use audiocodes_rtp = only_for_audiocodes_sip?
  • What is the performance impact of AudioCodes tunneling on the SBC?
  • How to monitor the SBC CPU and network load when using tunneling?