# Cross-platform CDR normalization model

Canonical: https://warmtransfer.net/knowledge/cdr-normalization

Last verified: 2026-09-24

WarmTransfer's reading of the sources is that a cross-platform normalised leg key has to be composite (platform, tenant or cluster, native id), because Unified CM leg identifiers are unique only within a cluster and the Teams PSTN callId is not guaranteed unique[^10]. WarmTransfer's reading of the sources is that clearing causes cannot be compared across platforms without a mapping step, because Unified CM reports Q.850 plus Cisco-defined causes while Teams Direct Routing reports SIP final codes plus Microsoft subcodes; RFC 3326 lets SIP carry both but defines no one-to-one mapping[^9].

## Identity and Call Leg Models

In Cisco Unified CM 15 CDR files, cdrRecordType 1 marks an end call detail record, 2 marks a CMR record, and 0 (start record) is not used[^21]. Unified CM assigns a globalCallID_callId value to each call, and the CDR also carries globalCallID_callManagerId (the Unified CM node identity) and globalCallId_ClusterId (the cluster identity)[^16]. Unified CM origLegCallIdentifier and destLegCallIdentifier identify the originating and terminating legs of a call and are unique only within a cluster[^18]. Unified CM incomingProtocolCallRef and outgoingProtocolCallRef carry a globally unique protocol call reference, alphanumeric and truncated to 32 characters[^20].

In Microsoft Graph, a callRecord represents a peer-to-peer or group call and is created only after the call or meeting ends[^26]. Peer-to-peer Graph call records typically have 1 session, while group calls typically have at least 1 session per participant[^41]. The pstnCallLogRow callId is documented as not guaranteed to be unique, while the row id is a unique GUID[^36]. The id of a pstnCallLogRow or directRoutingLogRow cannot be used to retrieve a Graph callRecord, because these logs may reflect only part of a larger call or meeting[^40].

WarmTransfer's reading of the sources is that a cross-platform normalised leg key has to be composite (platform, tenant or cluster, native id), because Unified CM leg identifiers are unique only within a cluster and the Teams PSTN callId is not guaranteed unique[^10].

In Amazon Connect, a transfer creates a related contact: InitiationMethod includes TRANSFER and QUEUE_TRANSFER, InitialContactId names the first contact, and PreviousContactId names the preceding contact[^8]. The Amazon Connect ContactAssociationId is the root contactId, used as a unique identifier for all later contacts in a contact tree[^5].

## Timestamps and Duration Calculations

Unified CM 15 stores dateTimeOrigination, dateTimeConnect and dateTimeDisconnect as UTC[^22]. In Unified CM 15 CDRs, dateTimeConnect is zero when the call is never answered[^14]. Unified CM 15 CDR duration is the difference between connect time and disconnect time in seconds, and it remains zero if the call never connects[^15]. Unified CM generates a CDR for every call, including abandoned calls where a phone goes off hook and back on hook, in which case various fields are empty[^11]. Unified CM logs zero-duration calls only when the CDR Log Calls With Zero Duration Flag service parameter is enabled[^24]. Unified CM logs calls to busy or bad destinations as normal calls whose calling or called party cause field explains why the call did not connect, with Date/Time Connect left blank[^12].

In the Webex Calling detailed call history report, Start time and Answer time are given in UTC, and the answer time may be slightly after the start time[^58]. The Webex Calling detailed call history Duration field is the length of the call in seconds[^51].

A Microsoft Graph callRecord startDateTime (first user joined) and endDateTime (last user left) are ISO 8601 DateTimeOffset values that are always in UTC[^27]. In directRoutingLogRow, endDateTime exists only for fully established calls, failureDateTime exists only for calls that were not fully established, and startDateTime may equal the invite or failure time for failed and unanswered calls[^29]. In pstnCallLogRow, duration is connected time in seconds, and callDurationSource is operator when an Operator Connect operator supplied the duration and microsoft otherwise[^38].

The meaning of Amazon Connect InitiationTimestamp (UTC) depends on InitiationMethod: arrival for INBOUND, start of agent dialing for OUTBOUND, and transfer initiation for TRANSFER and QUEUE_TRANSFER[^7]. Amazon Connect DisconnectTimestamp is the UTC time the customer endpoint disconnected from the current contact, and in transfer scenarios the previous contact's DisconnectTimestamp marks when that contact ended[^6].

## Addressing, Participants, and Routing

Unified CM originalCalledPartyNumber is the number the call was first presented to before any forwarding, and finalCalledPartyNumber is the number the call was finally presented to[^19]. Unified CM lastRedirectDn holds the number of the next-to-last hop in a redirected call, and lastRedirectRedirectReason gives the last redirect reason from a separate code table[^17].

The Webex Calling detailed call history Original reason field records why a call was redirected, with values including Unconditional, NoAnswer, Deflection, TimeOfDay, UserBusy, FollowMe, CallQueue and HuntGroup[^54].

In directRoutingLogRow, callerNumber and calleeNumber are in E.164 format but might include other data[^30]. The pstnCallLogRow calleeNumber is documented as the number dialed in E.164, while callerNumber is described as the number that received the call for inbound calls or the number dialed for outbound calls[^35]. WarmTransfer's reading of the sources is that because the documented callerNumber semantics do not match the field name, a normaliser should derive A-party and B-party for Teams PSTN rows from callType direction together with sample data, not from the field names alone[^25]. The Graph callRecord organizer and participants properties are deprecated and documented to stop returning data on June 30, 2026, replaced by the organizer_v2 and participants_v2 relationships[^33]. WarmTransfer's reading of the sources is that because today (2026-09-24) is after the documented June 30, 2026 cutoff, a normaliser reading Graph callRecords should take party identities from participants_v2 and organizer_v2 and should not rely on the legacy properties[^32].

The Amazon Connect contact Channel is one of VOICE, CHAT, TASK or EMAIL[^4].

## Clearing Reason Normalization

Unified CM origCause_value and destCause_value carry the clearing reason as ITU-T Q.850 cause codes plus some Unified CM-defined codes[^13]. A Teams directRoutingLogRow reports the final SIP response code (finalSipCode, referencing RFC 3261), a Microsoft-specific callEndSubReason subcode, and a finalSipCodePhrase describing both[^31].

The SIP Reason header field (RFC 3326) carries a cause for a request under a protocol token, where SIP carries a SIP status code and Q.850 carries an ITU-T Q.850 cause value in decimal[^42]. RFC 3326 is a Proposed Standard updated by RFC 8606 and RFC 9366 and not obsoleted[^43]. RFC 6432 allows any SIP response except 100 (Trying) to carry a Reason header field with a Q.850 cause code[^44]. RFC 8606 updates RFC 3326 with a location parameter that carries the ISUP cause location in the SIP Reason header during PSTN-SIP interworking[^45]. RFC 9366 updates RFC 3326 to allow multiple Reason header values with the same protocol when that protocol defines what the multiplicity means; previously only one value per protocol was allowed[^46].

WarmTransfer's reading of the sources is that clearing causes cannot be compared across platforms without a mapping step, because Unified CM reports Q.850 plus Cisco-defined causes while Teams Direct Routing reports SIP final codes plus Microsoft subcodes; RFC 3326 lets SIP carry both but defines no one-to-one mapping[^9].

## Ingestion Pipelines and Retention

As of December 2025, the Webex Calling cdr_feed endpoint can query any 12-hour period between 5 minutes and 30 days ago, returning at most 12 hours of records per request, selected on the record's Start Time[^53]. The Webex Calling cdr_stream endpoint can be called about 1 minute after a call ends, returns up to 2 hours of records per request, selects on the time the record was written to the database, and backfills late records automatically[^59]. Reading Webex Calling CDRs through the API needs a token with the spark-admin:calling_cdr_read scope, and the administrator must hold the Webex Calling Detailed Call History API access role[^48].

Graph getPstnCalls takes fromDateTime and toDateTime in UTC, filters on call start time, and accepts a range of no more than 90 days[^34]. getPstnCalls supports only the application permission CallRecords.Read.All, not delegated permissions[^39]. getPstnCalls does not return information for Telstra calling plans and is not available in the China cloud operated by 21Vianet[^37]. A Graph callRecord carries a monotonically increasing version, and a higher-version record with the same id includes more data than a lower one[^28].

Amazon Connect delivers contact records at least once and may deliver them again when new information arrives, for example after contact attributes are updated[^3]. AWS adds new fields to the Amazon Connect contact record data model in a backward-compatible way and recommends that applications ignore fields they do not recognise[^2]. An Amazon Connect contact record is available for 24 months from the time the associated contact was initiated[^1]. In Webex Contact Center, end user phone numbers and their associated call detail records are retained for 1 year while a customer is active and for 1 year after termination[^60].

WarmTransfer's reading of the sources is that ingestion into a normalised CDR store should upsert on the native record key, not append, because Amazon Connect redelivers records, Graph callRecords are versioned upward and the Webex cdr_stream backfills late records[^47].

## See also

- [The Webex Calling Detailed Call History API](https://warmtransfer.net/knowledge/webex-calling-cdr)
- [What the Webex Calling detailed call history records](https://warmtransfer.net/knowledge/webex-calling-cdr-reference)
- [Amazon Connect contact records and streams](https://warmtransfer.net/knowledge/amazon-connect-data)
- [Teams call quality dashboard and analytics](https://warmtransfer.net/knowledge/teams-call-analytics)

## Applicability

Applies to: CDR normalisation model, Cisco Unified Communications Manager, Microsoft Teams, Microsoft Teams Phone, Amazon Web Services Amazon Connect, Cisco Webex Calling, Microsoft Teams Phone Direct Routing, IETF SIP, and Cisco Webex Contact Center. Deployments: cloud, on-premises, multi-tenant, and any. Sources checked 2026-09-24. getPstnCalls does not return information for Telstra calling plans and is not available in the China cloud operated by 21Vianet[^37].

## What remains uncertain

The Webex Calling cdr_feed and cdr_stream full field reference (Local/Remote call ID; session IDs; transfer related call ID; release time) is not covered by the sources below. Q.850 cause to SIP status interworking mapping (RFC 3398 and ITU-T Q.1912.5) is not covered by the sources below. Graph callRecords participants_v2 and organizer_v2 shape and actual post-cutoff behaviour is not covered by the sources below. Unified CM 15 Transferred Calls CDR example table (OnBehalfOf codes; globalCallID linkage) is not covered by the sources below. Another platform's call history and call log API data model is not covered by the sources below. Webex Contact Center interaction records vs Webex Calling CDR alignment is not covered by the sources below. Webex Calling CDR retention by license and API vs report retention is not covered by the sources below. Amazon Connect contact record per-field tables (Agent and Queue timestamps; DisconnectReason values) are not covered by the sources below.

## Sources

[^1]: An Amazon Connect contact record is available for 24 months from the time the associated contact was initiated. Source: [Data model for Connect Customer contact records](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html), Section Important things to know, second bullet. Checked 2026-09-24.
[^2]: AWS adds new fields to the Amazon Connect contact record data model in a backward-compatible way and recommends that applications ignore fields they do not recognise. Source: [Data model for Connect Customer contact records](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html), Section Important things to know, first bullet. Checked 2026-09-24.
[^3]: Amazon Connect delivers contact records at least once and may deliver them again when new information arrives, for example after contact attributes are updated. Source: [Data model for Connect Customer contact records](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html), Section Important things to know, second bullet. Checked 2026-09-24.
[^4]: The Amazon Connect contact Channel is one of VOICE, CHAT, TASK or EMAIL. Source: [Contact - Amazon Connect API Reference](https://docs.aws.amazon.com/connect/latest/APIReference/API_Contact.html), Contents, member Channel. Checked 2026-09-24.
[^5]: The Amazon Connect ContactAssociationId is the root contactId, used as a unique identifier for all later contacts in a contact tree. Source: [Contact - Amazon Connect API Reference](https://docs.aws.amazon.com/connect/latest/APIReference/API_Contact.html), Contents, member ContactAssociationId. Checked 2026-09-24.
[^6]: Amazon Connect DisconnectTimestamp is the UTC time the customer endpoint disconnected from the current contact, and in transfer scenarios the previous contact's DisconnectTimestamp marks when that contact ended. Source: [Contact - Amazon Connect API Reference](https://docs.aws.amazon.com/connect/latest/APIReference/API_Contact.html), Contents, member DisconnectTimestamp. Checked 2026-09-24.
[^7]: The meaning of Amazon Connect InitiationTimestamp (UTC) depends on InitiationMethod: arrival for INBOUND, start of agent dialing for OUTBOUND, and transfer initiation for TRANSFER and QUEUE_TRANSFER. Source: [Contact - Amazon Connect API Reference](https://docs.aws.amazon.com/connect/latest/APIReference/API_Contact.html), Contents, member InitiationTimestamp. Checked 2026-09-24.
[^8]: In Amazon Connect, a transfer creates a related contact: InitiationMethod includes TRANSFER and QUEUE_TRANSFER, InitialContactId names the first contact, and PreviousContactId names the preceding contact. Source: [Contact - Amazon Connect API Reference](https://docs.aws.amazon.com/connect/latest/APIReference/API_Contact.html), Contents, members InitiationMethod, InitialContactId, PreviousContactId. Checked 2026-09-24.
[^9]: Clearing causes cannot be compared across platforms without a mapping step, because Unified CM reports Q.850 plus Cisco-defined causes while Teams Direct Routing reports SIP final codes plus Microsoft subcodes; RFC 3326 lets SIP carry both but defines no one-to-one mapping (inferred). Source: [RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3326.html), Reason header protocol values; with cisco-cucm-cdr-field-descriptions-15 rows origCause_value/destCause_value and ms-graph-directroutinglogrow-resource row finalSipCode. Checked 2026-09-24.
[^10]: A cross-platform normalised leg key has to be composite (platform, tenant or cluster, native id), because Unified CM leg identifiers are unique only within a cluster and the Teams PSTN callId is not guaranteed unique (inferred). Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions, rows origLegCallIdentifier and globalCallId_ClusterId; see also ms-graph-pstncalllogrow-resource row callId. Checked 2026-09-24.
[^11]: Unified CM generates a CDR for every call, including abandoned calls where a phone goes off hook and back on hook, in which case various fields are empty. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01001.html), CDR Examples chapter, section Abandoned Calls. Checked 2026-09-24.
[^12]: Unified CM logs calls to busy or bad destinations as normal calls whose calling or called party cause field explains why the call did not connect, with Date/Time Connect left blank. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01001.html), CDR Examples chapter, section Calls with Busy or Bad Destinations. Checked 2026-09-24.
[^13]: Unified CM origCause_value and destCause_value carry the clearing reason as ITU-T Q.850 cause codes plus some Unified CM-defined codes. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows origCause_value, destCause_value. Checked 2026-09-24.
[^14]: In Unified CM 15 CDRs, dateTimeConnect is zero when the call is never answered. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, row dateTimeConnect. Checked 2026-09-24.
[^15]: Unified CM 15 CDR duration is the difference between connect time and disconnect time in seconds, and it remains zero if the call never connects. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, row duration. Checked 2026-09-24.
[^16]: Unified CM assigns a globalCallID_callId value to each call, and the CDR also carries globalCallID_callManagerId (the Unified CM node identity) and globalCallId_ClusterId (the cluster identity). Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows globalCallID_callManagerId, globalCallID_callId, globalCallId_ClusterId. Checked 2026-09-24.
[^17]: Unified CM lastRedirectDn holds the number of the next-to-last hop in a redirected call, and lastRedirectRedirectReason gives the last redirect reason from a separate code table. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows lastRedirectDn, lastRedirectRedirectReason. Checked 2026-09-24.
[^18]: Unified CM origLegCallIdentifier and destLegCallIdentifier identify the originating and terminating legs of a call and are unique only within a cluster. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows origLegCallIdentifier, destLegCallIdentifier. Checked 2026-09-24.
[^19]: Unified CM originalCalledPartyNumber is the number the call was first presented to before any forwarding, and finalCalledPartyNumber is the number the call was finally presented to. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows originalCalledPartyNumber, finalCalledPartyNumber. Checked 2026-09-24.
[^20]: Unified CM incomingProtocolCallRef and outgoingProtocolCallRef carry a globally unique protocol call reference, alphanumeric and truncated to 32 characters. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows IncomingProtocolCallRef, OutgoingProtocolCallRef. Checked 2026-09-24.
[^21]: In Cisco Unified CM 15 CDR files, cdrRecordType 1 marks an end call detail record, 2 marks a CMR record, and 0 (start record) is not used. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, row cdrRecordType. Checked 2026-09-24.
[^22]: Unified CM 15 stores dateTimeOrigination, dateTimeConnect and dateTimeDisconnect as UTC. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01010.html), CDR Field Descriptions table, rows dateTimeOrigination, dateTimeConnect, dateTimeDisconnect. Checked 2026-09-24.
[^23]: In the Unified CM transfer example (A calls B, B transfers to C), the system produces three CDRs: A to B, the B to C consultation, and A to C, with the first two marked Transfer (10) in the OnBehalfOf fields and the last marked by joinOnBehalfOf Transfer (10). Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CDR Examples](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/14/cucm_b_reporting-billing-administration-guide-14/cucm_b_reporting-and-billing-administration-guide_chapter_01001.html), CDR Examples chapter, section Transferred Calls. Checked 2026-09-24.
[^24]: Unified CM logs zero-duration calls only when the CDR Log Calls With Zero Duration Flag service parameter is enabled. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01001.html), CDR Examples chapter, section Abandoned Calls. Checked 2026-09-24.
[^25]: Because the documented callerNumber semantics do not match the field name, a normaliser should derive A-party and B-party for Teams PSTN rows from callType direction together with sample data, not from the field names alone (inferred). Source: [pstnCallLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-pstncalllogrow?view=graph-rest-1.0), Properties table, rows callerNumber, calleeNumber, callType. Checked 2026-09-24.
[^26]: A Microsoft Graph callRecord represents a peer-to-peer or group call and is created only after the call or meeting ends. Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Introductory paragraph under callRecord resource type. Checked 2026-09-24.
[^27]: callRecord startDateTime (first user joined) and endDateTime (last user left) are ISO 8601 DateTimeOffset values that are always in UTC. Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Properties table, rows startDateTime and endDateTime. Checked 2026-09-24.
[^28]: A Graph callRecord carries a monotonically increasing version, and a higher-version record with the same id includes more data than a lower one. Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Properties table, row version. Checked 2026-09-24.
[^29]: In directRoutingLogRow, endDateTime exists only for fully established calls, failureDateTime exists only for calls that were not fully established, and startDateTime may equal the invite or failure time for failed and unanswered calls. Source: [directRoutingLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-directroutinglogrow?view=graph-rest-1.0), Properties table, rows endDateTime, failureDateTime, startDateTime, inviteDateTime. Checked 2026-09-24.
[^30]: directRoutingLogRow callerNumber and calleeNumber are in E.164 format but might include other data. Source: [directRoutingLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-directroutinglogrow?view=graph-rest-1.0), Properties table, rows callerNumber and calleeNumber. Checked 2026-09-24.
[^31]: A Teams directRoutingLogRow reports the final SIP response code (finalSipCode, referencing RFC 3261), a Microsoft-specific callEndSubReason subcode, and a finalSipCodePhrase describing both. Source: [directRoutingLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-directroutinglogrow?view=graph-rest-1.0), Properties table, rows finalSipCode, callEndSubReason, finalSipCodePhrase. Checked 2026-09-24.
[^32]: Because today (2026-09-24) is after the documented June 30, 2026 cutoff, a normaliser reading Graph callRecords should take party identities from participants_v2 and organizer_v2 and should not rely on the legacy properties (inferred). Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Properties table, rows organizer (deprecated) and participants (deprecated). Checked 2026-09-24.
[^33]: The Graph callRecord organizer and participants properties are deprecated and documented to stop returning data on June 30, 2026, replaced by the organizer_v2 and participants_v2 relationships. Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Properties table, rows organizer (deprecated) and participants (deprecated). Checked 2026-09-24.
[^34]: Graph getPstnCalls takes fromDateTime and toDateTime in UTC, filters on call start time, and accepts a range of no more than 90 days. Source: [callRecord: getPstnCalls - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-1.0), Function parameters table and Important note. Checked 2026-09-24.
[^35]: The pstnCallLogRow calleeNumber is documented as the number dialed in E.164, while callerNumber is described as the number that received the call for inbound calls or the number dialed for outbound calls. Source: [pstnCallLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-pstncalllogrow?view=graph-rest-1.0), Properties table, rows calleeNumber and callerNumber. Checked 2026-09-24.
[^36]: The pstnCallLogRow callId is documented as not guaranteed to be unique, while the row id is a unique GUID. Source: [pstnCallLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-pstncalllogrow?view=graph-rest-1.0), Properties table, rows callId and id. Checked 2026-09-24.
[^37]: getPstnCalls does not return information for Telstra calling plans and is not available in the China cloud operated by 21Vianet. Source: [callRecord: getPstnCalls - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-1.0), Note under the introduction and the national cloud availability table. Checked 2026-09-24.
[^38]: pstnCallLogRow duration is connected time in seconds, and callDurationSource is operator when an Operator Connect operator supplied the duration and microsoft otherwise. Source: [pstnCallLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-pstncalllogrow?view=graph-rest-1.0), Properties table, rows duration and callDurationSource. Checked 2026-09-24.
[^39]: getPstnCalls supports only the application permission CallRecords.Read.All, not delegated permissions. Source: [callRecord: getPstnCalls - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-1.0), Permissions table. Checked 2026-09-24.
[^40]: The id of a pstnCallLogRow or directRoutingLogRow cannot be used to retrieve a Graph callRecord, because these logs may reflect only part of a larger call or meeting. Source: [pstnCallLogRow resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-pstncalllogrow?view=graph-rest-1.0), Introductory paragraphs of pstnCallLogRow resource type. Checked 2026-09-24.
[^41]: Peer-to-peer Graph call records typically have one session, while group calls typically have at least one session per participant. Source: [callRecord resource type - Microsoft Graph v1.0](https://learn.microsoft.com/en-us/graph/api/resources/callrecords-callrecord?view=graph-rest-1.0), Relationships table, row sessions. Checked 2026-09-24.
[^42]: The SIP Reason header field (RFC 3326) carries a cause for a request under a protocol token, where SIP carries a SIP status code and Q.850 carries an ITU-T Q.850 cause value in decimal. Source: [RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3326.html), Reason header field definition: protocol values and cause parameter, plus the example header. Checked 2026-09-24.
[^43]: RFC 3326 is a Proposed Standard updated by RFC 8606 and RFC 9366 and not obsoleted. Source: [Information on RFC 3326](https://www.rfc-editor.org/info/rfc3326), Updated by metadata field. Checked 2026-09-24.
[^44]: RFC 6432 allows any SIP response except 100 (Trying) to carry a Reason header field with a Q.850 cause code. Source: [RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses](https://www.rfc-editor.org/rfc/rfc6432.html), Normative statement on Reason header in responses (section number not captured). Checked 2026-09-24.
[^45]: RFC 8606 (June 2019) updates RFC 3326 with a location parameter that carries the ISUP cause location in the SIP Reason header during PSTN-SIP interworking. Source: [Information on RFC 8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field](https://www.rfc-editor.org/info/rfc8606), Abstract and Updates metadata field. Checked 2026-09-24.
[^46]: RFC 9366 updates RFC 3326 to allow multiple Reason header values with the same protocol when that protocol defines what the multiplicity means; previously only one value per protocol was allowed. Source: [Information on RFC 9366: Multiple SIP Reason Header Field Values](https://www.rfc-editor.org/info/rfc9366), Abstract. Checked 2026-09-24.
[^47]: Ingestion into a normalised CDR store should upsert on the native record key, not append, because Amazon Connect redelivers records, Graph callRecords are versioned upward and the Webex cdr_stream backfills late records (inferred). Source: [Data model for Connect Customer contact records](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html), Important things to know, second bullet; with ms-graph-callrecord-resource row version and webex-dev-blog-understanding-calling-cdr-apis cdr_stream section. Checked 2026-09-24.
[^48]: Reading Webex Calling CDRs through the API needs a token with the spark-admin:calling_cdr_read scope, and the administrator must hold the Webex Calling Detailed Call History API access role. Source: [Understanding the Webex Calling CDR APIs](https://developer.webex.com/blog/understanding-the-webex-calling-cdr-apis), Prerequisites/authorization text. Checked 2026-09-24.
[^49]: Webex Calling detailed call history records carry a Correlation ID that ties together the multiple call legs of one call session. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table row Correlation ID. Checked 2026-09-24.
[^50]: The Webex Calling detailed call history Direction field uses ORIGINATING for outbound and TERMINATING for inbound. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table row Direction. Checked 2026-09-24.
[^51]: The Webex Calling detailed call history Duration field is the length of the call in seconds. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table row Duration. Checked 2026-09-24.
[^52]: As described in January 2023, the Webex Detailed Call History API returned only calls completed between 48 hours ago and 5 minutes ago. Source: [Webex Detailed Call History API](https://developer.webex.com/blog/webex-detailed-call-history-api), Body text on query time window. Checked 2026-09-24.
[^53]: As of December 2025, the Webex Calling cdr_feed endpoint can query any 12-hour period between 5 minutes and 30 days ago, returning at most 12 hours of records per request, selected on the record's Start Time. Source: [Understanding the Webex Calling CDR APIs](https://developer.webex.com/blog/understanding-the-webex-calling-cdr-apis), Section comparing cdr_feed and cdr_stream. Checked 2026-09-24.
[^54]: The Webex Calling detailed call history Original reason field records why a call was redirected, with values including Unconditional, NoAnswer, Deflection, TimeOfDay, UserBusy, FollowMe, CallQueue and HuntGroup. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table row Original reason. Checked 2026-09-24.
[^55]: In Webex Calling detailed call history, Calling number and Called number are defined relative to the user on the leg: on an outgoing call the calling number is the user's number, and on an incoming call the called number is the user's number. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table rows Calling number and Called number. Checked 2026-09-24.
[^56]: Webex Calling detailed call history produces one record per call leg, so a single call session can yield several records. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table rows Correlation ID and Answered. Checked 2026-09-24.
[^57]: The help article gives Webex Calling detailed call history report access of 400 days with Pro Pack and 89 days without it, and at most 31 days per report. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report section, report availability text. Checked 2026-09-24.
[^58]: In the Webex Calling detailed call history report, Start time and Answer time are given in UTC, and the answer time may be slightly after the start time. Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Webex Calling detailed call history report, field table rows Start time and Answer time. Checked 2026-09-24.
[^59]: The Webex Calling cdr_stream endpoint can be called about one minute after a call ends, returns up to 2 hours of records per request, selects on the time the record was written to the database, and backfills late records automatically. Source: [Understanding the Webex Calling CDR APIs](https://developer.webex.com/blog/understanding-the-webex-calling-cdr-apis), Section comparing cdr_feed and cdr_stream. Checked 2026-09-24.
[^60]: End user phone numbers and their associated call detail records are retained for 1 year while a customer is active and for 1 year after termination. Source: [Cisco Webex Contact Center Service Offer Disclosure](https://trustportal.cisco.com/c/dam/r/ctp/docs/privacydatasheet/collaboration/webex-contact-center-offer-disclosure.pdf), Table 1 Customer Content, Host and Usage Information row. Checked 2026-09-05.