Audiocodes tunneling: Difference between revisions

From VoIPmonitor.org
(Add troubleshooting section for mixed RTP streams and AI Summary for RAG)
(Rewrite: konsolidace a vylepšení struktury - stručnější, přidán See Also)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
== VoIPmonitor Configuration for Audiocodes Tunneling ==
= 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.
[[Category:Configuration]]
[[Category:Sensors]]


=== Basic Tunneling Options ===
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.
To enable the processing of data from an Audiocodes tunnel, the following options must be enabled in the sniffer's configuration file (<code>voipmonitor.conf</code>).


audiocodes          = yes
<kroki lang="mermaid">
# The main switch that activates the Audiocodes tunnel processing feature.
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart LR
    subgraph Network["VoIP Network"]
        Phone1["SIP Phone"]
        Phone2["SIP Phone"]
    end


# Next, define the ports on which the sniffer will listen for incoming tunneled data.
    subgraph SBC["AudioCodes SBC"]
# Choose the transport protocol (UDP/TCP) used by your Audiocodes SBC and enable the corresponding option.
        TLS["TLS Termination"]
udp_port_audiocodes  = 925
        Debug["Debug Recording<br/>Server Feature"]
tcp_port_audiocodes  = 925
    end


=== Special Options for RTP/RTCP Handling ===
    subgraph VM["VoIPmonitor Server"]
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.
        Sniffer["Sniffer<br/>Port 925"]
        DB[(Database)]
    end


audiocodes_rtp  = no/yes/only/only_for_audiocodes_sip
    Phone1 -->|"SIP/TLS + RTP"| TLS
audiocodes_rtcp = no/yes/only/only_for_audiocodes_sip
    Phone2 -->|"SIP/TLS + RTP"| TLS
    TLS --> Debug
    Debug -->|"Decrypted<br/>SIP/RTP<br/>UDP/TCP 925"| Sniffer
    Sniffer --> DB
</kroki>


== When to Use AudioCodes Tunneling ==


The values for these options mean:
This method is ideal for:
* <code>no</code> - Disables processing of RTP/RTCP packets that arrive encapsulated in the Audiocodes tunnel.
* '''TLS 1.3 / ECDHE encrypted traffic''' - The SBC decrypts internally, no SSL key logger needed
* <code>yes</code> - Enables processing of RTP/RTCP packets from the tunnel. This is the '''default''' value.
* '''MS Teams Direct Routing''' - SBC-to-Microsoft traffic uses PFS where private key decryption is impossible
* <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, if also seen by the sniffer, will be ignored.
* '''Cross-segment monitoring''' - When SBC and VoIPmonitor are on different network segments
* <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.
* '''Closed appliances''' - When you cannot inject SSL key logger libraries


=== Common Scenarios and Troubleshooting ===
{{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.}}


'''Problem: Mixed RTP Streams (RTP + SRTP)'''
For other TLS decryption methods, see [[Tls|TLS Decryption Guide]].


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.
== Configuration ==


'''Solution:'''
=== Step 1: AudioCodes SBC ===


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 <code>voipmonitor.conf</code>:
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'''
 
Refer to AudioCodes documentation for model-specific steps.
 
=== Step 2: VoIPmonitor Server ===
 
Edit <code>/etc/voipmonitor.conf</code>:
 
<syntaxhighlight lang="ini">
audiocodes = yes
udp_port_audiocodes = 925
tcp_port_audiocodes = 925
</syntaxhighlight>
 
Restart the service:
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
</syntaxhighlight>
 
{{Note|1=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:
 
<syntaxhighlight lang="ini">
audiocodes_rtp  = yes | no | only | only_for_audiocodes_sip
audiocodes_rtcp = yes | no | only | only_for_audiocodes_sip
</syntaxhighlight>
 
{| class="wikitable"
|-
! Value !! Description !! Use Case
|-
| <code>yes</code> || Process tunnel RTP/RTCP ('''default''') || Tunnel-only capture, no SPAN
|-
| <code>no</code> || Ignore tunnel RTP/RTCP || Use only pure packets
|-
| <code>only</code> || Use '''only''' tunnel RTP/RTCP for all calls || Exclusively use tunnel data
|-
| <code>only_for_audiocodes_sip</code> || 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:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
[general]
audiocodes          = yes
audiocodes          = yes
audiocodes_rtp      = only_for_audiocodes_sip
audiocodes_rtp      = only_for_audiocodes_sip
Line 43: 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
 
'''On the AudioCodes SBC:'''
<syntaxhighlight lang="bash">
tshark -i pkt1 port 925
</syntaxhighlight>
 
'''On the VoIPmonitor server:'''
<syntaxhighlight lang="bash">
tcpdump -i any port 925 -w /var/tmp/capture.pcap
</syntaxhighlight>
 
== Known Limitations ==


'''When to Use Each Option:'''
=== IP Addresses Logged as 0.0.0.0 ===


* Use <code>yes</code> (default) when you only capture from the AudioCodes tunnel and no other traffic
RTP packets may show <code>0.0.0.0</code> IP addresses in CDR because the AudioCodes encapsulation strips IP header information.
* Use <code>only</code> when you want to EXCLUSIVELY use tunnel RTP for ALL calls (ignore any pure packets)
 
* Use <code>no</code> when you want to ignore tunnel RTP and use only pure packets
{| class="wikitable"
* Use <code>only_for_audiocodes_sip</code> 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)
|-
! 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:
 
# Check baseline SBC metrics (CPU, network)
# Enable tunneling via UDP on the SBC
# Monitor metrics during normal operation
 
{{Tip|1=You can test SBC impact without configuring VoIPmonitor listener to isolate SBC performance from sensor processing.}}
 
== See Also ==
 
* [[Tls|TLS Decryption Guide]] - All TLS decryption methods
* [[Sniffing_modes|Deployment & Topology Guide]] - Alternative capture methods (SPAN, GRE, HEP)
* [[Sniffer_configuration|Sniffer Configuration]] - General sensor configuration


== AI Summary for RAG ==
== 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.


'''Keywords:''' audiocodes, tunnel, SBC, rtp, rtcp, mixed streams, only_for_audiocodes_sip, encapsulation, span port, mirroring
'''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, MS Teams Direct Routing, 0.0.0.0 IP, SPAN alternative


'''Key Questions:'''
'''Key Questions:'''
* How to configure VoIPmonitor for AudioCodes tunneling?
* How to configure AudioCodes SBC to forward packets to VoIPmonitor?
* How to fix mixed RTP streams when capturing both AudioCodes tunnel and regular traffic?
* What is the default port for AudioCodes tunneling?
* What is the difference between audiocodes_rtp options (yes, no, only, only_for_audiocodes_sip)?
* How to configure VoIPmonitor to receive AudioCodes tunneled data?
* How to prevent RTP/RTCP packet duplication when both tunnel and pure traffic are visible?
* How to fix mixed RTP streams when capturing both AudioCodes tunnel and SPAN traffic?
* When should I use audiocodes_rtp = only_for_audiocodes_sip?
* 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?

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"