Call Detail Record - CDR

From VoIPmonitor.org
Revision as of 23:06, 4 January 2026 by Admin (talk | contribs) (Add PRICE column documentation showing how to enable and view billing costs)


This guide is a comprehensive tour of the main Call Detail Record (CDR) interface in the VoIPmonitor GUI. It explains every section, button, and feature, from searching for calls to analyzing their quality in detail.

What is a CDR?

A Call Detail Record (CDR) is a data record containing information about a single telephone call or communication session. In VoIPmonitor, each CDR captures:

  • Call timing (start time, duration, connect time)
  • Participant information (caller/called numbers, IP addresses, SIP agents)
  • Signaling details (SIP messages, final response codes)
  • Quality metrics (MOS scores, packet loss, jitter/delay statistics)
  • Media information (codecs, RTP stream data)

The CDR view is the primary interface for searching, filtering, and analyzing these records.

Understanding the Main CDR View

The CDR view is the central hub for exploring your captured call data. It is comprised of three main sections:

  1. The CDR List: The main table displaying a paginated list of all finished calls.
  2. The Button Panel: A toolbar for accessing key functions like filtering, charting, and exporting.
  3. The Dashboard: A set of panels at the bottom that provide aggregated statistics for the currently displayed data.

The main CDR View, showing the CDR list and the dashboard panels below.

The CDR List

This section details the components of the main call list, from the title bar to the information in each row.

Title Bar & Date Filter

At the very top, the title bar displays the current time range for the calls being shown. You can click on the dates to quickly change the filter.

Note: This quick date filter can be disabled on a per-user basis in user settings.

The title bar with a quick date range filter.

Button Panel

This toolbar provides access to the most important interactive features.

The main button panel for interacting with the CDR list.

1. Filter Form

This is the most powerful feature for finding specific calls. Clicking this button opens a detailed search form with two main tabs.

Common Tab

This tab contains filters for general call attributes and participant information.

The "Common" tab in the advanced filter form.

  • Participant Filters: Search by Caller/Called Number, Caller/Called IP, or Caller/Called Domain. You can use the % character as a wildcard (e.g., 222% finds all numbers starting with 222). You can also use commas for multiple values and ! for negation (e.g., 222%, !223%).
  • Group Filters: Search by pre-defined Caller/Called Groups or IP Groups.
  • Call Attribute Filters: Filter by Call Duration, Codec, or PDD (Post-Dial Delay) ranges.
  • SIP Filters: Filter by Last SIP Response Code (e.g., 487, or 4% for all 4xx codes), SIP Agent (phone type/firmware), or Call-ID.
  • Other Filters: You can also filter by the Sensor that captured the call or find all Interrupted calls (those without a proper BYE).
RTP Tab

This tab allows you to find calls based on specific Quality of Service (QoS) metrics. This is essential for troubleshooting audio quality issues.

The "RTP" tab for filtering by quality metrics.

  • RTCP Metrics: Filter by Jitter or Fraction Loss values reported by the endpoints themselves via RTCP.
  • MOS: Find all calls with a Mean Opinion Score lower than a specified value.
  • PDV (Jitter): Find calls with a specific number of Packet Delay Variation events in different time intervals (e.g., find all calls with at least 10 packets delayed by more than 120ms).
  • Loss: Find calls based on patterns of consecutive packet loss.
  • Silence & Clipping: If enabled on the sensor, you can find calls with a certain percentage of silence or a specific number of clipped audio frames. See Silence_detection for configuration details.

2. Quick Filters

This dropdown provides shortcuts for finding problematic calls (e.g., "Worst Calls by Loss") and gives you access to your saved filter templates.

The Quick Filters menu.

3. Menu

This menu contains administrative actions.

  • Delete: Delete selected CDRs and their associated files (PCAPs, audio).
  • Export CSV: Export the current view of CDRs to a CSV file.

The Menu button with Delete and Export options.

4. Charts

This button opens a window for adding overlay charts to your current CDR view, allowing you to correlate data visually. This feature is covered in detail in the Charts guide.

The Charts button and its window.

CDR List Columns

Each column in the CDR list provides key information and can be used for quick sorting.

An overview of the main columns in the CDR list.

Customizing Column Visibility

You can show or hide columns in the CDR list based on your preferences. This is useful when:

  • You want to reduce visual clutter and focus on specific information
  • Certain columns contain data that is causing performance issues
  • Your display has limited screen space

To hide or show columns in the CDR view:

  1. Locate the column header area at the top of the table
  2. Click on the column visibility icon (typically a column or grid icon)
  3. Uncheck columns you want to hide, check columns you want to show
  4. The view will update immediately with your selection

Your column visibility preferences are stored in the GUI configuration (saved in the MySQL custom_config table) and persist across sessions.

Column Reference

A single row represents a single call.

A single CDR row with all its columns.

Column Description
ID The unique identifier for the call record (primary key in the database)
Sensor ID The name of the sensor that captured the call (see Sensors configuration)
Datetime The start time of the call (from first INVITE)
Duration (PDD) / Codec Total call duration, Post-Dial Delay, and the audio codec used
Caller/Called Info Number, Name, SIP IP, and SIP Agent. The red flag indicates which party sent the BYE first
Last Response The final SIP response code and text for the call
RTP IP Addresses Source IP addresses for the caller and callee RTP streams

Quality Metric Columns

The quality columns provide at-a-glance indicators of call quality:

  • MOS Column : Shows three parametric MOS scores based on different jitter buffer simulations:
    • F1: Fixed 50ms jitter buffer
    • F2: Fixed 200ms jitter buffer
    • Adapt: Adaptive jitter buffer (up to 500ms)
  • Delay Column : Color-coded distribution of packet delay variation (jitter) events. See Jitter Analysis for interpretation.
  • Loss Column : Color-coded distribution of consecutive packet loss events. Red indicates burst losses which are more harmful to quality.
  • RTCP Column : Maximum jitter and fraction loss as reported by the endpoints themselves via RTCP.
  • PRICE Column: Shows billing costs calculated by the billing system. This column is hidden by default and must be enabled manually. To enable the PRICE column:
    1. Click the dropdown menu on the first column (the column header with the ID or the column selection icon)
    2. Select PRICE from the list of available columns
    3. The PRICE column will now display Customer (C:) and Operator (O:) prices for each call

Note: Costs only appear if billing is configured (see Billing Configuration) and "Enable by addresses" or "Enable by numbers" is checked in the billing settings. The "Default customer billing" checkbox ensures customer prices are applied to all source IPs by default, which may be useful for reporting purposes.

Understanding Sniffer vs RTCP Packet Loss

VoIPmonitor provides two different packet loss metrics measured from different network locations:

Interpretation Guide:

Scenario Likely Cause
RTCP loss > Sniffer loss Network issue after the sniffer (Wi-Fi, last-mile, endpoint network)
Sniffer loss > RTCP loss Monitoring point dropping packets (CPU overload, interface saturation) or RTCP reports not captured
High RTCP loss, good MOS Packet Loss Concealment (PLC) effectively hiding scattered losses

Troubleshooting tips:

  • Trust RTCP loss for user experience issues - it reflects what the device actually received
  • Use sniffer loss for network health monitoring in the segment you control
  • When RTCP loss is higher, investigate the network path between sniffer and endpoint

Commands Column

The Commands column contains:

  • Download links for PCAP and WAV files
  • Embedded audio player to listen directly in the browser

The CDR Detail View

Clicking the [+] icon at the beginning of any CDR row expands it to show the detailed analysis view with multiple tabs.

The expanded CDR detail view with its tabs.

Summary Tab

This tab provides a detailed breakdown of call information, RTP statistics, and a full chronological log of all SIP messages for the call.

The Summary tab provides a deep dive into a single call.

The Call Quality Graph

The most prominent feature is the detailed quality graph, which plots packet delay and loss over the duration of the call.

The detailed call quality graph.

  • Each vertical line represents a group of packets
  • The colored dot represents the median delay (jitter)
  • Packet loss is shown as red lines at the top of the graph
  • Clock Drift: A graph that steadily climbs or descends indicates a clock drift issue between the sending device and the sensor, not necessarily a network problem

Received Packets (Caller / Called)

The "received packets" field in the CDR grid shows how many RTP packets the VoIPmonitor sniffer received FROM that endpoint, not how many packets the endpoint itself received.

Field Meaning
Caller → Received Packets Number of RTP packets VoIPmonitor received from the caller (A-leg)
Called → Received Packets Number of RTP packets VoIPmonitor received from the called party (B-leg)

One-Way Stream Example: If you have a unidirectional RTP stream (caller → called only):

  • Caller column shows: 73 packets (VoIPmonitor received 73 packets from the caller's stream)
  • Called column shows: empty (VoIPmonitor received no packets from the called party)

This indicates that VoIPmonitor sniffed packets sent by the caller, but did not capture any return stream from the called party.

Bidirectional Stream: Both columns will have values when VoIPmonitor receives RTP packets from both endpoints.

SIP History Tab

This tab provides a powerful, Wireshark-like view of the call's signaling.

  • Sequence Diagram: A visual representation of the SIP message flow between endpoints
  • Message Table: A text-based list of all SIP messages and RTP streams
  • Packet Detail: Clicking on any message opens a window with a fully decoded tree view of the packet, similar to Wireshark

The SIP sequence diagram.

The fully decoded packet detail window.

Legs by CID / Legs by Header Tabs

These tabs are used to find related call legs in complex call scenarios. For detailed information about call correlation, see Merging_or_correlating_multiple_call_legs.

  • Legs by CID: Finds other calls that share the same numeric part of the From header tag within a few seconds of the original call. This is useful for finding the other legs of a call that was routed through a PBX.
  • Legs by Header: A more powerful method that correlates calls based on a shared identifier in a custom SIP header (configured by match_header in voipmonitor.conf). This is essential for tracing a single call across multiple proxies or SBCs where the Call-ID changes at each hop.

Charts Tab

This tab displays a set of predefined and custom charts applied specifically to the context of the selected call (e.g., showing trends for the caller number). This allows for quick historical analysis without leaving the CDR view.

The Charts tab within the CDR detail view.

Map Tab

This tab attempts to geolocate the source and destination SIP IP addresses on a world map using a GeoIP service.

The Map tab showing GeoIP locations.

The Dashboard Panels

The panels at the bottom of the screen provide aggregated views of the data currently displayed in the CDR list.

The dashboard panels provide aggregated statistics.

  • Group By: You can group the data by Last SIP Response, Codec, SIP IP, or predefined IP Groups
  • Charts: The middle section displays a pie chart of the grouped data
  • Filters: Clicking on any item in the group grid (e.g., clicking on the "200 OK" response) will instantly apply it as a filter to the main CDR list above

Related Documentation

AI Summary for RAG

Summary: The CDR (Call Detail Record) View is the primary interface in VoIPmonitor GUI for analyzing captured calls. It consists of three main sections: the CDR List (paginated call records), Button Panel (filtering and export tools), and Dashboard (aggregated statistics). The Filter Form provides powerful search capabilities through two tabs: Common (participant info, duration, SIP filters) and RTP (quality metrics like MOS, jitter, packet loss). Each CDR row displays call timing, participant information, and quality metrics including three MOS scores (F1, F2, Adaptive) based on different jitter buffer simulations. The RTCP column shows endpoint-reported metrics; when RTCP loss is higher than sniffer loss, it indicates network issues after the monitoring point (Wi-Fi, last-mile). The Detail View (accessed by expanding a row) includes the Summary tab with quality graphs, SIP History tab with Wireshark-like packet analysis, and Legs by CID/Header tabs for correlating related call segments across systems.

Keywords: CDR, call detail record, GUI, filter, search, MOS, jitter, PDV, packet loss, quality metrics, SIP history, sequence diagram, call legs, correlation, dashboard, group by, RTCP, sniffer loss, endpoint loss

Key Questions:

  • How do I use the CDR view to find specific calls?
  • How can I filter calls by quality metrics (MOS, jitter, loss)?
  • What do the MOS F1, F2, and Adaptive scores mean?
  • How do I view the SIP message flow for a call?
  • What is the difference between Legs by CID and Legs by Header?
  • How do I correlate related call legs across multiple systems?
  • What does the quality graph show and what indicates clock drift?
  • How do I use the dashboard panels to analyze call statistics?
  • What is the difference between sniffer loss and RTCP loss?
  • Why might RTCP loss be higher than sniffer loss?