Call recording processing method and device and storage medium

Abstract

The invention discloses a call recording processing method and device and a storage medium, and relates to the technical field of multimedia communication, and the call recording processing method comprises the following steps: in response to a recording starting instruction, analyzing an SIP signaling to obtain an IP address and a port number of an RTP stream; according to the IP address and the port number, RTP data packets are extracted from the RTP stream, and the SSRC and the serial number of each RTP data packet are recorded; based on the SSRC and the serial number, recombining the RTP data packet to obtain a complete call audio; decoding the call audio according to the encoding and decoding information of the RTP stream to obtain audio data; and carrying out compression coding on the audio data to generate a sound recording file. According to the method and the device, the SIP signaling is analyzed and the RTP data packet is recombined, so that the problem that the RTP data packet is possibly out of order in the transmission process is solved, and the integrity of the finally generated recording file is ensured.

Description

Technical Field

[0001] The present application relates to the field of multimedia communication technology, and in particular to a call recording processing method, device, and storage medium. Background Art

[0002] In customer service contact centers, call recording systems need to capture, process, and store large amounts of call media streams in real time. Current call recording systems based on the ARM (Advanced RISC Machine) platform, a reduced instruction set processor architecture, can experience packet loss or data out-of-sequence due to complex network environments and unstable data transmission. This can affect the quality of the resulting recording files and prevent them from being fully protected.

[0003] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a call recording processing method, device and storage medium, aiming to solve the technical problem that data packet loss and misordering affect the integrity of recording in the call recording system.

[0005] To achieve the above objectives, an embodiment of the present application provides a call recording processing method, the call recording processing method comprising: In response to the recording start instruction, parsing the SIP signaling to obtain the IP address and port number of the RTP stream; Extracting RTP packets from the RTP stream according to the IP address and the port number, and recording the SSRC and sequence number of each RTP packet; Reassemble the RTP data packets based on the SSRC and the sequence number to obtain the complete call audio; Decoding the call audio according to the encoding and decoding information of the RTP stream to obtain audio data; The audio data is compressed and encoded to generate a recording file.

[0006] In one embodiment, the step of parsing the SIP signaling to obtain the IP address and port number of the RTP stream in response to the recording start instruction includes: In response to the recording start instruction, obtaining SDP description information in the SIP signaling; Based on the SDP description information, the IP address and port number of the RTP stream are extracted.

[0007] In one embodiment, before the step of obtaining the SDP description information in the SIP signaling in response to the recording start instruction, the call recording processing method further includes: Parsing the SIP signaling to obtain session identification information of the SIP signaling, wherein the session identification information includes a calling number, a called number, a call identifier, and a device type; According to the session identification information, the corresponding recording task is started.

[0008] In one embodiment, after the step of starting the corresponding recording task according to the session identification information, the method further includes: If a BYE packet of the SIP signaling is detected, or if no RTP data packet is obtained within a preset time period, the current recording task is terminated.

[0009] In one embodiment, the step of reassembling the RTP data packet based on the SSRC and the sequence number to obtain the complete call audio includes: Determine the RTP data packet corresponding to the RTP stream according to the SSRC; The RTP data packets are sorted according to the sequence numbers, and the RTP data packets are reassembled according to the sorting results to obtain the complete call audio.

[0010] In one embodiment, the step of sorting the RTP data packets according to the sequence numbers and reassembling the RTP data packets according to the sorting results to obtain the complete call audio includes: When it is detected that the sequence numbers are discontinuous, calculating the audio loss duration based on the timestamps of adjacent RTP data packets; generating, according to the silence data format corresponding to the codec information, a compensation data packet matching the duration of the audio loss; The compensation data packet is inserted into the discontinuous position of the sequence number to fill the lost RTP data packet and obtain the complete call audio.

[0011] In one embodiment, the step of compressing and encoding the audio data to generate a recording file includes: Select the corresponding compression encoding format according to the preset storage requirements; The audio data is compressed and encoded according to the compression encoding format, and the recording file is generated according to a preset file naming rule.

[0012] In one embodiment, before the step of extracting RTP packets from the RTP stream according to the IP address and the port number, and recording the SSRC and sequence number of each RTP packet, the method includes: Extracting the RTP data packet from the RTP stream according to the IP address and the port number; The RTP data packet is stored in a buffer to prevent the RTP data packet from being lost.

[0013] An embodiment of the present application also provides a call recording processing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the call recording processing method described above.

[0014] An embodiment of the present application further provides a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the call recording processing method described above are implemented.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application can obtain the IP address and port number of the RTP stream by parsing the SIP signaling, providing an accurate transmission path for the subsequent extraction of RTP data packets. On this basis, the RTP data packets are extracted according to the IP address and port number, and the SSRC and sequence number of each RTP data packet are recorded. When the RTP data packets are out of order, the RTP data packets can be reorganized, effectively solving the disorder problem of the RTP data packets and ensuring the timing correctness and integrity of the call audio. The call audio is decoded according to the codec information of the RTP stream, so that the call recording system can adapt to different codec formats, avoid the problem of audio decoding failure caused by codec format mismatch, and improve the compatibility of audio decoding. In addition, by compressing and encoding the decoded audio data, recording files in different formats such as WAV and MP3 can be generated, which significantly reduces the storage space requirements of the recording files and improves storage efficiency. The integrity of the final generated recording file is ensured by the above technical means. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flowchart of a first embodiment of a call recording processing method according to an embodiment of the present application; Figure 2 This is a flow chart of a second embodiment of a call recording processing method according to an embodiment of the present application; Figure 3 This is a flowchart of a third embodiment of a call recording processing method according to an embodiment of the present application; Figure 4 This is a structural diagram of the call recording processing device involved in the embodiment of the present application.

[0017] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0018] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0019] In customer service contact centers, call recording systems need to capture, process, and store large amounts of call media streams in real time. Current call recording systems based on the ARM (Advanced RISC Machine) platform, a reduced instruction set processor architecture, can experience packet loss or data out-of-sequence due to complex network environments and unstable data transmission. This can affect the quality of the resulting recording files and prevent them from being fully protected.

[0020] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0021] The main solution of the embodiment of the present application is: in response to the recording start instruction, parse the SIP signaling to obtain the IP address and port number of the RTP stream; extract the RTP data packet from the RTP stream according to the IP address and the port number, and record the SSRC and sequence number of each RTP data packet; based on the SSRC and the sequence number, reassemble the RTP data packet to obtain the complete call audio; decode the call audio according to the encoding and decoding information of the RTP stream to obtain audio data; compress and encode the audio data to generate a recording file. The present application obtains the IP address and port number of the RTP stream by parsing the SIP signaling, and then accurately obtains and reassembles the RTP data packet, effectively avoiding the loss problem caused by improper data packet processing and ensuring the integrity of the call audio. At the same time, by decoding and compressing the call audio, a high-quality recording file is generated, thereby improving the traceability of the recording file.

[0022] It should be noted that the execution entity of this embodiment can be a call recording system based on the ARM platform, or a computing service device with data processing, network communication, and program execution functions, such as a recording server or media processing gateway deployed in a customer service contact center, or an electronic device or intelligent communication terminal capable of implementing the above functions. The following uses the call recording system as an example to illustrate this embodiment and the following embodiments.

[0023] The call recording processing method of the first embodiment proposed in this application, please refer to Figure 1 The method includes steps S10 to S50: Step S10: In response to the recording start instruction, parse the SIP signaling to obtain the IP address and port number of the RTP stream.

[0024] It's important to note that SIP (Session Initiation Protocol) signaling is a communications protocol used to establish, modify, and terminate multimedia sessions. During a call, SIP signaling includes relevant information used to negotiate the call, such as the called number, calling number, the IP addresses corresponding to the called and calling numbers, media types, and encoding formats. RTP (Real-time Transport Protocol) is a protocol for transmitting real-time data, such as audio and video. An RTP stream is a continuous media stream transmitted via the RTP protocol, responsible for carrying the actual audio data during a call. The IP address and port number identify the network transmission path for the RTP stream.

[0025] Specifically, when the calling terminal initiates a communication request, it sends an INVITE packet to the target terminal via the SIP protocol. The INVITE packet contains relevant information for negotiating the call, such as the calling number, called number, supported media types, and the IP address and port information of the calling terminal itself. After receiving the INVITE packet, if the target terminal accepts the communication request, it will send a response packet to the calling terminal. The response packet contains the IP address and port number used by the target terminal to transmit the RTP stream. After receiving the response packet, the calling terminal parses the SDP description information about the SIP signaling in the response packet and extracts the IP address and port number of the RTP stream. Subsequently, the calling terminal determines a port number for sending the RTP stream and sends it to the target terminal via an ACK packet, completing the call establishment and the negotiation of the RTP stream transmission path. The calling terminal and the target terminal establish an RTP stream transmission channel through the obtained IP address and port number, realizing real-time transmission of call audio data.

[0026] In this embodiment, when the call recording system detects an INVITE packet in SIP signaling and parses the INVITE packet to extract the calling number, called number, call ID, and calling terminal information, it indicates that the calling and called numbers have begun a voice call, and call recording is immediately started. Alternatively, the call recording system will also start recording when a manual recording start command is received.

[0027] It can be understood that this embodiment obtains the IP address and port of the RTP stream by parsing SIP signaling, ensuring that the call recording system can accurately capture and process call data, avoid call data loss and missequencing problems, and improve the integrity and traceability of subsequently generated recording files.

[0028] In a feasible implementation, step S10 may include steps S110 to S120: Step S110: In response to the recording start instruction, obtain the SDP description information in the SIP signaling.

[0029] It's important to note that SDP description information is a text format used to describe multimedia sessions, typically included in the body of SIP signaling messages. SDP description information informs the target terminal of the relevant parameters of the media stream, allowing both parties to correctly establish and process the media session. The SDP description includes information such as the media type (such as audio or video), transport protocol, port number, IP address, and codec information for the media stream.

[0030] Before step S110, the process further includes steps S101 and S102: Step S101: Parse the SIP signaling to obtain session identification information of the SIP signaling, where the session identification information includes a calling number, a called number, a call identification, and a device type.

[0031] Step S102: starting a corresponding recording task according to the session identification information.

[0032] It's important to note that when the call recording system detects SIP signaling, it parses it and retrieves the session identifier from the INVITE packet within it. This session identifier includes information such as the calling number, called number, call ID, and device type (i.e., the calling terminal's information).

[0033] For example, the invite packet in SIP signaling contains the following data: "Request-Line: INVITE sip: 8004@192.168.104.10 SIP / 2.0 Call-ID: example123@192.168.123.123 From:<sip:8001@192.168.123.123> To:<sip:8004@192.168.104.10> User-Agent: ABCD" The "Request-Line: INVITE sip:8004@192.0.104.10 SIP / 2.0" is the request line. INVITE, as the request method, is used to initiate a session invitation to establish a new session with another endpoint. In a call scenario, when the calling endpoint wishes to initiate a voice call with the target endpoint, it sends a SIP message with the INVITE method to initiate the call establishment process.

[0034] "sip:8004@192.168.104.10" is the request URI (Uniform Resource Identifier). "sip" indicates the protocol used for the call. "8004" is the called number, used to distinguish different terminal devices. "192.168.104.10" is the network IP address of the target terminal. "SIP / 2.0" indicates that the SIP protocol version used is 2.0. Different versions of the SIP protocol may have functional differences. Explicitly specifying the protocol version helps ensure that both parties have a consistent understanding and processing of the protocol, ensuring smooth communication.

[0035] "Call-ID" is a call identifier, used to confirm that the message belongs to the same call session. "From" indicates the calling terminal information, and "8001" is the calling number, which is used to identify the terminal device initiating the call invitation. "192.168.123.123" is the IP address of the calling terminal. "To" indicates the target terminal information, and "8004" is the called number, which is used to identify the target terminal. "192.168.104.10" is the IP address of the target terminal. The calling terminal uses the "To" field to specify the target terminal with which it wishes to establish a call connection. The "User-Agent" field indicates the type of terminal device being called.

[0036] It should be noted that the IP addresses in the above examples are only used for example demonstration. In actual call scenarios, IP addresses will be allocated based on the specific network environment and the actual deployment of terminal devices.

[0037] By parsing the INVITE packet in SIP signaling, the call recording system can obtain the session identification information for the current call. This information includes the calling number 8001, the called number 8004, the call ID example123@192.168.123.123, and the calling terminal device type ABCD. Based on this session identification information, the call recording system determines that a voice call has begun between the calling number 8001 and the called number 8004. It then automatically activates the call recording function and begins recording the current call.

[0038] Furthermore, after step S102, the method further includes: if a BYE packet of the SIP signaling is detected, or if no RTP data packet is obtained within a preset time period, terminating the current recording task.

[0039] To ensure the integrity and accuracy of call recordings, the call recording system has added a call termination detection mechanism. In SIP-based call scenarios, the end of a call is typically signaled by a BYE packet in SIP signaling. The BYE packet is a signaling message in the SIP protocol used to terminate a session. When either end of a call wishes to end the current call, they send a BYE packet to the other party, notifying them of the impending call termination.

[0040] When the call recording system detects a BYE packet, it can determine that the current call has ended. At this time, it terminates the current recording task, which can avoid recording unnecessary blanks or erroneous information and ensure that the recording file accurately reflects the actual content of the call.

[0041] Furthermore, due to the uncertainty and complexity of the network environment, RTP packet loss or transmission interruptions may occur. The default period of time during which RTP packets are not received is also used as a condition for terminating the recording task. This is because during a call, if there is no RTP packet transmission for an extended period, it may indicate that the call has been abnormally terminated. Terminating the recording task at this time ensures the effectiveness and accuracy of the recording. The default period is a time threshold and can be adjusted based on the actual application scenario and network environment.

[0042] It's important to note that the call recording system identifies the corresponding call session by matching the "Call-ID" field in the BYE packet. Since the Call-ID remains unchanged throughout the call, by comparing the "Call-ID" in the BYE packet with the "Call-ID" associated with the currently active recording task, the call corresponding to the BYE packet can be accurately determined, thereby terminating the corresponding recording task.

[0043] Step S120: extracting the IP address and port number of the RTP stream based on the SDP description information.

[0044] In a call scenario, SDP description information is typically transmitted in INVITE packets or response packets. When the calling terminal sends an INVITE packet, the SDP description carried in the INVITE packet contains key fields related to the media stream, such as the media type (such as audio or video), transport protocol, port number of the media stream, IP address, and codec information. Therefore, extracting the IP address and port number of the RTP stream from the SDP description ensures that the call recording system captures RTP packets from the correct network path and records the call audio.

[0045] Step S20: extracting RTP data packets from the RTP stream according to the IP address and the port number, and recording the SSRC and sequence number of each RTP data packet.

[0046] It's important to note that RTP packets are the basic units for real-time media data transmission. During a call, media data (such as audio or video) is divided into multiple smaller data units, known as RTP packets, and transmitted over the network. These RTP packets are sent in a specific order and at specific intervals, forming a continuous RTP stream. The SSRC is a 32-bit unsigned integer that identifies the media source sending the RTP packets. The sequence number indicates the order in which the RTP packets are sent.

[0047] Based on the IP address and port number, the call recording system can locate the RTP stream associated with the current call and extract the RTP packets within that stream. During the extraction process, the call recording system also records the SSRC (Synchronization Source Identifier) and sequence number of each packet.

[0048] Specifically, the call recording system monitors a designated IP address and port number through a network interface, capturing all network packets passing through that IP address and port. Since RTP packets are typically encapsulated within the UDP protocol, the system first identifies the UDP packet header and determines whether it conforms to the RTP protocol. Once confirmed as an RTP packet, the call recording system further parses the RTP packet header fields to extract the SSRC and sequence number for each RTP packet.

[0049] In this embodiment, due to the uncertainty and complexity of the network environment, RTP packets may be out of order during transmission. Therefore, the call recording system can sort and reassemble the RTP packets according to the sequence number to ensure the continuity and correctness of the media data.

[0050] In a feasible implementation manner, step S20 may further include steps S201 and S202 before step S20: Step S201: extracting the RTP data packet from the RTP stream according to the IP address and the port number.

[0051] Step S202: storing the RTP data packet in a buffer to prevent the RTP data packet from being lost.

[0052] To improve the efficiency and accuracy of data processing, a caching mechanism can be used. While extracting RTP packets, they are temporarily stored in a buffer to prevent data loss. Furthermore, the RTP packets in the buffer can be monitored in real time. When the buffer is full or a preset time interval is reached, batch processing of the RTP packets in the buffer is performed, such as sorting, reassembling, or compressing them.

[0053] Exemplarily, SSRC is used to identify different media sources, and RTP data packets belonging to the same media source are grouped and merged.

[0054] In another feasible embodiment, multiple threads are used to capture packets in parallel, with each thread processing a portion of the packets, thereby significantly improving data processing efficiency. By assigning the capture and processing of RTP packets to multiple threads, efficient processing of RTP streams can be achieved. Each thread can independently extract RTP packets from the network and store the RTP packets in a shared buffer.

[0055] Furthermore, to improve RTP packet capture efficiency and avoid unnecessary processing of irrelevant packets, a Berkeley Packet Filter (BPF) can be used to filter captured packets. BPF filters filter packets based on preset rules (such as protocol type, port number, and IP address), effectively capturing the desired RTP packets.

[0056] Step S30: Based on the SSRC and the sequence number, reassemble the RTP data packet to obtain the complete call audio.

[0057] After obtaining the SSRC and sequence number of the RTP packet, the packets are first grouped according to the SSRC field. RTP packets with the same SSRC value are considered to come from the same media source and belong to the same call media stream. In this way, packets from different media sources can be distinguished.

[0058] RTP packets in the same media stream are sorted by sequence number. Sequence numbers are incremented in the order in which the packets were sent, so sorting ensures that the packets are reassembled in the correct order.

[0059] By comparing the difference between the sequence number of the newly arrived RTP data packet and the maximum sequence number corresponding to the RTP data packet in the buffer, it is determined whether packet loss has occurred (such as the difference is greater than 1) or disorder (such as the difference is less than 0).

[0060] Step S40: Decode the call audio according to the encoding and decoding information of the RTP stream to obtain audio data.

[0061] It's important to note that when parsing SIP signaling, the SDP description includes not only the IP address and port number of the RTP stream, but also codec information. This codec information determines the encoding format and parameters of the audio data. Common codec standards include PCM (Pulse Code Modulation), G.711, and Opus.

[0062] In real-time communications, audio data is often compressed during transmission to reduce data size and facilitate efficient transmission. Codec information specifies the compression format and parsing method for audio data. Decoding converts the encoded audio data back to its original, processable format. Since most audio processing and storage operations are based on the PCM (Pulse Code Modulation) format, decoded audio data is typically converted to PCM.

[0063] It's important to note that PCM is an uncompressed audio data format that represents audio signals in their raw, sampled form, making it easier to process them, such as editing, storing, or re-encoding them. For example, Opus-encoded audio requires decoding using the libopus library, setting the appropriate sampling rate and number of channels, and ultimately converting it to PCM audio data.

[0064] Step S50: compress and encode the audio data to generate a recording file.

[0065] It should be noted that the decoded audio data may occupy a lot of storage space, so the audio data needs to be compressed and encoded to reduce the space occupied.

[0066] For example, in step S40, the decoded audio data is presented in PCM format. Since the audio data in PCM format is relatively large, in order to reduce storage space, the audio data in PCM format needs to be compressed and encoded to generate a recording file suitable for storage and transmission.

[0067] It should be noted that common recording file formats include WAV (Waveform Audio File Format), MP3 (Moving Picture Experts Group Audio Layer III), Opus, and AAC (Advanced Audio Coding). The call recording system selects the target format based on configuration parameters, including application scenario type, audio quality requirements, default settings, and storage policy.

[0068] In one feasible implementation, the call recording system passes decoded PCM audio data to the encoder process via a data processing interface, simultaneously writing metadata (such as the caller ID and call timestamp). This metadata records key information such as the source and time of the recorded file. For high-concurrency scenarios, the call recording system can utilize a thread pool for asynchronous encoding, preventing encoding tasks from blocking the processing of real-time RTP packets. The thread pool dynamically allocates thread resources based on the current call recording system load, ensuring efficient encoding for each recording task. The resulting recording files are named according to a pre-set naming convention (e.g., "Caller ID_Called ID_Timestamp.mp3") to facilitate subsequent retrieval and management. Furthermore, the call recording system creates an index for each recording file for fast retrieval and access.

[0069] In this embodiment, by parsing SIP signaling, the call recording system accurately obtains the IP address and port number of the RTP stream, ensuring that the RTP packets corresponding to the RTP stream are captured from the correct network path. During the RTP packet capture process, the SSRC and sequence number of each RTP packet are recorded. This allows the call recording system to sort and reassemble the RTP packets based on the SSRC and sequence number if RTP packets are out of order, thereby restoring the complete call audio stream.

[0070] Based on the RTP stream's codec information, the call recording system decodes the call audio to obtain processable audio data. It then compresses and encodes the audio data to generate recording files in various formats, tailored to specific needs. This allows for recording of call audio, meeting storage and usage requirements in various scenarios. Furthermore, at the end of a call, the recording task is terminated by detecting a BYE packet or failing to receive an RTP packet within a preset time period, ensuring the effectiveness and accuracy of call recording.

[0071] To further improve the processing efficiency and stability of the call recording system, the system uses a BPF filter to filter captured packets before extracting them. This accurately identifies RTP packets, avoids unnecessary processing of irrelevant packets, and effectively reduces processing latency. Furthermore, the system utilizes multi-threaded parallel processing, allowing each thread to independently process a portion of the RTP packets, further enhancing the system's concurrent processing capabilities.

[0072] In summary, this embodiment not only ensures the integrity and accuracy of call recordings, but also effectively addresses the limited computing resources of the ARM platform in high-concurrency scenarios. By employing technologies such as BPF filters and multi-threaded parallel processing, the call recording system significantly improves the efficiency and stability of capturing and processing RTP packets, thereby reducing the risk of packet loss and ensuring the quality of call recordings.

[0073] Based on the above embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be described in detail later. Figure 2 , step S30 further includes steps S310 to S320: Step S310: Determine the RTP data packet corresponding to the RTP stream according to the SSRC.

[0074] It's important to note that within a communication session, each media stream has a unique SSRC identifier. By parsing the SSRC field in the RTP packet header, RTP packets belonging to the same media stream are grouped together to ensure that the RTP packets of each media stream are not confused with those of other media streams during subsequent processing.

[0075] In one possible implementation, a data structure, such as a dictionary or hash table, is maintained. This data structure uses the SSRC as a key and stores a list of RTP packets corresponding to that SSRC as a value. When an RTP packet is received, the SSRC is first extracted from the RTP packet header. The data structure then checks to see if a list corresponding to that SSRC already exists. If so, the RTP packet is added to the corresponding list. If not, a new list is created and the RTP packet is added as the first element, completing the grouping of the RTP packets.

[0076] Step S320: Sort the RTP data packets according to the sequence numbers, and reassemble the RTP data packets according to the sorting results to obtain the complete call audio.

[0077] It should be noted that due to network fluctuations and other reasons, RTP packets may not arrive at the receiver in the order they were sent. Therefore, RTP packets need to be sorted to ensure data integrity and continuity.

[0078] In this embodiment, the RTP packets corresponding to the same RTP stream are sorted by sequence number. After the sorting is completed, the RTP packets are reassembled based on the sorting results to obtain the complete call audio. Optionally, the RTP packets are inserted into a doubly linked list queue and sorted in ascending order by sequence number.

[0079] In a feasible implementation manner, step S320 further includes steps S3210 to S3230: Step S3210: When it is detected that the sequence number is discontinuous, the audio loss duration is calculated based on the timestamps of adjacent RTP data packets.

[0080] When discontinuous sequence numbers are detected for RTP packets, this indicates that some RTP packets were lost during transmission. To compensate for these lost RTP packets, the duration of audio loss corresponding to these lost RTP packets must be calculated. Specifically, the audio loss duration can be calculated by checking the timestamps of adjacent RTP packets and combining them with the fixed time interval between each RTP packet.

[0081] Step S3220: Generate a compensation data packet that matches the audio loss duration according to the silence data format corresponding to the codec information.

[0082] After calculating the duration of audio loss, the call recording system generates a compensation packet to fill the gap. This compensation packet typically contains silence data, which is encoded and decoded in the same format as the original audio data. For example, if the original audio data is in PCM format, the compensation packet will also contain PCM silence data. The length of the silence data matches the calculated audio loss duration to ensure audio data continuity.

[0083] Step S3230: inserting the compensation data packet into the discontinuous position of the sequence number to fill the lost RTP data packet and obtain the complete call audio.

[0084] The call recording system inserts the generated compensation packets into the discontinuous positions of the sequence numbers to fill in the missing RTP packets. This reassembles the RTP packet sequence into a complete and continuous audio data stream that can be properly decoded and played. This effectively handles RTP packet out-of-order and loss, ensuring the integrity and playability of call recordings.

[0085] Based on the above embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be described in detail later. Figure 3 In the call recording processing method, step S50 includes steps S510 to S520: Step S510: Select a corresponding compression encoding format according to a preset storage requirement.

[0086] Step S520: compress and encode the audio data according to the compression encoding format, and generate the recording file according to a preset file naming rule.

[0087] It's important to note that the raw audio data generated during call recording (such as decoded PCM data) typically takes up a significant amount of storage space, making it difficult to store and transmit. Therefore, to meet diverse application scenarios and needs, the call recording system selects an appropriate compression encoding format based on pre-defined storage requirements. These pre-defined storage requirements include application scenario type, audio quality requirements, default settings, and storage policies.

[0088] For example, in scenarios such as customer service centers, a large number of call recordings need to be stored, so an efficient compression format is needed to save storage space. In this case, the call recording system can use the MP3 format; if the application scenario has high requirements for sound quality, the WAV format can be selected.

[0089] After generating recording files, the call recording system can further improve their management efficiency. Specifically, the call recording system creates an index for each recording file. The index information includes file name, storage path, metadata, and more. This index information allows for quick retrieval of specific recording files during subsequent searches, improving the management efficiency of the call recording system and making it easier for users to quickly access and recall required call recordings.

[0090] In this embodiment, the call recording system can flexibly select compression encoding formats according to different application scenarios and needs, efficiently generate and manage recording files, and ensure that the storage and management of call recordings saves space while meeting audio quality requirements.

[0091] Based on the above embodiments of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail. On this basis, in order to ensure that the call recording system can still operate normally under abnormal circumstances, the present application also designs a fault tolerance mechanism. Specifically: First, to address potential out-of-order or lost RTP packets, the system maintains a buffer sorted by sequence number to sort and reassemble them. When a discontinuous sequence number is detected, the call recording system calculates the duration of the audio loss based on the timestamps of adjacent RTP packets and generates silence packets that match the duration of the audio loss to fill the gaps between the lost RTP packets, thereby ensuring the integrity and continuity of the audio stream. Furthermore, the call recording system sets a preset time period and continuously monitors the reception of RTP packets. If no RTP packets are received within the preset time period, the call recording system assumes the call has ended and terminates the current recording task, preventing incomplete recording files due to RTP packet loss.

[0092] In addition, this application also supports a dual-machine backup recording mechanism to further improve the reliability of the call recording system. The call recording system is configured with a main recording server and a backup recording server. During normal operation, the main recording server is responsible for the recording task, while the backup recording server is on standby. When the main recording server encounters hardware anomalies or software program crashes, the backup recording server will immediately take over all the work of the main recording server and continue to complete the recording task to ensure that the recording file is not lost. Specifically, fault switching can be achieved through real-time monitoring and heartbeat detection mechanisms to ensure that in abnormal circumstances, it can quickly switch to the backup recording server and seamlessly take over the recording task.

[0093] Through the above-mentioned fault-tolerance mechanism, this application can effectively deal with problems such as message disorder, loss, and hardware or software failure, ensuring that the call recording system can still operate normally under various abnormal circumstances and safeguarding the integrity and reliability of call recording.

[0094] An embodiment of the present application provides a call recording processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the call recording processing method in the above-mentioned embodiment 1.

[0095] Reference below Figure 4 , which shows a schematic diagram of the structure of a call recording processing device suitable for implementing the embodiment of the present application. The call recording processing device in the embodiment of the present application may include various hardware and software components for implementing the call recording processing method. Figure 4 The call recording processing device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0096] like Figure 4As shown, the call recording processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the call recording processing device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to I / O interface 1006: input device 1007, such as a touchscreen, touchpad, or keyboard; output device 1008, such as a liquid crystal display (LCD), speaker, or vibrator; storage device 1003, such as a magnetic tape or hard disk; and communication device 1009. The communication device 1009 can allow the call recording processing device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a call recording processing device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0097] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0098] The call recording processing device provided in this application, employing the call recording processing method described in the aforementioned embodiment, can resolve the technical issue of incomplete recordings in high-concurrency scenarios on the ARM platform. Compared to the prior art, the beneficial effects of the call recording processing device provided in this application are the same as those of the call recording processing method described in the aforementioned embodiment. Other technical features of the call recording processing device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0099] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0100] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0101] An embodiment of the present application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the call recording processing method in the above embodiment.

[0102] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0103] The computer-readable storage medium may be included in the call recording processing device; or it may exist independently without being assembled into the call recording processing device.

[0104] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the call recording processing device, the call recording processing device: responds to the recording start instruction, parses the SIP signaling to obtain the IP address and port number of the RTP stream; extracts RTP data packets from the RTP stream according to the IP address and the port number, and records the SSRC and sequence number of each RTP data packet; reassembles the RTP data packets based on the SSRC and the sequence number to obtain complete call audio; decodes the call audio according to the codec information of the RTP stream to obtain audio data; compresses and encodes the audio data to generate a recording file.

[0105] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0107] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0108] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned call recording method. This computer-readable storage medium can address the technical issue of incomplete recordings in high-concurrency scenarios on the ARM platform. Compared to the prior art, the computer-readable storage medium provided in this application offers the same beneficial effects as the call recording method provided in the aforementioned embodiments, and will not be further elaborated here.

[0109] An embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the call recording processing method as described above.

[0110] The computer program product provided in this application can solve the technical problem of incomplete recording in high-concurrency scenarios on the ARM platform. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as those of the call recording processing method provided in the above embodiments, and will not be repeated here.

[0111] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

[0112] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0113] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method.

[0114] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A call recording processing method, characterized in that: The call recording processing method includes: In response to the recording start instruction, parsing the SIP signaling to obtain the IP address and port number of the RTP stream; Extracting RTP packets from the RTP stream according to the IP address and the port number, and recording the SSRC and sequence number of each RTP packet; Reassemble the RTP data packets based on the SSRC and the sequence number to obtain the complete call audio; Decoding the call audio according to the encoding and decoding information of the RTP stream to obtain audio data; The audio data is compressed and encoded to generate a recording file.

2. The call recording processing method according to claim 1, wherein: The step of parsing the SIP signaling to obtain the IP address and port number of the RTP stream in response to the recording start instruction includes: In response to the recording start instruction, obtaining SDP description information in the SIP signaling; Based on the SDP description information, the IP address and port number of the RTP stream are extracted.

3. The call recording processing method according to claim 2, wherein: Before the step of obtaining the SDP description information in the SIP signaling in response to the recording start instruction, the call recording processing method further includes: Parsing the SIP signaling to obtain session identification information of the SIP signaling, wherein the session identification information includes a calling number, a called number, a call identification, and a device type; According to the session identification information, the corresponding recording task is started.

4. The call recording processing method according to claim 3, wherein: After the step of starting the corresponding recording task according to the session identification information, the call recording processing method further includes: If a BYE packet of the SIP signaling is detected, or if no RTP data packet is obtained within a preset time period, the current recording task is terminated.

5. The call recording processing method according to claim 1, wherein: The step of reassembling the RTP data packet based on the SSRC and the sequence number to obtain the complete call audio includes: Determine the RTP data packet corresponding to the RTP stream according to the SSRC; The RTP data packets are sorted according to the sequence numbers, and the RTP data packets are reassembled according to the sorting results to obtain the complete call audio.

6. The call recording processing method according to claim 5, wherein: The step of sorting the RTP data packets according to the sequence numbers and reassembling the RTP data packets according to the sorting results to obtain the complete call audio includes: When it is detected that the sequence numbers are discontinuous, calculating the audio loss duration based on the timestamps of adjacent RTP data packets; generating, according to the silence data format corresponding to the codec information, a compensation data packet matching the duration of the audio loss; The compensation data packet is inserted into the discontinuous position of the sequence number to fill the lost RTP data packet and obtain the complete call audio.

7. The call recording processing method according to claim 1, wherein: The step of compressing and encoding the audio data to generate a recording file comprises: Select the corresponding compression encoding format according to the preset storage requirements; The audio data is compressed and encoded according to the compression encoding format, and the recording file is generated according to a preset file naming rule.

8. The call recording processing method according to claim 1, wherein: Before the step of extracting RTP data packets from the RTP stream according to the IP address and the port number, and recording the SSRC and sequence number of each RTP data packet, the call recording processing method includes: Extracting the RTP data packet from the RTP stream according to the IP address and the port number; The RTP data packet is stored in a buffer to prevent the RTP data packet from being lost.

9. A call recording processing device, characterized in that: The call recording processing device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the call recording processing method according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the call recording processing method according to any one of claims 1 to 8 are implemented.

Images