CDR Field Mappings
Overview.
The v2 API will show easier to understand names for returned CDR fields. This is a list of valid field names and their descriptions.
More info on its uses can be found in these APIs.
Table Mapping and Description
| API v2 | API v1 | Description |
|---|---|---|
| call-account-code | pac | The account code used by a user to make an outbound call. This will default to null unless otherwise configured. More information is available Account Codes to Restrict Dialing Unvalidated Account Codes |
| call-answer-datetime | time-answer | The date-time that this leg of a call was answered (ie. that a SIP 200 OK was sent or received in response to a SIP INVITE). |
| call-audio-codec | codec | The audio codec that was negotiated for this call, recorded from the call's SDP. Note: individual phone vendors may use different names for the same codec. You may see "PCMU" or "G.711 u-law" as an example. |
| call-audio-relay-side-a-local-port | rly_prt_0 | Of calls whose RTP was relayed through the Core Server, this is one of the two UDP ports that was used on the Core Server to relay RTP between the orig and term legs of a call. |
| call-audio-relay-side-a-packet-count | rly_cnt_a | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "A" side of the call. |
| call-audio-relay-side-a-remote-ip | rly_prt_a | The IP address and UDP port that sent RTP on the "A" side of the call. This may be a remote IP or may be the IP of the Core Server. This value will be null if the call was never successfully connected. |
| call-audio-relay-side-b-packet-count | rly_cnt_b | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "B" side of the call. |
| call-audio-relay-side-b-remote-ip | rly_prt_b | The IP address and UDP port that sent RTP on the "B" side of the call. This may be a remote IP or may be the IP of the Core Server. This value will be null if the call was never successfully connected. |
| call-batch-answer-datetime | batch_tim_ans | For all of the batched legs of a single call, this is the date and time that any of the legs was answered (i.e. that a SIP 200 OK was sent or received in response to a SIP INVITE). |
| call-batch-on-hold-duration-seconds | batch_hold | For all of the batched legs of a single call, this is the accumulated duration in seconds that the call was on hold. This hold duration may be the sum of one or more call legs. |
| call-batch-sequence-marker | release_code | For all of the batched legs of a single call, this indicates whether this specific leg was to : - "begin" the batch - "continue" the batch - "end" the batch |
| call-batch-start-datetime | batch_tim_beg | For all of the batched legs of a single call, this is the date and time that the original leg of the call was started on the system. |
| call-batch-total-duration-seconds | batch_dura | For all of the batched legs of a single call, this is the accumulated duration in seconds of the call, from the the time the call was first answered until the final leg of a call has disconnected. |
| call-direction | type | Whether the directionality of the call was: - "Outbound" - "Inbound" - "Missed" |
| call-disconnect-datetime | time_release | The date-time that this leg of a call was disconnected (i.e. that a SIP BYE was sent). |
| call-disconnect-reason-text | release_text | The text description of the reason this leg of a call was disconnected. Results may include: "Call completed elsewhere" "DTMF <3> entered" "Incompatible Media" "No Answer" "Term: Bye" - the term leg of the call sent a SIP BYE |
| call-disposition | disposition | If Call Dispositions and Reasons have been configured on the system, an agent was logged into one of the graphical interfaces of the system, and the agent completed the Disposition and Reason form after a call, this field will show the Disposition of the call. More information can be found in this documentation article. Defaults to null. |
| call-disposition-notes | notes | If Call Dispositions and Reasons have been configured on the system, an agent was logged into one of the graphical interfaces of the system, and the agent completed the Disposition and Reason form after a call, this field will show any notes the agent may have written for the call. More information can be found in this documentation article. Defaults to null. |
| call-disposition-reason | reason | If Call Dispositions and Reasons have been configured on the system, an agent was logged into one of the graphical interfaces of the system, and the agent completed the Disposition and Reason form after a call, this field will show the Reason for the call's Disposition. More information can be found in this documentation article. Defaults to null |
| call-disposition-submitted-datetime | time_disp | If Call Dispositions and Reasons have been configured on the system, an agent was logged into one of the graphical interfaces of the system, and the agent completed the Disposition and Reason form after a call, this field will show the date-time that the disposition was submitted by the agent. More information can be found in this documentation article. Defaults to null |
| call-disposition-direction | disp_type | If Call Dispositions and Reasons have been configured on the system, an agent was logged into one of the graphical interfaces of the system, and the agent completed the Disposition and Reason form after a call, this field will show whether the call was: More information can be found in this documentation article. Defaults to null |
| call-fax-codec | image_codec | The fax codec that was negotiated for this call, recorded from the call's SDP. Note: through at least release v44.0, if a fax was transmitted through the system, this field will invariably show "Image" as the codec |
| call-fax-relay-side-a-local-port | image_prt_0 | Of calls whose RTP was relayed through the Core Server, this is one of the two UDP ports that was used on the Core Server to relay RTP between the orig and term legs of a call. |
| call-fax-relay-side-a-packet-count | image_cnt_a | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "A" side of the call. |
| call-fax-relay-side-a-remote-ip | image_prt_a | The IP address and UDP port that sent RTP on the "A" side of the call. This may be a remote IP or may be the IP of the Core Server. This value will be null if the call was never successfully connected. |
| call-fax-relay-side-b-packet-count | image_cnt_b | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "B" side of the call. |
| call-fax-relay-side-b-remote-ip | image_prt_b | The IP address and UDP port that sent RTP on the "B" side of the call. This may be a remote IP or may be the IP of the Core Server. This value will be null if the call was never successfully connected. |
| call-intelligence-job-id | n/a | This is the id used to tranct the transcription, sentiment and intelegence request to the 3rd party. Needed to request the data. |
| call-intelligence-percent-negative | n/a | The percent of the call that had a negative sentiment. Only available with intelligence features turned on. |
| call-intelligence-percent-neutral | n/a | The percent of the call that had a neutral sentiment. Only available with intelligence features turned on. |
| call-intelligence-percent-positve | n/a | The percent of the call that had a postive sentiment. Only available with intelligence features turned on. |
| call-intelligence-topics-top | n/a | The top topics discussed during the call. Comma seperated list of topics. Only available with intelligence features turned on. |
| call-leg-ordinal-index | cdr_index | For all of the batched legs of a single call, this represents what order a specific call leg took place in the batch. |
| call-on-hold-duration-seconds | time_holding | The duration in seconds that this leg of a call was on hold. |
| call-orig-call-id | orig_callid | The value of the SIP Call-ID header received in the initial SIP INVITE that started a batch of call legs. This value will typically be the same Call-ID for all legs in a batch of calls. |
| call-orig-caller-id | orig_id | The Caller ID for the orig side of a call leg. |
| call-orig-department | orig_group | The department of the user that initiated the orig leg of a new call. This may be null for calls that originated through a SIP trunk or for users that are not assigned to a department. |
| call-orig-domain | orig_domain | The domain of the user that initiated the orig leg of a new call. This may be null for calls that originated through a SIP trunk. |
| call-orig-from-host | orig_from_host | The host portion of the SIP From URI, after passing through initial Dial Translations, just prior to passing through Call Routing. |
| call-orig-from-name | orig_from_name | The name portion of the SIP From URI, after passing through initial dial translations, just prior to passing through Call Routing. |
| call-orig-from-uri | orig_from_uri | The complete SIP From URI, after passing through initial Dial Translations, just prior to passing through Call Routing. |
| call-orig-from-user | orig_from_user | The user portion of the SIP From URI, after passing through initial Dial Translations, just prior to passing through Call Routing. |
| call-orig-ip-address | orig_ip | The IP address the orig leg of the call was received from. This may be a remote IP address or may be the IP of the Core Server. |
| call-orig-match-uri | orig_match | For origination calls (calls inbound to the system), this is the pattern that a SIP header positively matched against to allow the call to begin. For calls that came in from extensions, this will be the SIP AOR (Address of Record) (e.g. sip:1000wp@domain) For calls that came in from SIP trunks, this will be the "Origination Match" pattern of the trunk (e.g. sip*@trunk-name). This includes calls that traversed geo servers in the same cluster. |
| call-orig-pre-routing-uri | orig_logi_uri | The complete SIP Request URI for the orig leg of a call, prior to passing through initial Dial Translations, and prior to passing through Call Routing. |
| call-orig-request-host | orig_req_host | The host portion of the SIP URI from the Request line of the SIP INVITE of the orig leg of a call. |
| call-orig-request-uri | orig_req_uri | The complete SIP URI from the Request line of the SIP INVITE of the orig leg of a call. |
| call-orig-request-user | orig_req_user | The user portion of the SIP URI from the Request line of the SIP INVITE of the orig leg of a call. |
| call-orig-reseller | orig_territory | The name of the reseller of the user that initiated the orig leg of a new call. This may be null for calls that originated through a SIP trunk. |
| call-orig-site | orig_site | The site of the user that initiated the orig leg of a new call. This may be null for calls that originated through a SIP trunk or for users that are not assigned to a site. |
| call-orig-to-host | orig_to_host | The host portion of the SIP to header of the SIP INVITE of the orig leg of a call. |
| call-orig-to-uri | orig_to_uri | The complete SIP URI from the SIP To header of the SIP INVITE of the orig leg of a call. |
| call-orig-to-user | orig_to_user | The user portion of the SIP to header of the SIP INVITE of the orig leg of a call. |
| call-orig-user | orig_sub | The extension number of the user that initiated the orig leg of a new call. This may be null for calls that originated through a SIP trunk. |
| call-parent-call-id | servedCallId | The Call-ID that started a new, unique call flow on the system. This field exists but will be empty prior to v44.0 |
| call-parent-cdr-id | cdr_id | The unique ID of this CDR. |
| call-record-creation-datetime | time_insert | The date-time that this record was inserted into the database. |
| call-ringing-datetime | time_ringing | The date-time that this leg of a call first started ringing (i.e. that a SIP 180 Ringing or SIP 183 Early Media was sent or received in response to a SIP INVITE). |
| call-routing-class | route_class | The configured routing class used when the call went through Call Routing. This is likely null in most cases. |
| call-routing-match-uri | route_to | For all calls on the system that successfully connected one party to another, this is the pattern that a SIP Request URI positively matched against in the system's Call Routing table. For calls that terminated to extensions, this will be the wildcard Call Route that matches sip:*@*For calls that terminated through SIP trunks, this will be the "Destination" pattern of the Call Route (e.g. sip:1??????????@*). This includes calls that traversed geo servers in the same cluster. |
| call-server-mac-address | mac | The MAC address of the Core Server that processed the call. |
| call-start-datetime | time_start | The date-time that this leg of a call began (i.e. that a SIP INVITE was sent or received). |
| call-tag | tag | The tag of this leg of a call. |
| call-talking-duration-seconds | time_talking | The duration in seconds that this leg of a call was in a talking state (does not include the time prior to answer or while on hold). |
| call-term-call-id | term_callid | The value of the SIP Call-ID header sent in the SIP INVITE of the term leg of the call. |
| call-term-caller-id | term_id | The Caller ID for the term side of a call leg. |
| call-term-department | term_group | The department of the user that received. the term leg of the call. |
| call-term-domain | term_domain | The domain of the user that received the term leg of the call. This may be null for calls that terminated through a SIP trunk . |
| call-term-ip-address | term_ip | The IP address the term leg of the call was sent to. This may be a remote IP address or may be the IP of the Core Server. |
| call-term-match-uri | term_match | For all calls on the system that successfully connected one party to another, this is the pattern that a translated SIP Request URI positively matched against in the system's Connections (SIP Trunk) list or Extensions list. For calls that terminated to extensions, this will be the AOR of the user sip:1000@domainFor calls that terminated through SIP trunks, this will be the "Termination Match" pattern of the Connection (e.g. sip*@sbc.company.com). This includes calls that traversed geo servers in the same cluster. |
| call-term-pre-reouting-uri | term_logi_uri | The complete SIP To URI for the term leg of a call, prior to passing through initial Dial Translations, and prior to passing through Call Routing. |
| call-term-reseller | term_territory | The reseller-territory of the user that received the term leg of the call. This may be null for calls that terminated through a SIP trunk. |
| call-term-site | term_site | The site of the user that received the term leg of the call. This may be null for calls that terminated through a SIP trunk. |
| call-term-to-uri | term_to_uri | The complete SIP To URI for the term leg of a call, after passing through initial Dial Translations, and just prior to passing through Call Routing. |
| call-term-user | term_sub | The extension number of the user that received the term leg of the call. This may be null for calls that terminated through a SIP trunk. |
| call-through-action | by_action | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-action indicates what system event occurred that furthered the processing of a call. Examples include: "Call retrieved" "Forward always" "Inter-server call leg" "Queue dispatch" "Supervised transfer" |
| call-through-call-id | by_callid | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-call-id is the Call-ID of the call leg that furthered the processing of a call. |
| call-through-caller-id | by_id | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-caller-id is the Caller ID of the user account of the call leg that furthered the processing of a call. |
| call-through-department | by_group | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-department is the department of the user account of the call leg that furthered the processing of a call. |
| call-through-domain | by_domain | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-domain is the domain of the user account of the call leg that furthered the processing of a call |
| call-through-reseller | by_territory | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-reseller is the reseller-territory of the domain of the user account of the call leg that furthered the processing of a call. |
| call-through-site | by_site | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-site is the site of the user account of the call leg that furthered the processing of a call. |
| call-through-uri | by_uri | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-uri is the SIP URI of the call leg that furthered the processing of a call. |
| call-through-user | by_sub | For call flows more complex than one user calling another, "call-through-" fields identify an intermediary user account that was involved in directing a call from one destination to another. call-through-user is the user account of the call leg that furthered the processing of a call. |
| call-total-duration-seconds | duration | The total duration in seconds of this leg of a call. Includes time ringing, talking, and on hold. |
| call-video-codec | video_codec | The video codec that was negotiated for this call, recorded from the call's SDP. Note: through at least release v44.0, if video was relayed through the system, this field will invariably show "Video" as the codec. |
| call-video-relay-side-a-local-port | video_prt_0 | Of calls whose RTP was relayed through the Core Server, this is one of the two UDP ports that was used on the Core Server to relay RTP between the orig and term legs of a call. |
| call-video-relay-side-a-packet-count | video_cnt_a | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "A" side of the call. |
| call-video-relay-side-a-remote-ip | video_prt_a | The IP address and UDP port that sent RTP on the "A" side of the call. This may be a remote public IP (if video relay was successfully acquired) or a remote private IP (if video relay was not successfully acquired). This value will be null if video was not negotiated during the call. |
| call-video-relay-side-b-packet-count | video_cnt_b | Of calls whose RTP was relayed through the Core Server, this is the number of packets that were received from the "B" side of the call. |
| call-video-relay-side-b-remote-ip | video_prt_b | The IP address and UDP port that sent RTP on the "B" side of the call. This may be a remote public IP (if video relay was successfully acquired) or a remote private IP (if video relay was not successfully acquired). This value will be null if video was not negotiated during the call. |
| core-server | hostname | The FQDN of the Core Server that processed the call. |
| domain | domain | The domain in which this call leg took place. |
| hide-from-results | hide | Whether this leg of a call should be hidden from the Call History of a user. Typically these are call legs created for internal system processes and not meaningful to an end user. |
| is-trace-expected | expected_trace | Based on the date the call took place and the Core Server's configured Event Keep Day duration, whether detailed call processing logs should still be available in order to retrieve a call trace (SIP ladder graph) via the API. |
| prefilled-trace-api | trace_api | A pre-filled v1 API call that can be used to retrieve a call trace. Should only be used if the is-trace-expected parameter is 'yes'. |
| prefilled-transcription-api | n/a | A pre-filed api link that can be used to get the inteligence and transcription info. |
| reseller | reseller | The reseller-territory of the domain in which this call leg took place. |
Updated 11 months ago