Cross-platform CDR normalization model
Verified 2026-09-24 · 60 sources · tier 1–2 · 1 superseded
Also known as CDR.
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
- What the Webex Calling detailed call history records
- Amazon Connect contact records and streams
- Teams call quality dashboard and 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.
See also
Feeds
- The Webex Calling Detailed Call History API — Inbound edge: webex-calling-cdr feeds this topic. Vendor CDR shapes (Webex Calling detailed call history) must be normalised before cross-platform analysis.
Referenced by
- The Webex Calling Detailed Call History API — Vendor CDR shapes must be normalised before analysis
- Asterisk CDR and CEL recordsstub — Queued 2026-10-15; Cross-platform CDR normalization model is the nearest existing coverage
- Call accounting and telecom expense managementstub — Call accounting and chargeback depend on normalizing per-platform call records before rating costs
- Exporting contact center data to a data warehouse — Once exported; vendor records (Connect contact records; Genesys conversation details; Webex CSR/CAR; CXone Data Share views) need normalising into a common interaction and agent-session model.
- How contact center platforms define service level and abandon and handle time differently — per-leg contact records versus per-call records change handled and transferred counts
- Pulling call detail records from CPaaS APIsstub — Queued 2026-10-14; Cross-platform CDR normalization model is the nearest existing coverage
- RingCentral call log and analytics APIsstub — Queued 2026-10-14; Cross-platform CDR normalization model is the nearest existing coverage
- SMDR call records from legacy PBXsstub — Queued 2026-10-14; Cross-platform CDR normalization model is the nearest existing coverage
- Zoom Phone call history and call logs APIstub — Queued 2026-10-14; Cross-platform CDR normalization model is the nearest existing coverage
Sources
- 1An Amazon Connect contact record is available for 24 months from the time the associated contact was initiated.Data model for Connect Customer contact records · Section Important things to know, second bullet · Checked 2026-09-24
- 2AWS 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.Data model for Connect Customer contact records · Section Important things to know, first bullet · Checked 2026-09-24
- 3Amazon Connect delivers contact records at least once and may deliver them again when new information arrives, for example after contact attributes are updated.Data model for Connect Customer contact records · Section Important things to know, second bullet · Checked 2026-09-24
- 4The Amazon Connect contact Channel is one of VOICE, CHAT, TASK or EMAIL.Contact - Amazon Connect API Reference · Contents, member Channel · Checked 2026-09-24
- 5The Amazon Connect ContactAssociationId is the root contactId, used as a unique identifier for all later contacts in a contact tree.Contact - Amazon Connect API Reference · Contents, member ContactAssociationId · Checked 2026-09-24
- 6Amazon 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.Contact - Amazon Connect API Reference · Contents, member DisconnectTimestamp · Checked 2026-09-24
- 7The 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.Contact - Amazon Connect API Reference · Contents, member InitiationTimestamp · Checked 2026-09-24
- 8In 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.Contact - Amazon Connect API Reference · Contents, members InitiationMethod, InitialContactId, PreviousContactId · Checked 2026-09-24
- 9Clearing 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.inferredRFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP) · 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
- 10A 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.inferredCall Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions, rows origLegCallIdentifier and globalCallId_ClusterId; see also ms-graph-pstncalllogrow-resource row callId · Checked 2026-09-24
- 11Unified 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.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples · CDR Examples chapter, section Abandoned Calls · Checked 2026-09-24
- 12Unified 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.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples · CDR Examples chapter, section Calls with Busy or Bad Destinations · Checked 2026-09-24
- 13Unified CM origCause_value and destCause_value carry the clearing reason as ITU-T Q.850 cause codes plus some Unified CM-defined codes.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows origCause_value, destCause_value · Checked 2026-09-24
- 14In Unified CM 15 CDRs, dateTimeConnect is zero when the call is never answered.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, row dateTimeConnect · Checked 2026-09-24
- 15Unified CM 15 CDR duration is the difference between connect time and disconnect time in seconds, and it remains zero if the call never connects.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, row duration · Checked 2026-09-24
- 16Unified 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).Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows globalCallID_callManagerId, globalCallID_callId, globalCallId_ClusterId · Checked 2026-09-24
- 17Unified 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.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows lastRedirectDn, lastRedirectRedirectReason · Checked 2026-09-24
- 18Unified CM origLegCallIdentifier and destLegCallIdentifier identify the originating and terminating legs of a call and are unique only within a cluster.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows origLegCallIdentifier, destLegCallIdentifier · Checked 2026-09-24
- 19Unified 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.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows originalCalledPartyNumber, finalCalledPartyNumber · Checked 2026-09-24
- 20Unified CM incomingProtocolCallRef and outgoingProtocolCallRef carry a globally unique protocol call reference, alphanumeric and truncated to 32 characters.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows IncomingProtocolCallRef, OutgoingProtocolCallRef · Checked 2026-09-24
- 21In 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.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, row cdrRecordType · Checked 2026-09-24
- 22Unified CM 15 stores dateTimeOrigination, dateTimeConnect and dateTimeDisconnect as UTC.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions · CDR Field Descriptions table, rows dateTimeOrigination, dateTimeConnect, dateTimeDisconnect · Checked 2026-09-24
- 23In 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).Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CDR Examples · CDR Examples chapter, section Transferred Calls · Checked 2026-09-24
- 24Unified CM logs zero-duration calls only when the CDR Log Calls With Zero Duration Flag service parameter is enabled.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples · CDR Examples chapter, section Abandoned Calls · Checked 2026-09-24
- 25Because 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.inferredpstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows callerNumber, calleeNumber, callType · Checked 2026-09-24
- 26A Microsoft Graph callRecord represents a peer-to-peer or group call and is created only after the call or meeting ends.callRecord resource type - Microsoft Graph v1.0 · Introductory paragraph under callRecord resource type · Checked 2026-09-24
- 27callRecord startDateTime (first user joined) and endDateTime (last user left) are ISO 8601 DateTimeOffset values that are always in UTC.callRecord resource type - Microsoft Graph v1.0 · Properties table, rows startDateTime and endDateTime · Checked 2026-09-24
- 28A Graph callRecord carries a monotonically increasing version, and a higher-version record with the same id includes more data than a lower one.callRecord resource type - Microsoft Graph v1.0 · Properties table, row version · Checked 2026-09-24
- 29In 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.directRoutingLogRow resource type - Microsoft Graph v1.0 · Properties table, rows endDateTime, failureDateTime, startDateTime, inviteDateTime · Checked 2026-09-24
- 30directRoutingLogRow callerNumber and calleeNumber are in E.164 format but might include other data.directRoutingLogRow resource type - Microsoft Graph v1.0 · Properties table, rows callerNumber and calleeNumber · Checked 2026-09-24
- 31A Teams directRoutingLogRow reports the final SIP response code (finalSipCode, referencing RFC 3261), a Microsoft-specific callEndSubReason subcode, and a finalSipCodePhrase describing both.directRoutingLogRow resource type - Microsoft Graph v1.0 · Properties table, rows finalSipCode, callEndSubReason, finalSipCodePhrase · Checked 2026-09-24
- 32Because 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.inferredcallRecord resource type - Microsoft Graph v1.0 · Properties table, rows organizer (deprecated) and participants (deprecated) · Checked 2026-09-24
- 33The 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.callRecord resource type - Microsoft Graph v1.0 · Properties table, rows organizer (deprecated) and participants (deprecated) · Checked 2026-09-24
- 34Graph getPstnCalls takes fromDateTime and toDateTime in UTC, filters on call start time, and accepts a range of no more than 90 days.callRecord: getPstnCalls - Microsoft Graph v1.0 · Function parameters table and Important note · Checked 2026-09-24
- 35The 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.pstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows calleeNumber and callerNumber · Checked 2026-09-24
- 36The pstnCallLogRow callId is documented as not guaranteed to be unique, while the row id is a unique GUID.pstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows callId and id · Checked 2026-09-24
- 37getPstnCalls does not return information for Telstra calling plans and is not available in the China cloud operated by 21Vianet.callRecord: getPstnCalls - Microsoft Graph v1.0 · Note under the introduction and the national cloud availability table · Checked 2026-09-24
- 38pstnCallLogRow duration is connected time in seconds, and callDurationSource is operator when an Operator Connect operator supplied the duration and microsoft otherwise.pstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows duration and callDurationSource · Checked 2026-09-24
- 39getPstnCalls supports only the application permission CallRecords.Read.All, not delegated permissions.callRecord: getPstnCalls - Microsoft Graph v1.0 · Permissions table · Checked 2026-09-24
- 40The 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.pstnCallLogRow resource type - Microsoft Graph v1.0 · Introductory paragraphs of pstnCallLogRow resource type · Checked 2026-09-24
- 41Peer-to-peer Graph call records typically have one session, while group calls typically have at least one session per participant.callRecord resource type - Microsoft Graph v1.0 · Relationships table, row sessions · Checked 2026-09-24
- 42The 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.RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP) · Reason header field definition: protocol values and cause parameter, plus the example header · Checked 2026-09-24
- 43RFC 3326 is a Proposed Standard updated by RFC 8606 and RFC 9366 and not obsoleted.Information on RFC 3326 · Updated by metadata field · Checked 2026-09-24
- 44RFC 6432 allows any SIP response except 100 (Trying) to carry a Reason header field with a Q.850 cause code.RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses · Normative statement on Reason header in responses (section number not captured) · Checked 2026-09-24
- 45RFC 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.Information on RFC 8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field · Abstract and Updates metadata field · Checked 2026-09-24
- 46RFC 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.Information on RFC 9366: Multiple SIP Reason Header Field Values · Abstract · Checked 2026-09-24
- 47Ingestion 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.inferredData model for Connect Customer contact records · 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
- 48Reading 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.Understanding the Webex Calling CDR APIs · Prerequisites/authorization text · Checked 2026-09-24
- 49Webex Calling detailed call history records carry a Correlation ID that ties together the multiple call legs of one call session.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table row Correlation ID · Checked 2026-09-24
- 50The Webex Calling detailed call history Direction field uses ORIGINATING for outbound and TERMINATING for inbound.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table row Direction · Checked 2026-09-24
- 51The Webex Calling detailed call history Duration field is the length of the call in seconds.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table row Duration · Checked 2026-09-24
- 52As described in January 2023, the Webex Detailed Call History API returned only calls completed between 48 hours ago and 5 minutes ago.Webex Detailed Call History API · Body text on query time window · Checked 2026-09-24
- 53As 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.Understanding the Webex Calling CDR APIs · Section comparing cdr_feed and cdr_stream · Checked 2026-09-24
- 54The 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.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table row Original reason · Checked 2026-09-24
- 55In 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.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table rows Calling number and Called number · Checked 2026-09-24
- 56Webex Calling detailed call history produces one record per call leg, so a single call session can yield several records.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table rows Correlation ID and Answered · Checked 2026-09-24
- 57The 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.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report section, report availability text · Checked 2026-09-24
- 58In 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.Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table rows Start time and Answer time · Checked 2026-09-24
- 59The 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.Understanding the Webex Calling CDR APIs · Section comparing cdr_feed and cdr_stream · Checked 2026-09-24
- 60End 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.Cisco Webex Contact Center Service Offer Disclosure · Table 1 Customer Content, Host and Usage Information row · Checked 2026-09-05
Documents
Information on RFC 3326
Information on RFC 8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field
Information on RFC 9366: Multiple SIP Reason Header Field Values
RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)
RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses
Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions
Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CDR Examples
Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples
callRecord resource type - Microsoft Graph v1.0
callRecord: getPstnCalls - Microsoft Graph v1.0
Cisco Webex Contact Center Service Offer Disclosure
Contact - Amazon Connect API Reference
Data model for Connect Customer contact records
directRoutingLogRow resource type - Microsoft Graph v1.0
pstnCallLogRow resource type - Microsoft Graph v1.0
Reports for Your Cloud Collaboration Portfolio
Understanding the Webex Calling CDR APIs
Webex Detailed Call History API
Cite this page
APA
WarmTransfer. (2026, September 24). Cross-platform CDR normalization model. WarmTransfer. https://warmtransfer.net/knowledge/cdr-normalization
BibTeX
@misc{warmtransfer-cdr-normalization,
title = {Cross-platform CDR normalization model},
author = {{WarmTransfer}},
year = {2026},
url = {https://warmtransfer.net/knowledge/cdr-normalization},
note = {Verified 2026-09-24}
}