Audiocodes tunneling: Difference between revisions

From VoIPmonitor.org
(Add SBC performance impact info to AI Summary for RAG)
(Rewrite: konsolidace a vylepšení struktury - stručnější, přidán See Also)
 
Line 3: Line 3:
[[Category:Sensors]]
[[Category:Sensors]]


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.
AudioCodes tunneling allows AudioCodes SBCs to encapsulate and forward SIP/RTP packets to VoIPmonitor via the "Debug Recording Server" feature, as an alternative to traditional SPAN port mirroring.
 
== 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).


<kroki lang="mermaid">
<kroki lang="mermaid">
Line 33: Line 30:
</kroki>
</kroki>


The setup involves two components:
== When to Use AudioCodes Tunneling ==
 
# '''AudioCodes SBC Configuration''' - Configure the AudioCodes device to forward packets to VoIPmonitor
# '''VoIPmonitor Server Configuration''' - Configure VoIPmonitor to receive and process the tunneled packets
 
AudioCodes tunneling is particularly useful for monitoring '''encrypted SIP over TLS traffic''' that uses Perfect Forward Secrecy (PFS) cipher suites like ECDHE, especially for Microsoft Teams Direct Routing trunks where the traffic between the SBC and Microsoft's servers is encrypted.


When an AudioCodes SBC terminates TLS connections, it can:
This method is ideal for:
* Decrypt the TLS-encrypted SIP signaling internally
* '''TLS 1.3 / ECDHE encrypted traffic''' - The SBC decrypts internally, no SSL key logger needed
* Forward the decrypted (clear-text) SIP packets to VoIPmonitor using the "debug call recording" feature
* '''MS Teams Direct Routing''' - SBC-to-Microsoft traffic uses PFS where private key decryption is impossible
* Eliminate the need for SSL key logger injection or private key access
* '''Cross-segment monitoring''' - When SBC and VoIPmonitor are on different network segments
* '''Closed appliances''' - When you cannot inject SSL key logger libraries


This approach is ideal when:
{{Note|1=For MS Teams Direct Routing, AudioCodes tunneling is often the most practical solution because it does not require access to Microsoft's private keys.}}
* 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
* Monitoring '''MS Teams Direct Routing''' trunks where the SBC-Traffic to Microsoft is TLS-encrypted and uses PFS


{{Note|1=For Microsoft Teams Direct Routing deployments, the AudioCodes tunneling method is often the most practical solution because it does not require access to Microsoft's private keys or injection of SSL key loggers into cloud infrastructure.}}
For other TLS decryption methods, see [[Tls|TLS Decryption Guide]].


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


== Step 1: Configure the AudioCodes SBC ==
=== Step 1: AudioCodes SBC ===


On the AudioCodes device, you need to enable the packet forwarding feature and configure it to send packets to the VoIPmonitor server.
On the AudioCodes device:
# Locate '''Debug Recording Server''' (or "Log server" / "Session mirroring")
# Set the IP address to your '''VoIPmonitor server IP'''
# Default port: '''UDP/TCP 925'''


'''Required Settings (AudioCodes Device):'''
Refer to AudioCodes documentation for model-specific steps.


Access the AudioCodes SBC configuration interface (web GUI or CLI) and locate the following setting:
=== Step 2: VoIPmonitor Server ===


* '''Debug Recording Server''' (or equivalent log/mirroring server setting)
Edit <code>/etc/voipmonitor.conf</code>:
* 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 (<code>/etc/voipmonitor.conf</code>):


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# The main switch that activates the AudioCodes tunnel processing feature
audiocodes = yes
audiocodes = yes
# 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
udp_port_audiocodes = 925
udp_port_audiocodes = 925
tcp_port_audiocodes = 925
tcp_port_audiocodes = 925
</syntaxhighlight>
</syntaxhighlight>


{{Note|1=Ensure your firewall allows incoming traffic on port 925 (or your custom port).}}
Restart the service:
 
After making changes, restart the service:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
systemctl restart voipmonitor
</syntaxhighlight>
</syntaxhighlight>


== Special Options for RTP/RTCP Handling ==
{{Note|1=Ensure your firewall allows incoming traffic on port 925.}}


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.
== RTP/RTCP Handling Options ==
 
These options control how VoIPmonitor handles RTP/RTCP packets when both tunneled and pure (non-encapsulated) packets are captured:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
Line 115: Line 79:
</syntaxhighlight>
</syntaxhighlight>


'''Option Values:'''
{| class="wikitable"
{| class="wikitable"
|-
|-
! Value !! Description
! Value !! Description !! Use Case
|-
|-
| <code>yes</code> || Enables processing of RTP/RTCP packets from the tunnel. '''Default value.'''
| <code>yes</code> || Process tunnel RTP/RTCP ('''default''') || Tunnel-only capture, no SPAN
|-
|-
| <code>no</code> || Disables processing of RTP/RTCP packets that arrive encapsulated in the AudioCodes tunnel.
| <code>no</code> || Ignore tunnel RTP/RTCP || Use only pure packets
|-
|-
| <code>only</code> || 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 will be ignored.
| <code>only</code> || Use '''only''' tunnel RTP/RTCP for all calls || Exclusively use tunnel data
|-
|-
| <code>only_for_audiocodes_sip</code> || Tunneled RTP/RTCP packets are assigned to a CDR '''only if''' the SIP signaling for that call was also delivered through the AudioCodes tunnel. '''Recommended for mixed-capture scenarios.'''
| <code>only_for_audiocodes_sip</code> || Use tunnel RTP only if SIP was also tunneled || '''Recommended for mixed capture''' (tunnel + SPAN)
|}
|}


== Common Scenarios and Troubleshooting ==
=== Mixed Traffic Configuration ===


=== Problem: Mixed RTP Streams ===
When capturing both AudioCodes tunnel and SPAN traffic, use:
 
When the sniffer captures traffic where RTP 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:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
Line 145: Line 102:
</syntaxhighlight>
</syntaxhighlight>


This configuration ensures that:
This ensures correct pairing between tunnel RTP and tunnel SIP, preventing stream mixing.
* 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
== Verification ==
* The correct association between tunnel RTP and tunnel SIP is maintained


=== When to Use Each Option ===
'''On the AudioCodes SBC:'''
<syntaxhighlight lang="bash">
tshark -i pkt1 port 925
</syntaxhighlight>


{| class="wikitable"
'''On the VoIPmonitor server:'''
|-
<syntaxhighlight lang="bash">
! Option !! Use Case
tcpdump -i any port 925 -w /var/tmp/capture.pcap
|-
</syntaxhighlight>
| <code>yes</code> (default) || You only capture from the AudioCodes tunnel and no other traffic
|-
| <code>only</code> || You want to EXCLUSIVELY use tunnel RTP for ALL calls (ignore any pure packets)
|-
| <code>no</code> || You want to ignore tunnel RTP and use only pure packets
|-
| <code>only_for_audiocodes_sip</code> || You have mixed traffic (tunnel + pure) and want to ensure correct pairing between tunnel RTP and tunnel SIP. '''Recommended for most mixed-capture scenarios.'''
|}


== Known Limitations ==
== Known Limitations ==
Line 169: Line 120:
=== IP Addresses Logged as 0.0.0.0 ===
=== IP Addresses Logged as 0.0.0.0 ===


In certain scenarios with AudioCodes tunneling, you may observe that some IP addresses are logged as <code>0.0.0.0</code> 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).
RTP packets may show <code>0.0.0.0</code> IP addresses in CDR because the AudioCodes encapsulation strips IP header information.


{| class="wikitable"
{| class="wikitable"
Line 175: Line 126:
! Aspect !! Details
! Aspect !! Details
|-
|-
| '''Behavior''' || The system logs <code>0.0.0.0</code> because the necessary IP address information is not present in the RTP packet structure as received.
| '''Impact''' || Display limitation only; SIP signaling IPs and call recording remain intact
|-
| '''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.
| '''Workaround''' || Use SIP History tab to see actual IPs from signaling packets
|-
|-
| '''Impact''' || While the IP column may show <code>0.0.0.0</code>, 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.
| '''Status''' || Expected behavior, not fixable via configuration
|}
|}


'''Workarounds:'''
== Performance Considerations ==
* 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:
 
# Check the current baseline: Monitor SBC CPU usage and network load before enabling tunneling
# Enable the tunneling feature via UDP on the SBC
# 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.
Monitor SBC CPU and network load before/after enabling tunneling:


== Verification ==
# Check baseline SBC metrics (CPU, network)
# Enable tunneling via UDP on the SBC
# Monitor metrics during normal operation


To verify that AudioCodes tunneling is working correctly:
{{Tip|1=You can test SBC impact without configuring VoIPmonitor listener to isolate SBC performance from sensor processing.}}


'''On the AudioCodes SBC:'''
== See Also ==
<syntaxhighlight lang="bash">
tshark -i pkt1 port 925
</syntaxhighlight>


'''On the VoIPmonitor server:'''
* [[Tls|TLS Decryption Guide]] - All TLS decryption methods
<syntaxhighlight lang="bash">
* [[Sniffing_modes|Deployment & Topology Guide]] - Alternative capture methods (SPAN, GRE, HEP)
tcpdump -i any port 925 -w /var/tmp/capture.pcap
* [[Sniffer_configuration|Sniffer Configuration]] - General sensor configuration
</syntaxhighlight>


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' AudioCodes tunneling allows AudioCodes SBCs to encapsulate and forward SIP/RTP packets to VoIPmonitor using the "Debug Recording Server" feature (default port UDP/TCP 925). Configuration requires: (1) SBC side - set Debug Recording Server to VoIPmonitor IP, (2) VoIPmonitor side - enable <code>audiocodes=yes</code> and set <code>udp_port_audiocodes/tcp_port_audiocodes=925</code>. For mixed capture scenarios (tunnel + SPAN), use <code>audiocodes_rtp=only_for_audiocodes_sip</code> to prevent stream mixing. Key TLS use case: AudioCodes SBC can decrypt TLS 1.3/ECDHE traffic internally and forward clear-text SIP, eliminating need for SSL key logger. Particularly useful for '''MS Teams Direct Routing''' deployements where traffic to Microsoft's servers is TLS-encrypted with PFS. '''Performance Impact:''' Monitor SBC CPU and network load before/after enabling tunneling to assess if tunneling affects the SBC. This test can be done without VoIPmonitor listener to isolate SBC performance. Known limitation: RTP IP addresses may show as 0.0.0.0 due to encapsulation format (expected behavior, not fixable).
'''Summary:''' AudioCodes tunneling allows AudioCodes SBCs to encapsulate and forward SIP/RTP packets to VoIPmonitor using the "Debug Recording Server" feature (default port UDP/TCP 925). Configuration: (1) SBC - set Debug Recording Server IP to VoIPmonitor server, (2) VoIPmonitor - enable <code>audiocodes=yes</code> and set <code>udp_port_audiocodes/tcp_port_audiocodes=925</code>. For mixed capture (tunnel + SPAN), use <code>audiocodes_rtp=only_for_audiocodes_sip</code> to prevent stream mixing. Key use case: Decrypt TLS 1.3/ECDHE traffic (including MS Teams Direct Routing) without SSL key logger. Known limitation: RTP IPs may show as 0.0.0.0 due to encapsulation format.


'''Keywords:''' audiocodes, tunnel, SBC, debug recording server, port 925, udp_port_audiocodes, tcp_port_audiocodes, audiocodes_rtp, only_for_audiocodes_sip, mixed streams, TLS decryption, ECDHE, PFS, TLS 1.3, encrypted SIP, 0.0.0.0 IP, SPAN alternative, MS Teams Direct Routing, Microsoft Teams, Teams Direct Routing, performance impact, SBC performance, CPU load, network load
'''Keywords:''' audiocodes, tunnel, SBC, debug recording server, port 925, udp_port_audiocodes, tcp_port_audiocodes, audiocodes_rtp, only_for_audiocodes_sip, mixed streams, TLS decryption, ECDHE, PFS, TLS 1.3, MS Teams Direct Routing, 0.0.0.0 IP, SPAN alternative


'''Key Questions:'''
'''Key Questions:'''
* How to configure AudioCodes SBC to forward packets to VoIPmonitor?
* How to configure AudioCodes SBC to forward packets to VoIPmonitor?
* What is the default port for AudioCodes tunneling (925)?
* What is the default port for AudioCodes tunneling?
* How to configure VoIPmonitor to receive AudioCodes tunneled data?
* How to configure VoIPmonitor to receive AudioCodes tunneled data?
* How to fix mixed RTP streams when capturing both AudioCodes tunnel and regular traffic?
* How to fix mixed RTP streams when capturing both AudioCodes tunnel and SPAN traffic?
* What is the difference between audiocodes_rtp options (yes, no, only, only_for_audiocodes_sip)?
* What is the difference between audiocodes_rtp options?
* Can AudioCodes tunneling decrypt TLS/ECDHE encrypted SIP without SSL key logger?
* Can AudioCodes tunneling decrypt TLS/ECDHE encrypted SIP?
* Why are IP addresses logged as 0.0.0.0 with AudioCodes tunneling?
* Why are IP addresses logged as 0.0.0.0 with AudioCodes tunneling?
* How to capture MS Teams Direct Routing traffic that is TLS-encrypted with PFS?
* How to monitor MS Teams Direct Routing traffic?
* Can AudioCodes SBC decrypt Microsoft Teams Direct Routing traffic?
* What is the performance impact of AudioCodes tunneling on the SBC?
* How to monitor AudioCodes SBC CPU and network load when using tunneling?

Latest revision as of 16:47, 8 January 2026

AudioCodes Tunneling

AudioCodes tunneling allows AudioCodes SBCs to encapsulate and forward SIP/RTP packets to VoIPmonitor via the "Debug Recording Server" feature, as an alternative to traditional SPAN port mirroring.

When to Use AudioCodes Tunneling

This method is ideal for:

  • TLS 1.3 / ECDHE encrypted traffic - The SBC decrypts internally, no SSL key logger needed
  • MS Teams Direct Routing - SBC-to-Microsoft traffic uses PFS where private key decryption is impossible
  • Cross-segment monitoring - When SBC and VoIPmonitor are on different network segments
  • Closed appliances - When you cannot inject SSL key logger libraries

ℹ️ Note: For MS Teams Direct Routing, AudioCodes tunneling is often the most practical solution because it does not require access to Microsoft's private keys.

For other TLS decryption methods, see TLS Decryption Guide.

Configuration

Step 1: AudioCodes SBC

On the AudioCodes device:

  1. Locate Debug Recording Server (or "Log server" / "Session mirroring")
  2. Set the IP address to your VoIPmonitor server IP
  3. Default port: UDP/TCP 925

Refer to AudioCodes documentation for model-specific steps.

Step 2: VoIPmonitor Server

Edit /etc/voipmonitor.conf: 

audiocodes = yes
udp_port_audiocodes = 925
tcp_port_audiocodes = 925

Restart the service: 

systemctl restart voipmonitor

ℹ️ Note: Ensure your firewall allows incoming traffic on port 925.

RTP/RTCP Handling Options

These options control how VoIPmonitor handles RTP/RTCP packets when both tunneled and pure (non-encapsulated) packets are captured: 

audiocodes_rtp  = yes | no | only | only_for_audiocodes_sip
audiocodes_rtcp = yes | no | only | only_for_audiocodes_sip
Value Description Use Case
yes Process tunnel RTP/RTCP (default) Tunnel-only capture, no SPAN
no Ignore tunnel RTP/RTCP Use only pure packets
only Use only tunnel RTP/RTCP for all calls Exclusively use tunnel data
only_for_audiocodes_sip Use tunnel RTP only if SIP was also tunneled Recommended for mixed capture (tunnel + SPAN)

Mixed Traffic Configuration

When capturing both AudioCodes tunnel and SPAN traffic, use: 

audiocodes          = yes
audiocodes_rtp      = only_for_audiocodes_sip
audiocodes_rtcp     = only_for_audiocodes_sip

This ensures correct pairing between tunnel RTP and tunnel SIP, preventing stream mixing.

Verification

On the AudioCodes SBC: 

tshark -i pkt1 port 925

On the VoIPmonitor server: 

tcpdump -i any port 925 -w /var/tmp/capture.pcap

Known Limitations

IP Addresses Logged as 0.0.0.0

RTP packets may show 0.0.0.0 IP addresses in CDR because the AudioCodes encapsulation strips IP header information.

Aspect Details
Impact Display limitation only; SIP signaling IPs and call recording remain intact
Workaround Use SIP History tab to see actual IPs from signaling packets
Status Expected behavior, not fixable via configuration

Performance Considerations

Monitor SBC CPU and network load before/after enabling tunneling:

  1. Check baseline SBC metrics (CPU, network)
  2. Enable tunneling via UDP on the SBC
  3. Monitor metrics during normal operation

💡 Tip: You can test SBC impact without configuring VoIPmonitor listener to isolate SBC performance from sensor processing.

See Also

AI Summary for RAG

Summary: AudioCodes tunneling allows AudioCodes SBCs to encapsulate and forward SIP/RTP packets to VoIPmonitor using the "Debug Recording Server" feature (default port UDP/TCP 925). Configuration: (1) SBC - set Debug Recording Server IP to VoIPmonitor server, (2) VoIPmonitor - enable audiocodes=yes and set udp_port_audiocodes/tcp_port_audiocodes=925. For mixed capture (tunnel + SPAN), use audiocodes_rtp=only_for_audiocodes_sip to prevent stream mixing. Key use case: Decrypt TLS 1.3/ECDHE traffic (including MS Teams Direct Routing) without SSL key logger. Known limitation: RTP IPs may show as 0.0.0.0 due to encapsulation format.

Keywords: audiocodes, tunnel, SBC, debug recording server, port 925, udp_port_audiocodes, tcp_port_audiocodes, audiocodes_rtp, only_for_audiocodes_sip, mixed streams, TLS decryption, ECDHE, PFS, TLS 1.3, MS Teams Direct Routing, 0.0.0.0 IP, SPAN alternative

Key Questions:

  • How to configure AudioCodes SBC to forward packets to VoIPmonitor?
  • What is the default port for AudioCodes tunneling?
  • How to configure VoIPmonitor to receive AudioCodes tunneled data?
  • How to fix mixed RTP streams when capturing both AudioCodes tunnel and SPAN traffic?
  • What is the difference between audiocodes_rtp options?
  • Can AudioCodes tunneling decrypt TLS/ECDHE encrypted SIP?
  • Why are IP addresses logged as 0.0.0.0 with AudioCodes tunneling?
  • How to monitor MS Teams Direct Routing traffic?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Audiocodes_tunneling&oldid=10045"