A method and apparatus for generating call detail records

Abstract

This application relates to the field of communications, including a method and apparatus for generating call detail records. Upon initiating a call for the first time, a unique transaction identifier is generated for the call according to encoding rules; an initial call stage identifier is created, and the call is routed to its destination, performing corresponding operations based on the destination type; during the call's duration, events are captured in real-time at key nodes of signaling processing, generating event timeline data; based on the event timeline data and destination type, multi-dimensional duration calculations are performed for each call stage, generating duration data; if a call transfer occurs, a new call stage identifier is created, associated with the unique transaction identifier, and the process of routing the call to its destination is restarted; a complete call detail record containing the timeline is generated based on the duration data and timeline data. This method can record a structured call process that uniformly associates all stages of a complete call.

Description

Technical Field

[0001] This application relates to the field of communications, specifically to a method and apparatus for generating call detail records. Background Technology

[0002] In today's enterprise communication systems, private branch exchanges (PBXs) or IP-based PBX systems are the core devices for handling internal and external calls. Call detail records (CDRs), as the basis for recording metadata for each call, are a key data source for system administrators to perform call billing, service quality analysis, troubleshooting, and compliance audits.

[0003] Traditional CDR generation and management technologies have the following obvious limitations and defects: First, call logs are fragmented and lack unified identifying identifiers. In the traditional "one channel, one log" model, whenever a call is transferred, routed, or redirected to a new destination, the system generates a separate Call Record (CDR) for each new call leg. These CDRs lack a clear correlation, resulting in a complete call—which may involve multiple IVR (Interactive Voice Response) navigations, queue waiting, agent answering, and consultation transfers—being scattered across multiple unrelated logs. This makes it difficult for administrators to easily trace the entirety of a call. Furthermore, supplementary information such as call notes, recordings, and AI-transcribed summaries are also fragmented and scattered along with the CDRs, making them difficult to aggregate, view, and manage.

[0004] Secondly, the call process cannot be accurately traced. Existing CDRs only record the start and end times of the call, the calling and called numbers, and a rough status code (such as connected, missed, busy). Specific operations occurring during the call lifecycle, such as the user's button selections after entering the IVR, being routed to different queues, executing hold and resume actions, and the specific type of transfer (blind transfer, consultation transfer), lack structured records. When troubleshooting is required, administrators often have to rely on manual experience to make inferences, lacking objective process-level evidence.

[0005] Third, the determination of the reason for call termination is too crude. Existing systems typically only categorize the reason for call termination based on the termination code in the session protocol signaling (such as BYE, CANCEL, 4xx / 5xx responses), such as "normal hang-up," "missed call," or "busy." This mechanism cannot accurately distinguish the specific party that hung up (e.g., whether the caller actively hung up, the called party rejected the call, the IVR automatically released after timeout, or the queue timed out and bounced back), nor can it reconstruct the complete causal chain leading to the termination, which is not conducive to investigating call anomalies.

[0006] Fourth, call duration statistics are based on a single dimension and are calculated in a coarse manner. Existing CDRs typically only provide a summary of the total call duration. While some systems can distinguish between ring duration and talk duration, they do not further break down the different stages of the call process. For example, they cannot accurately calculate key service quality indicators such as the user's dwell time in the IVR, the waiting time in the queue, and the duration the call is held. When the recording file length is inconsistent with the total call duration, administrators cannot determine whether it is due to a system anomaly or the user actively pausing the recording.

[0007] Therefore, there is an urgent need for a structured call process recording method that can uniformly correlate all stages of a complete call. Summary of the Invention

[0008] To provide a structured call recording method capable of uniformly associating all stages of a complete call, in a first aspect, embodiments of this application provide a call detail record generation method, the method comprising: When a call is initiated for the first time, a unique transaction identifier is generated for the call according to the encoding rules, which include communication type, destination type, call status and incrementing order. Create the first call stage identifier, route the call to the destination, and perform corresponding operations according to the destination type, which includes extension, queue, IVR, ringing group, call flow, and voicemail; During the call duration, events are captured in real time at each key node of the signaling processing to generate event timeline data. Based on the event timeline data and destination type, multi-dimensional duration calculations are performed for each call stage, including ringing duration, pure call duration, and dwell time, to generate duration data. The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, Hold / Resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage. If a call transfer occurs, a new call phase identifier is created, the new call phase identifier is associated with a unique transaction identifier, and the process re-enters the step of routing the call to its destination. A complete call detail record, including timelines, is generated based on duration and timeline data.

[0009] In one possible implementation, the step of capturing events in real time at each key node of signaling processing and generating event timeline data includes: Set up collection points at each key node of the signaling processing engine to capture key events in the call lifecycle in real time; The key events are grouped by call stage identifier and sorted by timestamp to generate structured event timeline data. Each event includes: timestamp, event type, event content, operation extension identifier, and front-end rendering icon type.

[0010] In one possible implementation, the calculation of multi-dimensional duration for each call phase, based on event timeline data and destination type, including ringing duration, pure call duration, and dwell time, includes: When the destination type is extension, the ringing duration is from the start of the ringing until the answer or timeout, and the pure call duration is the difference between the call duration and the call hold duration. When the destination type is queue, the ringing duration is the sum of the Join prompt tone, each round of ringing and the retry interval, the pure call duration is the pure call duration after the agent answers, and the waiting duration is the waiting time between the call entering the queue and being assigned to an agent. When the destination type is a ringing group, the total ringing duration is calculated according to the distribution strategy, and the pure call duration is the pure call duration after the call is answered. When the destination type is voicemail, the ringing duration is calculated from the time of the call, and the pure call duration is the voicemail duration. When the destination type is IVR, the dwell time is calculated from the time of entry, excluding the time without ringing. When the destination type is Call Flow, the dwell time is calculated from the time the component is entered, excluding the time without ringing.

[0011] In one possible implementation, the method further includes: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

[0012] In one possible implementation, the method further includes: If the call ends, the party that hung up and the reason for the end are determined based on the complete event sequence in the event timeline data. The reasons for the end include the caller actively hanging up, the called party rejecting the call, IVR timeout release, queue timeout bounce, and the call flow hang-up component executing the hang-up.

[0013] In one possible implementation, generating a unique transaction identifier for the call according to the encoding rules upon initiating the call for the first time includes: The transaction identifier adopts a structured coding strategy. When a call is initiated for the first time, the first digit of the transaction identifier is generated according to the communication type, which includes incoming call, outgoing call, and internal call; the second digit of the transaction identifier is generated according to the destination type; the third digit of the transaction identifier is generated according to the call status, which includes answered, missed call, and busy; the other digits of the transaction identifier are generated in ascending order; the first, second, third, and other digits are concatenated in sequence to generate the transaction identifier.

[0014] Secondly, embodiments of this application provide a call detail record generation apparatus, the apparatus comprising: The transaction identifier generation module is used to generate a unique transaction identifier for the call according to the encoding rules when the call is first initiated. The encoding rules include communication type, destination type, call status and incrementing order. The first call phase module is used to create the first call phase identifier, route the call to the destination, and perform corresponding operations according to the destination type, which includes extension, queue, IVR, ringing group, call flow, and voicemail. The acquisition module is used to capture events in real time at key nodes of signaling processing during the call duration, generate event timeline data, and perform multi-dimensional duration calculations for each call stage based on the event timeline data and destination type, including ringing duration, pure call duration, and dwell time, to generate duration data. The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage. The call transfer module is used to create a new call phase identifier if a call transfer occurs, associate the new call phase identifier with a unique transaction identifier, and re-enter the step of routing the call to the destination. The complete call detail record generation module is used to generate a complete call detail record including a timeline based on duration data and timeline data.

[0015] In one possible implementation, the device further includes a timing aggregation module for: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

[0016] In one possible implementation, the apparatus further includes an termination cause determination module, configured to: If the call ends, the party that hung up and the reason for the end are determined based on the complete event sequence in the event timeline data. The reasons for the end include the caller actively hanging up, the called party rejecting the call, IVR timeout release, queue timeout bounce, and the call flow hang-up component executing the hang-up.

[0017] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described call detail record generation methods.

[0018] The call detail record generation method provided in this application generates a unique transaction identifier for the call according to an encoding rule when the call is first initiated. This encoding rule includes communication type, destination type, call status, and incrementing order. An initial call stage identifier is created, and the call is routed to the destination. Corresponding operations are performed based on the destination type, which includes extension, queue, IVR, ringing group, and call. The method involves capturing events in real time at key nodes of signaling processing during a call, generating event timeline data. Based on the event timeline data and destination type, multi-dimensional duration calculations are performed for each call stage, including ringing duration, pure call duration, and dwell time, generating duration data. The key nodes are inevitable turning points in the call signaling processing flow that have business significance. Events include inbound / outbound events, routing events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, and hang-up events. Each event is marked with a timestamp and the current call stage identifier. If a call transfer occurs, a new call stage identifier is created, associated with a unique transaction identifier, and the process of routing the call to the destination is re-entered. A complete call detail record containing the timeline is generated based on the duration data and timeline data. This method can record a structured call process that uniformly associates all stages of a complete call. Attached Figure Description

[0019] Figure 1A schematic diagram of the first method for generating call details provided in an embodiment of this application; Figure 2 A system block diagram corresponding to the call detail record generation method provided in this application; Figure 3 This is a schematic diagram of a second flowchart of the call detail record generation method provided in the embodiments of this application. Detailed Implementation

[0020] Firstly, see [the following] Figure 1 This application provides a method for generating call detail records, the method comprising: S101, when a call is initiated for the first time, a unique transaction identifier is generated for the call according to the encoding rules.

[0021] The encoding rules include communication type, destination type, call status, and ascending order.

[0022] The transaction identifier adopts a structured coding strategy. When a call is initiated for the first time, the first digit of the transaction identifier is generated according to the communication type, which includes incoming call, outgoing call, and internal call; the second digit of the transaction identifier is generated according to the destination type; the third digit of the transaction identifier is generated according to the call status, which includes answered, missed call, and busy; the other digits of the transaction identifier are generated in ascending order; the first, second, third, and other digits are concatenated in sequence to generate the transaction identifier.

[0023] The first digit can be represented by Incoming Call (I), Outgoing Call (O), or Internal Call (N); the second digit can be represented by Extension (E), Queue (Q), IVR (V), Ringing Group (G), or Call Flow (F); and the third digit can be represented by Called (A), Missed Call (M), or Busy (B). The incrementing order can be a timestamp or a globally incrementing sequence. The transaction identifier is at least 5 bits (3 bits for type + ≥ 2 bits for sequence number). In one example, the other bits can be 0 or 1, indicating that the current stage is the first call. The transaction identifier can be used for reverse parsing to quickly obtain the basic attributes of the call.

[0024] S102, create the first call stage identifier, route the call to the destination, and perform the corresponding operation according to the destination type.

[0025] The destination types include extensions, queues, IVR, ringing groups, call flows, and voicemail.

[0026] For example, for extensions, the corresponding operation is to initiate a SIP INVITE to the extension, record the ringing start time, and if the extension is busy or does not answer, handle it according to the extension configuration (such as transferring to voicemail, returning to the queue, etc.); for queues, add the call to the queue waiting pool, record the entry time, and wait for agent allocation according to the queue strategy (polling, least calls, linear, etc.); for IVR, play the voice menu, wait for the user to press a key, record the entry time of IVR, and each key press event will be collected as part of the event timeline; for ringing groups, call all extensions in the group in parallel or in polling, record the ringing start time, and stop calling other members after any member answers; for Call Flow, execute the predefined process (such as playing a prompt tone, sending an HTTP request, transferring to an outside number, etc.), without generating a traditional ringing, and the dwell time is calculated separately; for voicemail, directly transfer to the voicemail system, start recording, and do not generate a ringing phase.

[0027] S103 captures events in real time at each key node of signaling processing during the call duration, generates event timeline data, and performs multi-dimensional duration calculations for each call stage based on the event timeline data and destination type, including ringing duration, pure call duration and dwell time, to generate duration data.

[0028] The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing and distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, response events, Hold / Resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage.

[0029] Specifically, key events in the call lifecycle can be captured in real time by setting up collection points at each key node of the signaling processing engine. The key events are grouped by call stage identifier and sorted by timestamp to generate structured event timeline data. Each event includes: timestamp, event type, event content, operation extension identifier, and front-end rendering icon type.

[0030] Event acquisition latency refers to the delay from signaling triggering to event writing to the timeline, typically less than or equal to 100ms. There is no hard limit to the maximum number of events that can be recorded in a single call, limited only by storage capacity. There is also no hard limit to the maximum number of transfers (Legs) in a single call. The timestamp is a precise millisecond-level timestamp of the event occurrence. Event content includes the operation entry point, terminal type, trunk information, DID (Direct Inward Dialing) number, etc., providing detailed event information to help administrators understand the operation context. Keyword search is supported, such as "Called in via trunk X, DID: 400-888-1234, pressed '1', routed to the technical support queue." The extension identifier is the internal user extension number that performed the operation. The front-end rendered icon type usually corresponds to the event type, making the event type immediately clear.

[0031] For incoming call events, the STIR / SHAKEN verification level is also included, indicating whether the caller ID has been verified, to help determine the credibility of the call. A is full verification, B is partial verification, and C is gateway verification.

[0032] Event timeline data is grouped by call stage identifiers and rendered in timeline format on the front end, supporting filtering and searching by event type.

[0033] Timestamp + current call stage identifier: This determines which call stage and time the event occurred, which is the basis for duration calculation (e.g., queue waiting time = allocated event timestamp - entered queue event timestamp).

[0034] Event type + event content: the former provides a quick classification, while the latter provides a detailed description, together forming a highly readable and searchable event log.

[0035] Operation extension identification: When a call involves multiple people (such as transfer, hold), the operator's extension is recorded to facilitate auditing and accountability.

[0036] Front-end rendering icon type: The front-end can quickly match icons based on this field, improving the user-friendliness of the interface.

[0037] Verification Level: For calls originating from external trunks, a security verification level is provided directly, helping administrators identify potentially fraudulent calls.

[0038] Through this set of structured fields, the event timeline data can not only fully preserve the details of the call process, but also support efficient front-end rendering, retrieval analysis, and duration calculation.

[0039] Multi-dimensional duration calculation can specifically include: When the destination type is extension, the ringing duration is from the start of the ringing until the answer or timeout, and the pure call duration is the difference between the call duration and the call hold duration. When the destination type is queue, the ringing duration is the sum of the Join prompt tone, each round of ringing and the retry interval, the pure call duration is the pure call duration after the agent answers, and the waiting duration is the waiting time between the call entering the queue and being assigned to an agent. When the destination type is a ringing group, the total ringing duration is calculated according to the distribution strategy, and the pure call duration is the pure call duration after the call is answered. When the destination type is voicemail, the ringing duration is calculated from the time of the call, and the pure call duration is the voicemail duration. When the destination type is IVR, the dwell time is calculated from the time of entry, excluding the time without ringing. When the destination type is Call Flow, the dwell time is calculated from the time the component is entered, excluding the time without ringing.

[0040] The ringing duration of the queue is the cumulative ringing time (excluding queuing wait) from the time the call enters the queue until the agent answers, represented by the sum of the Join prompt tone, each round of ringing, and the retry interval. The distribution strategy for ringing groups includes polling, concurrency, and priority. In concurrent ringing, the ringing duration is the time from the start of calling all extensions in the group until the first call is answered. The ringing group waiting time is the time from when a call enters the ringing group until any member answers, calculated by subtracting the entry into the ringing group event timestamp from the response event timestamp. The queue waiting time is the waiting time from when a call enters the queue until it is assigned to an agent, calculated by subtracting the entry into the queue event timestamp from the assignment event timestamp. The call hold duration is the total duration during which one or more parties are held (music wait) during the call, calculated by subtracting the corresponding hold timestamp from the Resume timestamp each time the call is resumed, and then accumulating the results.

[0041] S104, if a call transfer occurs, create a new call phase identifier, associate the new call phase identifier with a unique transaction identifier, and re-enter the step of routing the call to the destination.

[0042] If a call is transferred (supporting blind transfer, consultation transfer, semi-consultation transfer, redirect, bounce, etc.), the system creates a new call stage identifier (incrementing sequence number) and inherits the same transaction identifier. The new call stage re-enters the routing decision. All call stages within the same call share the same prefix (communication type + initial destination type + call status), and the stage order is distinguished by incrementing sequence number. Transfer chains of arbitrary depth are supported (blind transfer → consultation transfer → re-blind transfer), with the sequence number continuously incrementing without upper limit.

[0043] S105 generates a complete call detail record including timelines based on duration data and timeline data.

[0044] The call detail record generation method provided in this application generates a unique transaction identifier for the call according to an encoding rule when the call is first initiated. This encoding rule includes communication type, destination type, call status, and incrementing order. An initial call stage identifier is created, and the call is routed to the destination. Corresponding operations are performed based on the destination type, which includes extension, queue, IVR, ringing group, and call. The method involves capturing events in real time at key nodes of signaling processing during a call, generating event timeline data. Based on the event timeline data and destination type, multi-dimensional duration calculations are performed for each call stage, including ringing duration, pure call duration, and dwell time, generating duration data. The key nodes are inevitable turning points in the call signaling processing flow that have business significance. Events include inbound / outbound events, routing events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, and hang-up events. Each event is marked with a timestamp and the current call stage identifier. If a call transfer occurs, a new call stage identifier is created, associated with a unique transaction identifier, and the process of routing the call to the destination is re-entered. A complete call detail record containing the timeline is generated based on the duration data and timeline data. This method can record a structured call process that uniformly associates all stages of a complete call.

[0045] Report data is highly coupled with CDRs. Statistical reports in existing systems typically rely on real-time querying and calculation of raw CDR records. When the CDR data volume is large, real-time calculation consumes significant system resources. More critically, if an administrator deletes a raw CDR for storage reasons, the historical report data generated based on it will also be lost. Furthermore, in multi-node call scenarios (such as concurrent calls in a ringing group), the system may create hidden CDRs invisible to the user in order to generate accurate reports, leading to a discrepancy between the actual amount of data stored and the user's perception, increasing management complexity.

[0046] In one example, the method further includes: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

[0047] Administrators can configure the execution interval of scheduled tasks, for example, setting it to execute every 15 minutes. Each time a scheduled task runs, it queries the original CDR table for newly completed call records since the last run (determined by the end timestamp). Based on predefined system reporting requirements (such as hourly call volume statistics, average call duration statistics by agent, and queue waiting time distribution statistics), it performs batch calculations on these CDRs. During aggregation, it fully utilizes the pre-calculated multi-dimensional durations (pure call duration, queue waiting time, hold duration, etc.) and event timeline information in the CDRs. The aggregation results are written to a structured report table. The report table typically includes time granularity (e.g., 2026-05-23 14:00~15:00), dimension fields (queue ID, agent ID), and indicator fields (total number of calls, average pure call duration, etc.). Even if the administrator subsequently deletes the original CDRs (e.g., deleting records older than 90 days to save space), the data in the report table will not be deleted, thus ensuring the integrity of long-term statistical data.

[0048] This method also eliminates hidden intermediate records generated by multi-node calls. In traditional systems, to accurately count metrics for ringing groups or queues (such as "number of times each extension is rang"), the system may generate a hidden CDR for each sub-call. These records are invisible to users but are used for report queries.

[0049] In this application, this information is no longer stored via hidden CDRs, but is recorded through events such as "assignment events" and "ringing events" in the event timeline. A scheduled aggregation task directly scans the event timeline, extracting the necessary child node statistics (such as how many times a particular extension is rang within an hour), thus completely eliminating hidden records. Therefore, the number of CDRs seen by the user is exactly the same as the actual number of stored call segments (legs).

[0050] The method provided in this application transforms report queries into direct reading of pre-aggregated result tables, reducing response time from seconds or even minutes to milliseconds. Deleting original CDRs does not destroy historical reports, meeting the needs of enterprises for long-term data retention and compliance auditing. Hidden intermediate records are eliminated, and the number of CDRs stored in the system perfectly matches the user's perception, simplifying management. Multiple different aggregation tasks and report tables can be created for different reporting needs (daily, weekly, monthly, agent performance reports, etc.) without interference.

[0051] In one example, the method further includes: If the call ends, the party that hung up and the reason for the end are determined based on the complete event sequence in the event timeline data. The reasons for the end include the caller actively hanging up, the called party rejecting the call, IVR timeout release, queue timeout bounce, and the call flow hang-up component executing the hang-up.

[0052] When the system records the termination reason as Call Flow component routing, it means that the termination of the call (or leaving the current call phase) was caused by a routing action actively triggered by a component in Call Flow, rather than the user hanging up, the agent hanging up, or the system timeout.

[0053] Suppose an administrator designs a call flow to handle calls received after get off work hours: 1. Playback prompt: "We are currently off work. Please leave a message or press 1 to transfer to emergency contact."

[0054] 2. Collect user key presses: If the user presses 1, the call is transferred to the emergency contact extension (at this time, the Call Flow component performs the routing action to the extension, and the call leaves the Call Flow); if the user does not press any key and the timeout occurs (e.g., 10 seconds), the call is transferred to voicemail; if the user presses an invalid key (e.g., 9), the system retryes twice and then the Call Flow's hang-up component directly terminates the call.

[0055] In the third scenario described above, the final reason for the call termination is the Call Flow component routing (more precisely, "the Call Flow hang-up component performs the hang-up"). The system will not misinterpret this as "user hang-up" or "system timeout" because the termination action is issued by an explicit component instruction within the Call Flow process.

[0056] When administrators see a large number of calls ending via "Call Flow component routing," they can quickly pinpoint potential issues in the Call Flow design (e.g., incomplete invalid key handling logic, incorrect branch condition configuration). Avoid confusing this with "user-initiated hang-up" or "IVR timeout." IVR timeouts are typically triggered by internal system timers, while Call Flow component routing involves explicitly defined hang-up behaviors by the process designer (e.g., "if the user enters more than 3 incorrect characters, play a prompt and then hang up").

[0057] In certain industries that require recording call handling methods (such as finance and government), it is crucial to clearly distinguish between "automatic process actively terminated" and "user hung up".

[0058] Call Flow is a destination type, therefore it has differentiated duration calculation rules. When a Call Flow component executes routing or hangs up, the system collects an event, such as event_type="CallFlowComponent" with content="Invalid key presses exceeded 3 times, execute hang-up component". The termination reason is extracted from this event.

[0059] Call Flow component routing is a structured reason for call termination, indicating that the call ended because a certain route or hang-up component in the call flow was executed. It belongs to the system actively releasing according to preset logic, rather than natural hang-up or timeout.

[0060] See Figure 2This is a system block diagram corresponding to the call detail record generation method, divided into a call signaling layer, a CDR core processing layer, a destination specification layer, and a data storage and display layer. The SIP (Session Initiation Protocol) / signaling processing engine in the call signaling layer is responsible for processing all call-related SIP signaling (INVITE, BYE, REFER, NOTIFY, etc.), serving as the original source of call events. It sends signaling events to the event collector, forming the raw event stream. The CDR core processing layer includes a Transaction ID allocation and management module, a multi-stage Leg management module, an event timeline generation module, and a multi-dimensional duration calculation module. The Transaction ID allocation and management module generates a unique transaction identifier according to the encoding rules (communication type + destination type + status + incrementing sequence number) when a call is first initiated. All new Legs created due to transfers, switching, and routing inherit the same transaction identifier, with the sequence number incremented. The multi-stage Leg management module maintains the lifecycle of all Legs under the same transaction, manages the parent-child relationship and temporal relationship between Legs, and when a transfer occurs (blind transfer / consultation transfer / semi-consultation transfer / redirect / return), a new Leg is created and its association with the parent Leg is established. The event timeline generation module receives the raw events from the event collector, groups them by Leg affiliation, sorts them by timestamp, and generates a structured event timeline. Each event includes: timestamp, event type, content fields (operation entry, terminal type, relay information, DID number, etc.), operation extension identifier, and icon type. The multi-dimensional duration calculation module calculates multi-dimensional durations for each Leg based on the event timeline and destination general specifications, including: Ring Duration, Pure Talk Duration (pure talk duration, excluding Hold), and dwell time at each stage (IVR dwell, Call Flow dwell, queue waiting, etc.). Different calculation rules apply to different destination types. The destination specification layer defines the duration calculation rules and display specifications for various destinations (extensions, queues, IVRs, ringing groups, call flows, voicemail, conference rooms, AI reception, etc.). For example, the Ring Duration of a queue includes a Join prompt tone, each round of ringing, and a retry interval; IVRs have no ringing duration, and the dwell time is counted from the moment of entry.The data storage and presentation layer includes a CDR database, a scheduled aggregation report module, and a front-end presentation module. The CDR database stores the original CDRs generated based on duration data and timeline data. The scheduled aggregation report module performs CDR aggregation calculations through scheduled tasks within a configured time window, storing the report data independently. The aggregation results are decoupled from the original CDRs, so deleting a CDR does not affect existing reports, and it also eliminates hidden intermediate records of multi-node calls. The front-end presentation module aggregates and displays complete call records by transaction dimension, renders the event timeline (grouped by leg and distinguishing event types by icon), and displays multi-dimensional duration breakdowns.

[0061] See Figure 3This is a flowchart illustrating the call detail record generation method. When a call is first initiated (whether incoming or outgoing), the system immediately assigns a unique Transaction ID according to the coding rules. The code includes the communication type (incoming / outgoing / internal), destination type (extension / queue / IVR, etc.), status bit, and a globally incrementing sequence number. The first call phase (Leg 1) is created, and the call is directed to the destination according to the routing rules. The system enters the corresponding processing logic based on the destination type: if it is a Call Flow, the process components are executed; if it is a ringing group, polling / concurrency within the group is performed; if it is a queue, queuing is assigned; if it is an IVR, the voice menu is played; if it is an extension, the ringing occurs directly. During the call, the event collector captures events in real time at each key node of signaling processing, including but not limited to: incoming / outgoing events, routing events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, hang-up events, etc. Each event is marked with a precise timestamp and belongs to the current Leg. If a call is transferred (supporting blind transfer, consultation transfer, semi-consultation transfer, redirect, bounce, etc.), the system creates a new Leg that inherits the same Transaction ID, with the sequence number incremented. The new Leg re-enters the routing decision. At the end of the call, the system accurately determines the hanging party and the reason for termination (e.g., caller actively hanging up, called party rejecting, IVR timeout release, queue timeout bounce, CallFlow component routing, etc.) based on the complete event sequence in the event timeline, recording it as a structured hang-up event. Based on the destination type of each Leg, differentiated duration calculation rules are applied to calculate Ring Duration, Pure Talk Duration, and Time Breakdown (Time Breakdown can be further broken down into: IVR dwell time, Call Flow dwell time, queue waiting time, total Hold time, etc., allowing administrators to analyze call quality from multiple dimensions). The complete CDR (including transaction identifier, all Legs, event timeline, and multi-dimensional duration) is written to the database. Scheduled aggregation tasks are executed according to the configured cycle, independently writing the data required for reporting to the report table.

[0062] This application uses Transaction ID encoding rules to connect the entire call from initiation to termination. Regardless of the number of transfers / transfers / routings, all legs always belong to the same transaction, allowing a single query to obtain the complete call overview. Supplementary data (notes, recordings, AI transcriptions / summaries) are aggregated with the transaction, no longer fragmented and scattered, achieving unified association throughout the entire call lifecycle.

[0063] The structured event timeline records key operations and status changes throughout the entire call process, including routing paths, IVR interactions, transfer links, and Hold operations. This allows for precise determination of the reason for call termination (down to the party hanging up and the causal chain). Administrators can troubleshoot issues without manual speculation, ensuring accurate and traceable call processes.

[0064] Differentiated duration calculation rules were established for 21 destination types, distinguishing between multiple dimensions such as ringing duration, pure call duration, hold duration, and IVR / queue waiting time. This multi-dimensional and refined duration analysis provides accurate data support for call quality assessment. Comparison of recording duration with pure call duration can accurately pinpoint the causes of recording anomalies.

[0065] The timed aggregation mechanism decouples report data from CDR, allowing report data to be stored independently. Deleting CDR does not affect historical reports. Eliminating hidden data ensures that the system's storage capacity is completely consistent with the user's perception. Asynchronous computing reduces real-time performance consumption.

[0066] Transaction ID encoding supports transfer chains of arbitrary depth, offering high scalability and compatibility; event types and destination types are extensible; and the timeline structure supports seamless integration of new event types.

[0067] In one example, in a company's communication system, an incoming external call goes through the following complete process: 1. Incoming calls from external numbers reach the system via trunk lines; 2. The system assigns a Transaction ID and creates Leg 1; 3. The call enters IVR mode; the caller presses "1" to select technical support. 4. The IVR routes the call to the technical support queue, creating Leg 2; 5. The call is assigned to extension A in the queue; answer the call after it rings. 6. During a call, Agent A transfers the consultation to Agent B, creating Leg 3; 7. Agent B answers the call, Agent A exits the call; 8. During the call between the caller and agent B, agent B performs a hold operation; 9. Agent B releases Hold and continues the call; 10. The caller hangs up on their own initiative.

[0068] The timeline of events for the above process is shown in Table 1.

[0069] Table 1: Event Timeline

[0070] The multi-dimensional duration calculation results of the above process are shown in Table 2.

[0071] Table 2: Multi-dimensional Duration

[0072] Administrators can view the complete call path using a single Transaction ID, including all stages such as IVR navigation, queueing, agent answering, inquiry transfer, and Hold. The reason for call termination is accurately recorded as "caller hung up," eliminating the need for speculation. Multi-dimensional duration breakdown allows for precise positioning of the time spent at each stage, facilitating service quality optimization. Comparing the recording duration with PureTalk Duration accurately determines the integrity of the recording.

[0073] One parameter setting is as follows: timed aggregation period of 15 minutes; event collection delay ≤50ms; 21 standard destination types; STIR / SHAKEN verification enabled, supporting A / B / C levels and Invalid / Unknown.

[0074] Secondly, embodiments of this application provide a call detail record generation apparatus, the apparatus comprising: The transaction identifier generation module is used to generate a unique transaction identifier for the call according to the encoding rules when the call is first initiated. The encoding rules include communication type, destination type, call status and incrementing order. The first call phase module is used to create the first call phase identifier, route the call to the destination, and perform corresponding operations according to the destination type, which includes extension, queue, IVR, ringing group, call flow, and voicemail. The acquisition module is used to capture events in real time at key nodes of signaling processing during the call duration, generate event timeline data, and perform multi-dimensional duration calculations for each call stage based on the event timeline data and destination type, including ringing duration, pure call duration, and dwell time, to generate duration data. The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage. The call transfer module is used to create a new call phase identifier if a call transfer occurs, associate the new call phase identifier with a unique transaction identifier, and re-enter the step of routing the call to the destination. The complete call detail record generation module is used to generate a complete call detail record including a timeline based on duration data and timeline data.

[0075] In one possible implementation, the device further includes a timing aggregation module for: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

[0076] In one possible implementation, the apparatus further includes an termination cause determination module, configured to: If the call ends, the party that hung up and the reason for the end are determined based on the complete event sequence in the event timeline data. The reasons for the end include the caller actively hanging up, the called party rejecting the call, IVR timeout release, queue timeout bounce, and the call flow hang-up component executing the hang-up.

[0077] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described call detail record generation methods.

[0078] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0079] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0080] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are described simply because they are similar to the method embodiments; relevant parts can be referred to the descriptions of the method embodiments.

[0081] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A call detail record generation method, characterized by, The method includes: When a call is initiated for the first time, a unique transaction identifier is generated for the call according to the encoding rules, which include communication type, destination type, call status and incrementing order. Create the first call stage identifier, route the call to the destination, and perform corresponding operations according to the destination type, which includes extension, queue, IVR, ringing group, call flow, and voicemail; During the call duration, events are captured in real time at each key node of the signaling processing to generate event timeline data. Based on the event timeline data and destination type, multi-dimensional duration calculations are performed for each call stage, including ringing duration, pure call duration, and dwell time, to generate duration data. The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, Hold / Resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage. If a call transfer occurs, a new call phase identifier is created, the new call phase identifier is associated with a unique transaction identifier, and the process re-enters the step of routing the call to its destination. A complete call detail record, including timelines, is generated based on duration and timeline data.

2. The method of claim 1, wherein, The process of capturing events in real time at each key node of signaling processing and generating event timeline data includes: Set up collection points at each key node of the signaling processing engine to capture key events in the call lifecycle in real time; The key events are grouped by call stage identifier and sorted by timestamp to generate structured event timeline data. Each event includes: timestamp, event type, event content, operating extension identifier, and front-end rendering icon type.

3. The method of claim 1, wherein, Based on event timeline data and destination type, the system performs multi-dimensional duration calculations for each call phase, including ringing duration, pure call duration, and dwell time, including: When the destination type is extension, the ringing duration is from the start of the ringing until the answer or timeout, and the pure call duration is the difference between the call duration and the call hold duration. When the destination type is queue, the ringing duration is the sum of the Join prompt tone, each round of ringing and the retry interval, the pure call duration is the pure call duration after the agent answers, and the waiting duration is the waiting time between the call entering the queue and being assigned to an agent. When the destination type is a ringing group, the total ringing duration is calculated according to the distribution strategy, and the pure call duration is the pure call duration after the call is answered. When the destination type is voicemail, the ringing duration is calculated from the time of the call, and the pure call duration is the voicemail duration. When the destination type is IVR, the dwell time is calculated from the time of entry, excluding the time without ringing. When the destination type is Call Flow, the dwell time is calculated from the time the component is entered, excluding the time without ringing.

4. The method of claim 1, wherein, The method further includes: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

5. The method of claim 1, wherein, The method further includes: If the call ends, the party that hung up and the reason for the end are determined based on the complete event sequence in the event timeline data. The reasons for the end include the caller actively hanging up, the called party rejecting the call, IVR timeout release, queue timeout bounce, and the call flow hang-up component executing the hang-up.

6. The method according to claim 1, characterized in that, The step of generating a unique transaction identifier for the call according to the encoding rules when initiating the first call includes: The transaction identifier adopts a structured coding strategy. When a call is initiated for the first time, the first digit of the transaction identifier is generated according to the communication type, which includes incoming call, outgoing call, and internal call; the second digit of the transaction identifier is generated according to the destination type; the third digit of the transaction identifier is generated according to the call status, which includes answered, missed call, and busy; the other digits of the transaction identifier are generated in ascending order; the first, second, third, and other digits are concatenated in sequence to generate the transaction identifier.

7. A call detail record generating apparatus characterized by comprising: The device includes: The transaction identifier generation module is used to generate a unique transaction identifier for the call according to the encoding rules when the call is first initiated. The encoding rules include communication type, destination type, call status and incrementing order. The first call phase module is used to create the first call phase identifier, route the call to the destination, and perform corresponding operations according to the destination type, which includes extension, queue, IVR, ringing group, call flow, and voicemail. The acquisition module is used to capture events in real time at key nodes of signaling processing during the call duration, generate event timeline data, and perform multi-dimensional duration calculations for each call stage based on the event timeline data and destination type, including ringing duration, pure call duration, and dwell time, to generate duration data. The key nodes are turning points that inevitably occur in the call signaling processing flow and have business significance. The events include inbound / outbound events, routing distribution events, destination entry events, IVR button events, queue queuing / exit events, transfer initiation / completion events, answer events, hold / resume events, and hang-up events. Each event is marked with a timestamp and the identifier of the current call stage. The call transfer module is used to create a new call phase identifier if a call transfer occurs, associate the new call phase identifier with a unique transaction identifier, and re-enter the step of routing the call to the destination. The complete call detail record generation module is used to generate a complete call detail record including a timeline based on duration data and timeline data.

8. The apparatus of claim 7, wherein, The device further includes a timing aggregation module for: Perform a timed aggregation operation on the generated complete call details to obtain aggregated data; The aggregated data is stored independently to decouple it from the generated complete call details. The aggregated data is displayed by transaction dimension, and the event timeline is rendered to show multi-dimensional duration breakdown.

9. The apparatus of claim 7, wherein, The device further includes an termination reason determination module, used for: If the call ends, the hangup party and the end reason are determined based on the complete event sequence in the event timeline data, the end reason including the caller actively hanging up, the callee rejecting, IVR timeout releasing, queue timeout bouncing back, and the call flow hangup component executing hangup.

10. A computer-readable storage medium, characterized in that, The computer program is stored in the computer readable storage medium and is executed by the processor to implement the method in any one of claims 1-6.

Images