Cellular Call Detail Records: Android CallLog Provider & CDR Forensics

In telecommunications auditing, mobile forensics, and threat investigations, call event telemetry provides vital chronological and relational evidence. While smartphone users interact with call histories through native dialer interfaces, telephony events operate across two radically different architectural layers: the local operating system content provider on the device, and the carrier core network's authoritative Call Detail Records (CDRs). Understanding the schema of Android's CallLog.Calls provider, examining carrier Mobile Switching Center (MSC) generation mechanics, and analyzing cryptographically signed STIR/SHAKEN attestation headers allows investigators to detect caller ID spoofing and uncover deleted communications.

Android CallLog Provider: Schema and SQLite Architecture

On Android devices, telephony history is managed by the Telephony provider and exposed through the android.provider.CallLog.Calls content provider. The underlying records reside in an encrypted SQLite database typically located at /data/data/com.android.providers.contacts/databases/calllog.db (or within contacts2.db on legacy firmware) within the calls table:

Carrier Network CDR Generation at the MSC and VLR

When a cellular call connects across 4G LTE VoLTE or 5G New Radio networks, the call session is managed by the IP Multimedia Subsystem (IMS) core and the Mobile Switching Center (MSC) paired with the Visitor Location Register (VLR). At the conclusion of every session, the billing and mediation gateways generate a Call Detail Record containing critical network metadata:

* A-Party & B-Party Identifiers: Records the originating MSISDN, IMSI (International Mobile Subscriber Identity), and handset IMEI (International Mobile Equipment Identity).

* Cell Global Identity (CGI) Routing: Records the First CGI (the specific radio tower and antenna azimuth sector serving the phone at call initiation) and the Last CGI (the cell sector serving the phone when the call disconnected). Comparing First CGI to Last CGI reveals user physical movement during the call.

* Release Cause Codes (ISUP Q.850): Encodes the exact technical reason the call terminated (e.g., Code 16 "Normal Clearing", Code 17 "User Busy", Code 19 "No Answer from User", or Code 41 "Temporary Radio Congestion").

STIR/SHAKEN Cryptographic Verification Framework

To combat widespread caller ID spoofing orchestrated by VoIP robocall engines, telecommunications regulators established the STIR/SHAKEN framework (codified under IETF RFC 8224 and ATIS-1000074). Operating within SIP signaling headers, the originating carrier cryptographically signs a JSON Web Token known as a Personal Assertion Token (PASSporT):

// Example: SIP Identity Header encapsulating a STIR/SHAKEN PASSporT JWT
Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0cy5jYXJyaWVyLm5ldC9jZXJ0LnBlbSJ9.
eyJhdHRlc3QiOiJBIiwiaWNpIjoiZjhhOTM4MmMtMGQzOS00ODc3LWJmN2QtYmI2M2QwMjRkYTI1Iiwib3JpZyI6eyJ0biI6IisxMjEyNTU1MDEwMCJ9LCJyZXN0IjoiIiwidGltZXN0YW1wIjoxNzkwNTQxMjAwLCJkZXN0Ijp7InRuIjpbIisxMjEyNTU1MDIwMCJdfX0.
MEQCIG1xY2y0P...signature...;info=<https://certs.carrier.net/cert.pem>;alg=ES256

The SHAKEN PASSporT declares three authoritative attestation levels:

* Attestation A (Full): The carrier authenticates the customer and cryptographically certifies that the customer owns and is authorized to use the asserted caller ID number.

* Attestation B (Partial): The carrier authenticates the origination customer (e.g., an enterprise PBX trunk) but cannot certify that the customer has verified ownership of the specific outgoing caller ID.

* Attestation C (Gateway): The call originated outside the verified network (such as an international transit gateway); the carrier can only verify where it received the call, with zero guarantees regarding caller identity validity.

Starting in Android 11, the operating system inspects these SIP identity verdicts, populating the Calls.VERIFICATION_STATUS column. Modern dialer applications display a visual green checkmark for Attestation A calls while flagging unverified calls as potential spam.

Forensic Discrepancy Reconciliation

Digital investigators compare physical device extractions of calllog.db against subpoenaed carrier CDRs to uncover intentional anti-forensic tampering:

1. Phantom Deletions: If carrier CDRs document an outgoing call lasting 14 minutes at 23:15 UTC, but calllog.db contains zero records for that timeframe, the discrepancy proves deliberate record scrubbing by the device user.

2. IMSI/IMEI Swapping: CDR records track hardware identifiers. If a target's phone number suddenly connects from an unknown IMEI during a critical incident window, investigators establish that the subscriber swapped their SIM card into a secondary burner device.

3. VoIP Bypass Logging: Over-the-top communication tools (such as Signal or WhatsApp) route calls through local data sockets rather than carrier baseband channels. Forensics teams must extract secondary app databases (e.g., WhatsApp msgstore.db) to reconcile IP voice calls absent from traditional carrier CDRs.

Cell Site Location Information (CSLI) and Spatial Reconstructions

In addition to timestamps and phone numbers, carrier CDR files provide Cell Site Location Information (CSLI). Every cellular tower consists of multiple directional antenna sectors (typically three sectors per tower, each spanning a 120-degree beamwidth). When a call initiates, the network logs the exact Cell Global Identity (CGI) serving the mobile subscriber.

By pairing the tower's geographic coordinates and antenna azimuth heading with the carrier's Timing Advance (TA) or Round Trip Time (RTT) measurements, forensic analysts compute a circular wedge boundary. In LTE networks, each Timing Advance unit represents approximately 78 meters of distance from the radio tower. By plotting sequential TA values across the duration of a multi-minute phone conversation, investigators reconstruct the subscriber's physical travel velocity and direction along major highway corridors.

Android Runtime Interception: ContentObserver and CallScreeningService

For enterprise telematics and automated threat prevention engines, monitoring call logs at runtime requires integrating specialized operating system APIs:

* ContentObserver Telemetry: Applications register an Android ContentObserver listening to changes on CallLog.Calls.CONTENT_URI. Whenever a call completes, the telephony provider dispatches an asynchronous change notification, allowing monitoring agents to immediately ingest duration and verification status.

* CallScreeningService Integration: Introduced in modern Android releases, the CallScreeningService contract allows security engines to inspect incoming calls before the phone even rings. The service receives the incoming phone number, evaluates local threat intelligence lists, checks STIR/SHAKEN cryptographic attestation headers, and autonomously instructs the baseband to reject the call, silence the ringer, or skip the call log entirely.