Labs · early, not fully tested. Check what it produces before you rely on it.
{"version":"2026-09-22.3","entries":[{"code":"final-failure","topicSlug":"sip-response-codes","topicTitle":"SIP response codes and failure interpretation","articleHref":"/knowledge/sip-response-codes","askHref":"/?topic=sip-response-codes","claims":[{"id":"sip-six-response-classes","text":"SIP response codes fall into 6 classes: 1xx provisional 2xx success 3xx redirection 4xx request failure 5xx server failure and 6xx global failure.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-six-response-classes","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 21","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"wxc-reroute-sip-triggers","text":"Rerouting to another trunk is triggered by SIP responses 401, 470, 480 and 606 when no provisional 18x response preceded them, by all other 4xx responses except 403, 404, 410, 413, 484 and 486, by all 5xx responses, and by a 12 second SIP timeout.","status":"fact","verifiedAt":"2026-09-04","href":"/knowledge/claims/wxc-reroute-sip-triggers","sources":[{"id":"cisco-pdf-preferred-architecture-webex-calling","title":"Cisco Preferred Architecture for Webex Calling — Design Overview","publisher":"Cisco Systems, Inc. (CTG TME)","tier":2,"tierLabel":"current vendor documentation","locator":"Trunks and Route Groups, page 21","href":"/knowledge/sources/cisco-pdf-preferred-architecture-webex-calling"}]},{"id":"sip-final-response-ends-the-transaction","text":"A 1xx response is provisional and every other class is final and a final response completes the transaction.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-final-response-ends-the-transaction","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 sections 17 and 21","href":"/knowledge/sources/rfc-3261-sip"}]}]},{"code":"sip-488-codec-context","topicSlug":"sip-response-codes","topicTitle":"SIP response codes and failure interpretation","articleHref":"/knowledge/sip-response-codes","askHref":"/?topic=sip-response-codes","claims":[{"id":"sip-488-not-acceptable-here","text":"A 488 Not Acceptable Here means the request may succeed elsewhere and applies only to the resource addressed and may carry a body describing the media capabilities the responder does support.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-488-not-acceptable-here","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 21, 488 Not Acceptable Here","href":"/knowledge/sources/rfc-3261-sip"}]}]},{"code":"missing-ack","topicSlug":"sip-transactions-dialogs","topicTitle":"SIP transactions dialogs and call setup","articleHref":"/knowledge/sip-transactions-dialogs","askHref":"/?topic=sip-transactions-dialogs","claims":[{"id":"sip-invite-ack-2xx","text":"For every 2xx response the UAC receives to an INVITE, the UAC core generates a separate ACK sent directly by the transport layer rather than the transaction layer, reusing the INVITE's CSeq number but with the method changed to ACK.","status":"fact","verifiedAt":"2026-09-04","href":"/knowledge/claims/sip-invite-ack-2xx","sources":[{"id":"rfc-3261","title":"SIP: Session Initiation Protocol (RFC 3261)","publisher":"IETF","tier":1,"tierLabel":"standards and regulators","locator":"section-13.2.2.4","href":"/knowledge/sources/rfc-3261"}]},{"id":"siptx-retransmission-is-a-transport-property","text":"An INVITE is not retransmitted over a reliable transport and retransmissions cease altogether once a provisional response arrives.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siptx-retransmission-is-a-transport-property","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 17.1.1.2","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"siptx-ack-for-2xx-is-its-own-transaction","text":"The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siptx-ack-for-2xx-is-its-own-transaction","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 6 terminology and section 13","href":"/knowledge/sources/rfc-3261-sip"}]}]},{"code":"request-retransmission","topicSlug":"sip-transactions-dialogs","topicTitle":"SIP transactions dialogs and call setup","articleHref":"/knowledge/sip-transactions-dialogs","askHref":"/?topic=sip-transactions-dialogs","claims":[{"id":"siprt-no-request-retransmission-on-a-stream-transport","text":"Because all four retransmission timers are 0 on a reliable transport, a capture taken over TCP or TLS contains no request retransmission at all, so the absence of retransmissions in such a capture is a property of the transport and is not evidence about the network or the peer.","status":"inference","verifiedAt":"2026-09-15","href":"/knowledge/claims/siprt-no-request-retransmission-on-a-stream-transport","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 17 timer table, transport column","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"siprt-transport-decides-whether-a-timer-runs","text":"Four timers are scoped to an unreliable transport and become 0 on a reliable one: A and E do not retransmit at all and D I J and K wait 0 seconds instead of their unreliable values.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siprt-transport-decides-whether-a-timer-runs","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 appendix A, the timer table","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"siptx-retransmission-is-a-transport-property","text":"An INVITE is not retransmitted over a reliable transport and retransmissions cease altogether once a provisional response arrives.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siptx-retransmission-is-a-transport-property","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 17.1.1.2","href":"/knowledge/sources/rfc-3261-sip"}]}]},{"code":"incomplete-dialog","topicSlug":"sip-transactions-dialogs","topicTitle":"SIP transactions dialogs and call setup","articleHref":"/knowledge/sip-transactions-dialogs","askHref":"/?topic=sip-transactions-dialogs","claims":[{"id":"siptx-server-transaction-dies-at-the-2xx","text":"The INVITE server transaction is destroyed as soon as it passes a 2xx final response to the transport so retransmitting that response is the responsibility of the user agent rather than the transaction layer.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siptx-server-transaction-dies-at-the-2xx","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 13.3.1.4","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"sip-final-response-ends-the-transaction","text":"A 1xx response is provisional and every other class is final and a final response completes the transaction.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-final-response-ends-the-transaction","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 sections 17 and 21","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"siptx-ack-for-2xx-is-its-own-transaction","text":"The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/siptx-ack-for-2xx-is-its-own-transaction","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 6 terminology and section 13","href":"/knowledge/sources/rfc-3261-sip"}]}]},{"code":"connected-under-one-second","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-duration-is-zero-below-one-second","text":"The duration field is zero both when a call never connects and when it connects for less than one second, so a duration of zero is not evidence that a call was never answered.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-duration-is-zero-below-one-second","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, duration","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]},{"id":"cucmcdr-duration-is-connect-to-disconnect","text":"The duration field is the difference between the connect time and the disconnect time in seconds and so measures connected time rather than the life of the call.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-duration-is-connect-to-disconnect","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, duration","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]},{"id":"cucmcdr-zero-means-never-connected","text":"The connect time field holds 0 when the call never connects and the disconnect time field is set even when the call never connects.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-zero-means-never-connected","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, dateTimeConnect and dateTimeDisconnect","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]}]},{"code":"cause-unspecified-catch-all","topicSlug":"q850-cause-codes","topicTitle":"ITU-T Q.850 call clearing cause values","articleHref":"/knowledge/q850-cause-codes","askHref":"/?topic=q850-cause-codes","claims":[{"id":"q850-each-class-carries-an-unspecified-catch-all","text":"Each Q.850 class carries an unspecified cause used only when no other cause in that class applies, and the definitions say so in the same words for each: 31 normal, 47 resource unavailable, 63 service or option not available, 79 service or option not implemented, 95 invalid message, 111 protocol error and 127 interworking.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-each-class-carries-an-unspecified-catch-all","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clauses 6.2.7.1.25, 6.2.7.2.10, 6.2.7.3.8, 6.2.7.4.5, 6.2.7.6.10 and 6.2.7.7.1","href":"/knowledge/sources/itu-t-q850-2018"}]},{"id":"q850-cause-127-means-no-cause-was-available","text":"Cause 127 interworking unspecified indicates interworking with a network that does not provide causes for its actions, so the precise cause cannot be ascertained.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-cause-127-means-no-cause-was-available","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clause 6.2.7.7.1 Cause No. 127","href":"/knowledge/sources/itu-t-q850-2018"}]},{"id":"q850-cause-number-is-class-times-sixteen-plus-value","text":"A Q.850 cause value is a class in bits 5 to 7 and a value within the class in bits 1 to 4, so the cause number is the class times 16 plus the value, and that arithmetic holds for all 70 cause values in Table 1.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-cause-number-is-class-times-sixteen-plus-value","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clause 6.2.5 Cause value and Table 1","href":"/knowledge/sources/itu-t-q850-2018"}]}]},{"code":"cause-18-or-19","topicSlug":"q850-cause-codes","topicTitle":"ITU-T Q.850 call clearing cause values","articleHref":"/knowledge/q850-cause-codes","askHref":"/?topic=q850-cause-codes","claims":[{"id":"q850-cause-19-differs-from-18-by-alerting","text":"Cause 18 no user responding is used when the called party does not respond to call establishment within the allotted time, while cause 19 no answer from user is used when the called party was alerted and did not answer, so the pair separates a device that never signalled from a device that rang.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-cause-19-differs-from-18-by-alerting","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clauses 6.2.7.1.13 and 6.2.7.1.14","href":"/knowledge/sources/itu-t-q850-2018"}]}]},{"code":"cause-16-from-network","topicSlug":"q850-cause-codes","topicTitle":"ITU-T Q.850 call clearing cause values","articleHref":"/knowledge/q850-cause-codes","askHref":"/?topic=q850-cause-codes","claims":[{"id":"q850-cause-16-from-the-network-is-a-finding","text":"A cause 16 whose location field names a network element is worth stopping on in a trace, because Q.850 says the source of a normal call clearing is not normally the network, and nothing in the record says why the network cleared the call.","status":"inference","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-cause-16-from-the-network-is-a-finding","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clause 6.2.7.1.11 Cause No. 16 read with clause 6.2.3 Location","href":"/knowledge/sources/itu-t-q850-2018"}]},{"id":"q850-cause-16-does-not-normally-come-from-the-network","text":"Cause 16 normal call clearing indicates that one of the users involved requested that the call be cleared, and Q.850 states that under normal situations the source of this cause is not the network.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-cause-16-does-not-normally-come-from-the-network","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clause 6.2.7.1.11 Cause No. 16","href":"/knowledge/sources/itu-t-q850-2018"}]},{"id":"q850-location-is-a-separate-field-with-eight-values","text":"Location is a separate four-bit field of the same cause element with 8 defined values from user through international network and network beyond interworking point, so a cause value quoted without its location does not say who cleared the call.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/q850-location-is-a-separate-field-with-eight-values","sources":[{"id":"itu-t-q850-2018","title":"ITU-T Recommendation Q.850 (10/2018), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part","publisher":"International Telecommunication Union (ITU-T)","tier":1,"tierLabel":"standards and regulators","locator":"clause 6.2.3 Location","href":"/knowledge/sources/itu-t-q850-2018"}]}]},{"code":"cause-cisco-specific","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-cisco-specific-codes-sit-outside-the-q850-range","text":"Unified CM publishes call termination cause codes beyond the Q.850 set, marked Cisco specific in the table, including 125 out of bandwidth, 126 call split, 131 Call Control Discovery PSTN failover and a run of IME failure codes through 148.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-cisco-specific-codes-sit-outside-the-q850-range","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Call Termination Cause Codes, Table 12","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-sip-cause-codes-carry-a-q850-value-in-their-low-word","text":"Every one of the 42 SIP rows of the Cisco-specific cause code table has a Q.850 cause value in the low 16 bits of its code, and the guide states the construction for one row by writing the loop-detected code as 0x42000000 plus EXCHANGE_ROUTING_ERROR.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-sip-cause-codes-carry-a-q850-value-in-their-low-word","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Table 13 Cisco-Specific Call Termination Cause Codes","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-the-sip-marker-byte-is-not-arithmetic","text":"The high byte of a SIP-derived Unified CM cause code is not a fixed function of the SIP status code: across the 41 distinct status codes in the table the difference between the status code and the marker takes 6 different values, so decoding the SIP status out of a cause code needs the table rather than arithmetic.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-the-sip-marker-byte-is-not-arithmetic","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Table 13 Cisco-Specific Call Termination Cause Codes","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]}]},{"code":"cucm-transfer-final-record","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-join-on-behalf-of-marks-the-final-record","text":"The final transferred record is the one whose join-on-behalf-of field is set to 10 meaning transfer, and that field is 0 on the original and consultation records.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-join-on-behalf-of-marks-the-final-record","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, page 124, and the four worked examples","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-global-call-id-misses-the-consultation-record","text":"Grouping a transfer's records on the global call identifier collects two of the three: in all four worked examples the original and the final transferred record share one global call identifier and the consultation record carries a different one.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-global-call-id-misses-the-consultation-record","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-zero-means-never-connected","text":"The connect time field holds 0 when the call never connects and the disconnect time field is set even when the call never connects.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-zero-means-never-connected","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, dateTimeConnect and dateTimeDisconnect","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]}]},{"code":"cucm-transfer-split-record","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-split-cause-marks-the-first-two-records","text":"On both the original and the consultation record of a transfer, the originating and destination cause values are set to 393216 meaning split and the originating and destination termination-on-behalf-of fields are set to 10 meaning transfer.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-split-cause-marks-the-first-two-records","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, page 124, and the four worked examples","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-split-code-393216-replaces-126","text":"The Cisco-specific code 393216, hexadecimal 0x60000, is call split and the table records that it was formerly 126; it is set when a call terminates during a transfer because it was split off and was not part of the final transferred call.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-split-code-393216-replaces-126","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Table 13 Cisco-Specific Call Termination Cause Codes","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-final-originating-leg-is-the-surviving-original-leg","text":"The final transferred record's originating leg identifier is one of the original record's two leg identifiers, and which of the two it is depends on which party transferred, so a join from the original to the final record has to allow either.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-final-originating-leg-is-the-surviving-original-leg","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]}]},{"code":"cucm-consultation-record","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-global-call-id-misses-the-consultation-record","text":"Grouping a transfer's records on the global call identifier collects two of the three: in all four worked examples the original and the final transferred record share one global call identifier and the consultation record carries a different one.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-global-call-id-misses-the-consultation-record","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-duration-is-zero-below-one-second","text":"The duration field is zero both when a call never connects and when it connects for less than one second, so a duration of zero is not evidence that a call was never answered.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-duration-is-zero-below-one-second","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, duration","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]},{"id":"cucmcdr-blind-transfer-shows-a-zero-duration-consultation","text":"A blind transfer and a consultation transfer are distinguished in the record set by the consultation record's duration: it is 0 for a blind transfer and non-zero for a consultation transfer, while every other marker on the three records is identical.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-blind-transfer-shows-a-zero-duration-consultation","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]}]},{"code":"cucm-predecessor-outside-global-call","topicSlug":"cucm-cdr-field-reference","topicTitle":"CUCM CDR and CMR field reference","articleHref":"/knowledge/cucm-cdr-field-reference","askHref":"/?topic=cucm-cdr-field-reference","claims":[{"id":"cucmcdr-global-call-id-misses-the-consultation-record","text":"Grouping a transfer's records on the global call identifier collects two of the three: in all four worked examples the original and the final transferred record share one global call identifier and the consultation record carries a different one.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-global-call-id-misses-the-consultation-record","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-final-originating-leg-is-the-surviving-original-leg","text":"The final transferred record's originating leg identifier is one of the original record's two leg identifiers, and which of the two it is depends on which party transferred, so a join from the original to the final record has to allow either.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-final-originating-leg-is-the-surviving-original-leg","sources":[{"id":"archive-cucm-cdr-admin-guide-1251-book","title":"Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23","publisher":"Cisco Systems, Inc., served by the Internet Archive","tier":2,"tierLabel":"current vendor documentation","locator":"Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126","href":"/knowledge/sources/archive-cucm-cdr-admin-guide-1251-book"}]},{"id":"cucmcdr-leg-identifiers-are-cluster-unique","text":"The originating and terminating leg identifiers each identify one leg of a call and are unique within a cluster.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/cucmcdr-leg-identifiers-are-cluster-unique","sources":[{"id":"cisco-cucm-cdr-field-descriptions-15","title":"Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager Release 15 and SUs, CDR Field Descriptions","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"CDR Field Descriptions, origLegCallIdentifier and destLegCallIdentifier","href":"/knowledge/sources/cisco-cucm-cdr-field-descriptions-15"}]}]},{"code":"sip-final-response-class","topicSlug":"sip-response-codes","topicTitle":"SIP response codes and failure interpretation","articleHref":"/knowledge/sip-response-codes","askHref":"/?topic=sip-response-codes","claims":[{"id":"sip-six-response-classes","text":"SIP response codes fall into 6 classes: 1xx provisional 2xx success 3xx redirection 4xx request failure 5xx server failure and 6xx global failure.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-six-response-classes","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 section 21","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"sip-final-response-ends-the-transaction","text":"A 1xx response is provisional and every other class is final and a final response completes the transaction.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/sip-final-response-ends-the-transaction","sources":[{"id":"rfc-3261-sip","title":"RFC 3261 — SIP: Session Initiation Protocol","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3261 sections 17 and 21","href":"/knowledge/sources/rfc-3261-sip"}]},{"id":"wxc-reroute-sip-triggers","text":"Rerouting to another trunk is triggered by SIP responses 401, 470, 480 and 606 when no provisional 18x response preceded them, by all other 4xx responses except 403, 404, 410, 413, 484 and 486, by all 5xx responses, and by a 12 second SIP timeout.","status":"fact","verifiedAt":"2026-09-04","href":"/knowledge/claims/wxc-reroute-sip-triggers","sources":[{"id":"cisco-pdf-preferred-architecture-webex-calling","title":"Cisco Preferred Architecture for Webex Calling — Design Overview","publisher":"Cisco Systems, Inc. (CTG TME)","tier":2,"tierLabel":"current vendor documentation","locator":"Trunks and Route Groups, page 21","href":"/knowledge/sources/cisco-pdf-preferred-architecture-webex-calling"}]}]},{"code":"sip-replaces-join","topicSlug":"call-transfer-semantics","topicTitle":"Call transfer semantics REFER and Replaces","articleHref":"/knowledge/call-transfer-semantics","askHref":"/?topic=call-transfer-semantics","claims":[{"id":"xfersem-attended-transfer-is-hold-consult-hold-refer","text":"In an attended transfer the Transferor places the Transferee on hold, establishes a call with the Transfer Target to alert them to the impending transfer, places the Target on hold, and then transfers using an escaped Replaces header field inside the Refer-To header.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-attended-transfer-is-hold-consult-hold-refer","sources":[{"id":"rfc-5589-call-control-transfer","title":"RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 5589 section 7.3 Attended Transfer, opening paragraph","href":"/knowledge/sources/rfc-5589-call-control-transfer"}]},{"id":"xfersem-replaces-matches-on-three-values","text":"The Replaces header field identifies an existing dialog by Call-ID, to-tag and from-tag, and a user agent server matches those parameters as if they were tags in an incoming request, comparing the to-tag parameter to its own local tag and the from-tag parameter to the remote tag.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-replaces-matches-on-three-values","sources":[{"id":"rfc-3891-replaces","title":"RFC 3891 — The Session Initiation Protocol (SIP) \"Replaces\" Header","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3891 section 3, first 2 paragraphs","href":"/knowledge/sources/rfc-3891-replaces"}]},{"id":"xfersem-require-replaces-on-the-triggered-invite","text":"RFC 5589 says the Require replaces header field should be used in the triggered INVITE of an attended transfer, to prevent a user agent that does not support Replaces from ignoring it and answering the INVITE without a dialog match.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-require-replaces-on-the-triggered-invite","sources":[{"id":"rfc-5589-call-control-transfer","title":"RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 5589 section 7.3, paragraph 3","href":"/knowledge/sources/rfc-5589-call-control-transfer"}]}]},{"code":"sip-replaces-unobserved-dialog","topicSlug":"call-transfer-semantics","topicTitle":"Call transfer semantics REFER and Replaces","articleHref":"/knowledge/call-transfer-semantics","askHref":"/?topic=call-transfer-semantics","claims":[{"id":"xfersem-replaces-matches-on-three-values","text":"The Replaces header field identifies an existing dialog by Call-ID, to-tag and from-tag, and a user agent server matches those parameters as if they were tags in an incoming request, comparing the to-tag parameter to its own local tag and the from-tag parameter to the remote tag.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-replaces-matches-on-three-values","sources":[{"id":"rfc-3891-replaces","title":"RFC 3891 — The Session Initiation Protocol (SIP) \"Replaces\" Header","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3891 section 3, first 2 paragraphs","href":"/knowledge/sources/rfc-3891-replaces"}]},{"id":"xfersem-replaces-481-cases","text":"A Replaces header field that matches no dialog, that matches more than one dialog, or that matches a dialog not created with an INVITE is answered with 481 Call/Transaction Does Not Exist, and in the multiple-match case the user agent must act as if no match was found.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-replaces-481-cases","sources":[{"id":"rfc-3891-replaces","title":"RFC 3891 — The Session Initiation Protocol (SIP) \"Replaces\" Header","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3891 section 3, paragraphs 5 and 6","href":"/knowledge/sources/rfc-3891-replaces"}]},{"id":"xfersem-replaces-early-only-gets-486","text":"The early-only parameter in a Replaces header field restricts the replacement to an early dialog, and where it is present and the header matches a confirmed dialog the user agent rejects the request with a 486 Busy response.","status":"fact","verifiedAt":"2026-09-16","href":"/knowledge/claims/xfersem-replaces-early-only-gets-486","sources":[{"id":"rfc-3891-replaces","title":"RFC 3891 — The Session Initiation Protocol (SIP) \"Replaces\" Header","publisher":"IETF / RFC Editor","tier":1,"tierLabel":"standards and regulators","locator":"RFC 3891 sections 3 and 4, early-only","href":"/knowledge/sources/rfc-3891-replaces"}]}]},{"code":"calling-consultative-transfer","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdr-blind-transfer-surfaces-as-deflection","text":"A consultative transfer is carried in the related reason field by its own value, and a blind transfer surfaces only as deflection, a value it shares with auto-attendant transfer and call centre exit.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-blind-transfer-surfaces-as-deflection","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, related reason","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdrapi-interaction-id-spans-a-consult-and-its-transfer","text":"Detailed Call History Interaction ID ties together multiple call patterns linked by a service interaction, and Cisco's worked example is a consult and transfer: when a user holds an active call, places another call from the same app or device and then transfers the original call, both calls share the same Interaction ID.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-interaction-id-spans-a-consult-and-its-transfer","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Interaction ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdr-correlation-id-is-the-session-tie","text":"Cisco describes the correlation identifier as tying together multiple call legs of the same call session.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-correlation-id-is-the-session-tie","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, correlation identifier","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]}]},{"code":"calling-deflection","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdr-blind-transfer-surfaces-as-deflection","text":"A consultative transfer is carried in the related reason field by its own value, and a blind transfer surfaces only as deflection, a value it shares with auto-attendant transfer and call centre exit.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-blind-transfer-surfaces-as-deflection","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, related reason","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdr-correlation-id-survives-a-blind-transfer","text":"The correlation identifier is unchanged across all 4 call detail records of Cisco's blind transfer example.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-correlation-id-survives-a-blind-transfer","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, blind transfer worked example","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdr-park-does-not-collapse-to-deflection","text":"Call park has its own values in the related reason field, where a blind transfer collapses into deflection.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdr-park-does-not-collapse-to-deflection","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Cloud collaboration reports, related reason values","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]}]},{"code":"calling-call-park","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdr-correlation-id-breaks-on-call-park","text":"The correlation identifier takes 3 distinct values across the 4 call detail records of Cisco's call park example.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-correlation-id-breaks-on-call-park","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, call park worked example","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdr-park-does-not-collapse-to-deflection","text":"Call park has its own values in the related reason field, where a blind transfer collapses into deflection.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdr-park-does-not-collapse-to-deflection","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Cloud collaboration reports, related reason values","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdrapi-related-reason-publishes-33-values-with-a-typo","text":"The Detailed Call History Related reason field documents 33 named values, and 2 of them are malformed as identifiers: CalllPark is spelled with 3 letter Ls, and Remote Office carries a space where every other value is a single unspaced token.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-related-reason-publishes-33-values-with-a-typo","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Related reason description, bulleted value list","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]},{"code":"calling-success-not-answered","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdrapi-call-outcome-success-includes-busy-and-no-answer","text":"Detailed Call History Call outcome carries 3 values, and Success is defined as a call routed and disconnected successfully including the Normal, UserBusy and NoAnswer scenarios, so a busy or unanswered call is recorded as a successful outcome; Failure means an internal or external error and Refusal means the call was rejected because of call block or timeout.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-call-outcome-success-includes-busy-and-no-answer","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Call outcome description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdrapi-call-outcome-reason-value-census","text":"Detailed Call History Call outcome reason documents 26 values under the 3 outcomes on the cdr_feed endpoint: 3 under Success, 15 under Refusal and 8 under Failure.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-call-outcome-reason-value-census","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Call outcome reason description, counted over the 3 grouped value lists","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]},{"code":"calling-redirected","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdr-redirection-chain-loses-the-middle","text":"The redirecting number and redirecting party identifier give the last redirector and the original called party identifier gives the first; no field gives an intermediate one.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-redirection-chain-loses-the-middle","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, redirection fields","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdr-caller-id-changes-on-redirect","text":"The caller identifier number re-points at the redirected party on a redirected call, and the external caller identifier number is not set at all for redirected calls.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-caller-id-changes-on-redirect","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference, caller identifier fields","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdrapi-redirect-and-original-reason-share-a-value-list","text":"Detailed Call History Redirect reason and Original reason publish the same 13 values, Redirect reason carrying the reason for the redirecting number and Original reason the reason for the original called number, and their value descriptions differ in 4 places, of which only 1 is substantive: Original reason adds Group night forwarding to the Unconditional value and Redirect reason does not.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-redirect-and-original-reason-share-a-value-list","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Redirect reason and Original reason descriptions compared line by line","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]},{"code":"calling-two-records-one-leg","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdrapi-network-call-id-groups-one-leg","text":"Detailed Call History Network call ID shows whether 2 records belong to the same call leg: 2 records belong to the same leg if and only if they carry the same Network call ID, and Report ID is described as a unique identifier for the individual record that can be used to deduplicate while processing.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-network-call-id-groups-one-leg","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Network call ID and Report ID descriptions","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdrapi-local-call-id-joins-two-different-things","text":"Detailed Call History Local call ID is used with 2 other fields for 2 different purposes: with Remote call ID it identifies the remote record of the same call leg, and with Transfer related call ID it identifies the transferred leg.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-local-call-id-joins-two-different-things","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Local call ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdrapi-six-field-names-differ-only-in-spelling","text":"6 Detailed Call History field names are spelled differently by the API and by the Control Hub report while naming the same field: Client version against Client Version, Device MAC against Device Mac, Call transfer Time against Call transfer time, Final local SessionID against Final Local Session ID, Final remote SessionID against Final Remote Session ID, and PSTN Vendor Name against PSTN vendor name.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-six-field-names-differ-only-in-spelling","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema property names against the Calling Detailed Call History Report column table on cisco-help-nmug598-cloud-collaboration-reports, the API spelling given first in each pair","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]},{"code":"calling-transfer-related-leg","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdrapi-local-call-id-joins-two-different-things","text":"Detailed Call History Local call ID is used with 2 other fields for 2 different purposes: with Remote call ID it identifies the remote record of the same call leg, and with Transfer related call ID it identifies the transferred leg.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-local-call-id-joins-two-different-things","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Local call ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdr-transfer-related-call-id-partial","text":"The transfer related call identifier points at the other leg's local call identifier and is populated on only 2 of the 4 call detail records in Cisco's blind transfer example.","status":"fact","verifiedAt":"2026-09-05","href":"/knowledge/claims/wxcdr-transfer-related-call-id-partial","sources":[{"id":"cisco-help-nmug598-cloud-collaboration-reports","title":"Reports for Your Cloud Collaboration Portfolio","publisher":"Cisco Systems, Inc. (Webex Help Center)","tier":2,"tierLabel":"current vendor documentation","locator":"Detailed call history field reference and the blind transfer worked example","href":"/knowledge/sources/cisco-help-nmug598-cloud-collaboration-reports"}]},{"id":"wxcdrapi-related-call-id-is-service-created","text":"Detailed Call History Related call ID names a different call that this call created because of a service activation, and its value is the Local call ID of that related call.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-related-call-id-is-service-created","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Related call ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]},{"code":"calling-related-call","topicSlug":"webex-calling-cdr-reference","topicTitle":"What the Webex Calling detailed call history records","articleHref":"/knowledge/webex-calling-cdr-reference","askHref":"/?topic=webex-calling-cdr-reference","claims":[{"id":"wxcdrapi-related-call-id-is-service-created","text":"Detailed Call History Related call ID names a different call that this call created because of a service activation, and its value is the Local call ID of that related call.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-related-call-id-is-service-created","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Related call ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdrapi-local-call-id-joins-two-different-things","text":"Detailed Call History Local call ID is used with 2 other fields for 2 different purposes: with Remote call ID it identifies the remote record of the same call leg, and with Transfer related call ID it identifies the transferred leg.","status":"fact","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-local-call-id-joins-two-different-things","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema, Local call ID description","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]},{"id":"wxcdrapi-six-field-names-differ-only-in-spelling","text":"6 Detailed Call History field names are spelled differently by the API and by the Control Hub report while naming the same field: Client version against Client Version, Device MAC against Device Mac, Call transfer Time against Call transfer time, Final local SessionID against Final Local Session ID, Final remote SessionID against Final Remote Session ID, and PSTN Vendor Name against PSTN vendor name.","status":"field-pattern","verifiedAt":"2026-09-15","href":"/knowledge/claims/wxcdrapi-six-field-names-differ-only-in-spelling","sources":[{"id":"cisco-dev-cdr-feed-detailed-call-history","title":"Reports: Detailed Call History — Get Detailed Call History","publisher":"Cisco Systems, Inc. (developer.webex.com)","tier":2,"tierLabel":"current vendor documentation","locator":"spec.responses.200 schema property names against the Calling Detailed Call History Report column table on cisco-help-nmug598-cloud-collaboration-reports, the API spelling given first in each pair","href":"/knowledge/sources/cisco-dev-cdr-feed-detailed-call-history"}]}]}]} {"notes":[{"id":"collect-rtmt","text":"In RTMT the files are collected under System > Tools > Trace & Log Central > Collect Files, for an absolute or a relative time range. Cisco’s procedure selects Cisco CallManager and Cisco CTIManager on all servers.","claims":[{"id":"cucm-sdl-trace-files-rtmt-collect-files-path","href":"/knowledge/claims/cucm-sdl-trace-files-rtmt-collect-files-path"},{"id":"cucm-sdl-trace-files-rtmt-time-range","href":"/knowledge/claims/cucm-sdl-trace-files-rtmt-time-range"},{"id":"cucm-sdl-trace-files-rtmt-services-to-select","href":"/knowledge/claims/cucm-sdl-trace-files-rtmt-services-to-select"}]},{"id":"collect-cli","text":"On the command line the CallManager SDL files are under activelog cm/trace/ccm/sdl/, and file get activelog sends matching files to another system over SFTP.","claims":[{"id":"cucm-sdl-trace-files-sdl-cli-path","href":"/knowledge/claims/cucm-sdl-trace-files-sdl-cli-path"},{"id":"cucm-sdl-trace-files-cli-file-get","href":"/knowledge/claims/cucm-sdl-trace-files-cli-file-get"}]},{"id":"names","text":"In CUCM 14, Cisco CallManager SDL files match SDL00*_100*.txt and Cisco CTIManager SDL files match SDL*_200_*.txt. Those are two series here: open them separately.","claims":[{"id":"cucm-sdl-trace-files-ccm-100-cti-200","href":"/knowledge/claims/cucm-sdl-trace-files-ccm-100-cti-200"}]},{"id":"gzo","text":"Files pulled from the command line are normally .gz. A .gzo file was still open for writing when it was downloaded and may not open cleanly.","claims":[{"id":"cucm-sdl-trace-files-gz-gzo-extensions","href":"/knowledge/claims/cucm-sdl-trace-files-gz-gzo-extensions"}]},{"id":"rollover","text":"When the last trace file in the sequence is full, tracing writes over the first file, so the oldest data is lost and the lowest number is not always the oldest file.","claims":[{"id":"cucm-sdl-trace-files-rollover-overwrite","href":"/knowledge/claims/cucm-sdl-trace-files-rollover-overwrite"}]},{"id":"resize-deletes","text":"Changing Maximum No. of Files or Maximum File Size deletes every log file of the service except the current one, so collect the files first.","claims":[{"id":"cucm-sdl-trace-files-output-change-deletes","href":"/knowledge/claims/cucm-sdl-trace-files-output-change-deletes"},{"id":"cucm-sdl-trace-files-collect-before-resize","href":"/knowledge/claims/cucm-sdl-trace-files-collect-before-resize"}]},{"id":"sip-filters","text":"Enable SIP Stack Trace (on by default) and Enable SIP Call Processing Trace are Cisco CallManager trace filters, set in Cisco Unified Serviceability under Trace > Configuration.","claims":[{"id":"cucm-sdl-trace-files-sip-stack-trace","href":"/knowledge/claims/cucm-sdl-trace-files-sip-stack-trace"},{"id":"cucm-sdl-trace-files-sip-cp-trace","href":"/knowledge/claims/cucm-sdl-trace-files-sip-cp-trace"},{"id":"cucm-sdl-trace-files-trace-config-path","href":"/knowledge/claims/cucm-sdl-trace-files-trace-config-path"}]},{"id":"line-time","text":"Cisco’s sample CallManager trace lines are pipe-delimited: a sequence number, a time of day with milliseconds, then a tag such as AppInfo.","claims":[{"id":"cucm-sdl-trace-files-line-prefix-format","href":"/knowledge/claims/cucm-sdl-trace-files-line-prefix-format"}]}]}Trace Studio
Loading the local trace reader…