CDR & IPDR Analysis
Call Detail Records and Internet Protocol Detail Records reveal where a subscriber's device was, who it communicated with, and what internet sessions it carried — read correctly, and with clear-eyed limits.
What are CDR and IPDR?
A Call Detail Record (CDR) is a telecom operator's log of voice and SMS activity: calling and called party numbers, device and SIM identifiers (IMEI/IMSI), call type, duration, timestamp, and the cell tower that served the call — recorded as first and last cell ID, along with LAC/TAC and any roaming flag.
An Internet Protocol Detail Record (IPDR) instead logs data-session activity: the subscriber's private IP address, the NAT-translated public IP and port, destination ports, data volume transferred, and session start/end times. Because most operators use Carrier-Grade NAT, resolving an IPDR entry back to an individual subscriber usually requires the operator's NAT/port-translation session logs as well.
Together, CDR and IPDR let investigators build movement timelines, map communication networks, and correlate a specific internet session to a specific subscriber — always as a probabilistic, evidence-based reconstruction, never a GPS-precise pinpoint.
CDR
Who called whom, when, and which tower sector served the call.
IPDR
Which internet sessions a subscriber's connection carried, and how much data.
NAT Logs
The missing link that resolves a shared public IP back to one subscriber.
Step-by-Step Methodology
The sequence a careful examiner follows, in order.
- 1
Obtain records through proper legal process
Submit a court order, subpoena, or statutory law-enforcement request to the carrier's legal/compliance liaison unit, specifying the exact number/IMSI and date range needed — and request NAT session logs alongside any IPDR request.
- 2
Normalize the record schema
Different operators use different field names, time zones, and LAC/cell-ID numbering conventions — map every export into one common schema before analysis begins.
- 3
Build the tower-handover sequence
Sort CDR entries chronologically for the target IMSI/MSISDN and join each cell ID against the carrier's cell-site database to obtain tower coordinates and sector azimuth.
- 4
Model coverage as directional sectors
Plot each serving cell as an azimuth-bounded sector cone rather than a point radius, and use the overlap of consecutive sectors to bound a probable location corridor.
- 5
Resolve IPDR sessions to a subscriber
Join IPDR public-IP/port/timestamp entries against the operator's NAT session logs to recover the originating private IP, then cross-reference DHCP/session-authentication logs to attribute it to a specific subscriber connection.
- 6
Run co-location and common-contact analysis
Compare tower-handover histories and contact lists across multiple subjects of interest to surface overlapping locations or shared associates.
- 7
Flag SIM swaps and device changes
Track the IMEI–IMSI pairing across the full record set; an unexpected pairing change signals a SIM swap or device change worth independent investigation.
Tools Comparison
Sortable — click any column header.
Commands & Code
Copy-ready snippets used in real workflows.
import pandas as pd
cdr = pd.read_csv("carrier_a_cdr.csv", parse_dates=["timestamp"])
target = cdr[cdr["imsi"] == "404-45-1234567890123"].sort_values("timestamp")
towers = pd.read_csv("cell_site_db.csv") # cell_id, lat, lon, azimuth, beamwidth
merged = target.merge(towers, left_on="last_cell_id", right_on="cell_id", how="left")
merged[["timestamp", "b_party", "last_cell_id", "lat", "lon", "azimuth"]].to_csv(
"subject_tower_sequence.csv", index=False
)import pandas as pd
ipdr = pd.read_csv("ipdr_export.csv", parse_dates=["session_start", "session_end"])
nat_logs = pd.read_csv("nat_session_logs.csv", parse_dates=["timestamp"])
resolved = ipdr.merge(
nat_logs,
left_on=["public_ip", "public_port"],
right_on=["translated_ip", "translated_port"],
how="inner",
)
# resolved now includes the internal/private IP tied to the flagged public session
resolved[["session_start", "public_ip", "public_port", "private_ip", "subscriber_id"]]Sample Records
Illustrative dummy data showing record structure — not real subscriber data.
Sample Call Detail Record (CDR) — Illustrative Dummy Data
Structure only. All numbers, IMEIs, and identifiers below are fictional.
| A-Party | B-Party | IMEI | IMSI | Call Type | Duration | Date/Time | First Cell ID | Last Cell ID | LAC | Roaming |
|---|---|---|---|---|---|---|---|---|---|---|
| 9876500001 | 9876500099 | 356789012345670 | 404451234567890 | Voice | 00:04:12 | 2025-03-11 09:14:02 | 24501 | 24507 | 1102 | N |
| 9876500001 | 9876511122 | 356789012345670 | 404451234567890 | SMS | - | 2025-03-11 09:41:55 | 24507 | 24507 | 1102 | N |
| 9876500001 | 9876533344 | 356789012345670 | 404451234567890 | Voice | 00:12:47 | 2025-03-11 10:02:31 | 24507 | 24519 | 1103 | N |
| 9876500001 | 9876500099 | 356789012345670 | 404451234567890 | Voice | 00:00:38 | 2025-03-11 18:55:09 | 24601 | 24601 | 1109 | Y |
Sample Internet Protocol Detail Record (IPDR) — Illustrative Dummy Data
Structure only. IP addresses are RFC 5737 documentation ranges, not real allocations.
| Private IP | Public IP (NAT) | Src Port | Dst Port | Dest IP | Data Up (MB) | Data Down (MB) | Session Start | Session End |
|---|---|---|---|---|---|---|---|---|
| 10.42.6.113 | 203.0.113.44 | 51422 | 443 | 198.51.100.20 | 2.4 | 18.7 | 2025-03-11 09:10:00 | 2025-03-11 09:38:12 |
| 10.42.6.113 | 203.0.113.44 | 51890 | 443 | 198.51.100.77 | 0.6 | 3.1 | 2025-03-11 10:05:44 | 2025-03-11 10:11:02 |
| 10.42.6.113 | 203.0.113.44 | 52011 | 80 | 198.51.100.9 | 0.1 | 0.4 | 2025-03-11 10:12:15 | 2025-03-11 10:12:47 |
Legal & Ethical Considerations
- CDR/IPDR must be requested through valid legal process (court order, subpoena, or statutory authority) directed to the carrier's law-enforcement liaison unit.
- Retention windows are limited (often 90 days to a few years) — submit requests promptly once relevance is identified.
- Always request NAT/port-translation logs alongside any IPDR request; without them, a CGNAT-shared public IP cannot be attributed to an individual subscriber.
- Present location findings as a probable coverage sector, never a precise pinpoint, when testifying or reporting — overstating precision is a common and serious credibility risk.
Common Mistakes
- Treating a serving tower's coordinates as the handset's exact GPS location rather than a directional coverage-sector estimate.
- Requesting IPDR without also requesting NAT session logs, then finding the public IP alone insufficient to identify a specific subscriber.
- Ignoring the roaming flag, which can mean the serving tower belongs to a partner operator's network in a different location than assumed.
- Missing time-zone or daylight-saving mismatches between different operators' exports, which silently shifts every timestamp comparison.