cdr analytics · published

Cross-platform CDR normalization model

Verified 2026-09-24 · 60 sources · tier 1–2 · 1 superseded

Also known as CDR.

Superseded guidance: 1 source has been superseded by newer ones.

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

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

Referenced by

Sources

  1. 1
    An 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
  2. 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.
    Data model for Connect Customer contact records · Section Important things to know, first bullet · Checked 2026-09-24
  3. 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.
    Data model for Connect Customer contact records · Section Important things to know, second bullet · Checked 2026-09-24
  4. 4
    The Amazon Connect contact Channel is one of VOICE, CHAT, TASK or EMAIL.
    Contact - Amazon Connect API Reference · Contents, member Channel · Checked 2026-09-24
  5. 5
    The 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
  6. 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.
    Contact - Amazon Connect API Reference · Contents, member DisconnectTimestamp · Checked 2026-09-24
  7. 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.
    Contact - Amazon Connect API Reference · Contents, member InitiationTimestamp · Checked 2026-09-24
  8. 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.
    Contact - Amazon Connect API Reference · Contents, members InitiationMethod, InitialContactId, PreviousContactId · Checked 2026-09-24
  9. 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
    RFC 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
  10. 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
    Call 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
  11. 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.
  12. 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.
    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
  13. 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.
    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
  14. 14
    In Unified CM 15 CDRs, dateTimeConnect is zero when the call is never answered.
  15. 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.
  16. 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).
    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
  17. 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.
    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
  18. 18
    Unified 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
  19. 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.
    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
  20. 20
    Unified 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
  21. 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.
  22. 22
    Unified 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
  23. 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).
  24. 24
    Unified CM logs zero-duration calls only when the CDR Log Calls With Zero Duration Flag service parameter is enabled.
  25. 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
    pstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows callerNumber, calleeNumber, callType · Checked 2026-09-24
  26. 26
    A 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
  27. 27
    callRecord 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
  28. 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.
    callRecord resource type - Microsoft Graph v1.0 · Properties table, row version · Checked 2026-09-24
  29. 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.
    directRoutingLogRow resource type - Microsoft Graph v1.0 · Properties table, rows endDateTime, failureDateTime, startDateTime, inviteDateTime · Checked 2026-09-24
  30. 30
    directRoutingLogRow 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
  31. 31
    A 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
  32. 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
    callRecord resource type - Microsoft Graph v1.0 · Properties table, rows organizer (deprecated) and participants (deprecated) · Checked 2026-09-24
  33. 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.
    callRecord resource type - Microsoft Graph v1.0 · Properties table, rows organizer (deprecated) and participants (deprecated) · Checked 2026-09-24
  34. 34
    Graph 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
  35. 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.
    pstnCallLogRow resource type - Microsoft Graph v1.0 · Properties table, rows calleeNumber and callerNumber · Checked 2026-09-24
  36. 36
    The 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
  37. 37
    getPstnCalls 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
  38. 38
    pstnCallLogRow 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
  39. 39
    getPstnCalls supports only the application permission CallRecords.Read.All, not delegated permissions.
    callRecord: getPstnCalls - Microsoft Graph v1.0 · Permissions table · Checked 2026-09-24
  40. 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.
    pstnCallLogRow resource type - Microsoft Graph v1.0 · Introductory paragraphs of pstnCallLogRow resource type · Checked 2026-09-24
  41. 41
    Peer-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
  42. 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.
    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
  43. 43
    RFC 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
  44. 44
    RFC 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
  45. 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.
  46. 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.
  47. 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
    Data 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
  48. 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.
    Understanding the Webex Calling CDR APIs · Prerequisites/authorization text · Checked 2026-09-24
  49. 49
    Webex 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
  50. 50
    The 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
  51. 51
    The 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
  52. 52
    As 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
  53. 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.
    Understanding the Webex Calling CDR APIs · Section comparing cdr_feed and cdr_stream · Checked 2026-09-24
  54. 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.
    Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report, field table row Original reason · Checked 2026-09-24
  55. 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.
    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. 56
    Webex 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
  57. 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.
    Reports for Your Cloud Collaboration Portfolio · Webex Calling detailed call history report section, report availability text · Checked 2026-09-24
  58. 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.
    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. 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.
    Understanding the Webex Calling CDR APIs · Section comparing cdr_feed and cdr_stream · Checked 2026-09-24
  60. 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.
    Cisco Webex Contact Center Service Offer Disclosure · Table 1 Customer Content, Host and Usage Information row · Checked 2026-09-05

Documents

tier 1 standards and regulators

Information on RFC 3326

RFC Editor · 2002-12-01 · accessed 2026-09-24

tier 1 standards and regulators

Information on RFC 8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field

RFC Editor · 2019-06-01 · accessed 2026-09-24

tier 1 standards and regulators

Information on RFC 9366: Multiple SIP Reason Header Field Values

RFC Editor · accessed 2026-09-24

tier 1 standards and regulators

RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2002-12-01 · accessed 2026-09-24

tier 1 standards and regulators

RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses

IETF / RFC Editor · 2011-11-01 · accessed 2026-09-24

tier 2 current vendor documentation

Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions

Cisco Systems, Inc. (Webex Help Center) · accessed 2026-09-15

tier 2 current vendor documentation

Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CDR Examples

Cisco Systems · 2026-04-09 · accessed 2026-09-24

tier 2 current vendor documentation

Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CDR Examples

Cisco Systems · 2026-04-09 · accessed 2026-09-24

tier 2 current vendor documentation

callRecord resource type - Microsoft Graph v1.0

Microsoft · 2024-05-28 · accessed 2026-09-24

tier 2 current vendor documentation

callRecord: getPstnCalls - Microsoft Graph v1.0

Microsoft · 2024-10-10 · accessed 2026-09-24

tier 2 current vendor documentation

Cisco Webex Contact Center Service Offer Disclosure

Cisco Systems, Inc. (Cisco Trust Portal) · 2026-06-01 · accessed 2026-09-05

tier 2 current vendor documentation

Contact - Amazon Connect API Reference

Amazon Web Services · accessed 2026-09-24

tier 2 current vendor documentation

Data model for Connect Customer contact records

Amazon Web Services · accessed 2026-09-24

tier 2 current vendor documentation

directRoutingLogRow resource type - Microsoft Graph v1.0

Microsoft · 2024-05-23 · accessed 2026-09-24

tier 2 current vendor documentation

pstnCallLogRow resource type - Microsoft Graph v1.0

Microsoft · 2024-05-23 · accessed 2026-09-24

tier 2 current vendor documentation

Reports for Your Cloud Collaboration Portfolio

Cisco Systems, Inc. (Webex Help Center) · 2026-09-15 · accessed 2026-09-16

tier 2 current vendor documentation

Understanding the Webex Calling CDR APIs

Cisco Webex for Developers · 2025-12-17 · accessed 2026-09-24

tier 2 current vendor documentation

Webex Detailed Call History API

Cisco Webex for Developers · 2023-01-23 · accessed 2026-09-24

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}
}