Method for determining inconsistent call data of a main called party and electronic device

Abstract

The application discloses a kind of main called inconsistent ticket determination method and electronic equipment, belong to business operation support system field.Therein, the method includes: determining that the first to-be-processed ticket and the ticket in the duplicate record table do not match, wherein the duplicate record table is used to record the processed ticket;By exchanging the field attribute value of the main terminal number and the opposite terminal number of the first to-be-processed ticket, a first target ticket is obtained, wherein the call type value of the first target ticket is different from the call type value of the first to-be-processed ticket, and the call type value includes: calling or being called;The first target ticket is compared with each ticket in the duplicate record table;In the case where the first target ticket and each ticket in the duplicate record table do not match, the first to-be-processed ticket is determined as a main called inconsistent ticket.

Description

Technical Field

[0001] This application belongs to the field of business operation support systems, and specifically relates to a method and electronic equipment for determining inconsistent call detail records (CDRs) between the calling and called parties. Background Technology

[0002] Voice service is one of the fundamental services of mobile communication. Due to the networking characteristics of voice services and some deficiencies of network elements in voice connection, the billing system, under the requirement of high timeliness in billing, cannot wait for both ends' call detail records (CDRs) to arrive before outputting the bill. In other words, the billing system cannot identify whether the CDRs of the calling and called parties are consistent during the billing process.

[0003] To identify inconsistencies in call detail records (CDRs) between the calling and called parties, the relevant technology requires comparing a massive amount of billed call detail records output by the billing system during the same time period to find those that do not match, ultimately determining the truly inconsistent CDRs. Therefore, this process consumes significant database server computing power and additional database storage resources, resulting in high resource consumption and poor timeliness. Summary of the Invention

[0004] The purpose of this application is to provide a method and electronic device for determining inconsistent call detail records (CDRs) between the calling and called parties, which can solve the problems of high resource consumption and poor timeliness in the process of determining inconsistent CDRs between the calling and called parties.

[0005] In a first aspect, embodiments of this application provide a method for determining inconsistent call detail records (CDRs), comprising: determining that a first CDR to be processed does not match a CDR in a deduplication record table, wherein the deduplication record table is used to record processed CDRs; obtaining a first target CDR by exchanging the field attribute values ​​of the originating number and the deduplicating number of the first CDR to be processed, wherein the call type value of the first target CDR is different from the call type value of the first CDR to be processed, and the call type value includes: calling or called; comparing the first target CDR with each CDR in the deduplication record table; and determining that the first CDR to be processed is an inconsistent call detail record when the first target CDR does not match any of the CDRs in the deduplication record table.

[0006] Secondly, embodiments of this application provide a device for determining inconsistent call detail records (CDRs), comprising: a first determining module for determining that a first CDR to be processed does not match a CDR in a deduplication record table, wherein the deduplication record table is used to record processed CDRs; an interchange module for obtaining a first target CDR by interchangering the field attribute values ​​of the calling end number and the calling end number of the first CDR to be processed, wherein the call type value of the first target CDR is different from the call type value of the first CDR to be processed, and the call type value includes: calling or called; a comparison module for comparing the first target CDR with each CDR in the deduplication record table; and a second determining module for determining that the first CDR to be processed is an inconsistent call detail record when the first target CDR does not match any of the CDRs in the deduplication record table.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] In this embodiment, a mismatch is determined between the first pending call detail record (CDR) and the CDR in the deduplication record table, where the deduplication record table records processed CDRs. Then, a first target CDR is obtained by swapping the field attribute values ​​of the primary and secondary numbers of the first pending CDR. The call type value of the first target CDR differs from that of the first pending CDR, and the call type value includes either "calling" or "called." The first target CDR is then compared with each CDR in the deduplication record table. If the first target CDR does not match any of the CDRs in the deduplication record table, the first pending CDR is determined to be a non-consistent calling / called CDR, thereby improving the utilization rate and timeliness of computing resources when determining non-consistent calling / called CDRs. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) between the calling and called parties.

[0011] Figure 2 This is a flowchart illustrating a billing deduplication method;

[0012] Figure 3 This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) provided in one embodiment of this application.

[0013] Figure 4 This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) provided in another embodiment of this application.

[0014] Figure 5 This is a schematic diagram of the structure of a device for determining inconsistent call detail records (CDRs) provided in one embodiment of this application;

[0015] Figure 6 This is a schematic diagram of an electronic device provided in another embodiment of this application;

[0016] Figure 7 This is a schematic diagram of the hardware structure of an electronic device that implements an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] The method for determining inconsistent call detail records (CDRs) provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0020] Due to the networking characteristics of voice services and some deficiencies in network elements regarding voice connection, billing receipts may only be issued unilaterally by the calling or called end during voice communication. When the calling and called ends communicate, their connections may not be in the same network element in the same region. Therefore, the user service usage records (billing call detail records) for both the calling and called ends must be generated independently by their respective network elements. If one network element fails to generate a qualified billing call detail record due to certain factors, and there is a time difference between the arrival of the call detail records from both ends to the billing system, coupled with the high timeliness requirements of the billing system, the billing system cannot wait for both call detail records to arrive before uniformly outputting the bill. Therefore, it cannot identify whether the call detail records of the calling and called ends are consistent during the billing process.

[0021] Figure 1 This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) between the calling and called parties, such as... Figure 1 As shown, to identify inconsistencies in call detail records (CDRs) between the calling and called parties, it is necessary to compare a massive number of billed call detail records output by the billing system within the same time period to find any unmatched records. After applying filtering rules to filter out call scenarios that would only have one-sided CDRs, such as those with other networks, other provinces, or landlines, the truly inconsistent call records are finally identified and submitted to the network department for verification to correct network element errors and prevent similar situations from recurring. This method of determining inconsistent call detail records has the following shortcomings:

[0022] I. Resource Consumption. Utilizing a large commercial database system to extract and fully compare user billing call detail records that have been processed and stored in the database to identify billing call detail records with discrepancies between the calling and called parties requires a significant amount of computing power from the database host and additional database storage resources.

[0023] Second, poor timeliness. This method requires a full comparison of all voice billing call detail records in the later stages. Voice billing call detail records are typically massive, and even with a partitioned database stored on a daily basis, the comparison volume remains enormous. For example, a company might have around 2 billion voice billing call detail records per day, and completing a single daily data comparison would take over 10 hours. This means that the audit results for inconsistencies between the calling and called parties from the previous day wouldn't be available until the afternoon of the following day. This results in a very long comparison time, hindering the timely detection of problems.

[0024] The above-mentioned method for determining (or auditing) inconsistencies between the calling and called parties in voice billing call detail records is a post-processing method. It performs post-processing on the voice billing call detail records output to the database after billing processing to achieve the auditing purpose.

[0025] This application provides a method for determining inconsistent call detail records (CDRs) between the calling and called parties. Figure 3This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) provided in one embodiment of this application. This embodiment utilizes billing deduplication (e.g., ...). Figure 2 As shown, Figure 2 This is a schematic diagram of a billing deduplication method. The related technologies are relatively conventional and not the focus of this application; therefore, they will not be elaborated upon here to avoid repetition. (This method requires call detail record (CDR) comparison. A reverse comparison process is added so that the billing system determines the inconsistencies in the calling and called party CDRs only after completing the CDR deduplication process.) Figure 3 As shown, it includes the following steps:

[0026] S310: Determine that the first pending call detail record (CDR) does not match the CDR in the deduplication record table, wherein the deduplication record table is used to record processed CDRs.

[0027] After deduplication, call details records (CDRs) are stored in an in-memory database, forming a deduplication record table. When a new CDR is received, its key deduplication fields are compared with those of other CDRs in the deduplication record table to determine if the new CDR already exists in the table. If the new CDR is found in the deduplication record table, it is considered a duplicate and is saved as a duplicate record. If the new CDR is not found in the deduplication record table (meaning it does not match any of the CDRs in the table), it becomes the first CDR to be processed. Subsequent checks to determine if related CDRs are inconsistent between the calling and called parties involve checking this first CDR to be processed.

[0028] In one possible implementation, after determining that the first pending call detail record (CDR) does not match any of the CDRs in the deduplication record table, the first pending CDR is recorded in the deduplication record table. In this implementation, after determining that the first pending CDR does not match any of the CDRs in the deduplication record table, a subsequent process can be performed to determine whether the first pending CDR is a caller-called inconsistency. At this time, there are two processing methods: one is to directly determine whether the first pending CDR is a caller-called inconsistency, or the other is to first record the first pending CDR obtained above in the deduplication record table, and then perform the determination whether the first pending CDR is a caller-called inconsistency.

[0029] S320: A first target call detail record (CDR) is obtained by swapping the field attribute values ​​of the primary end number and the secondary end number of the first CDR to be processed. The call type value of the first target CDR is different from the call type value of the first CDR to be processed. The call type value includes: calling or called.

[0030] In one possible implementation, the first pending call detail record (CDR) is transformed into a first target CDR by performing the following processing: first, the field attribute values ​​of the originating and destination numbers of the first pending CDR are swapped; second, the call type value of the first pending CDR is changed, where the call type value includes either calling or called. For illustrative purposes, assume a first pending CDR is as follows:

[0031] 139xxxx1414 139xxxx3503 Caller 2021.8.27 09:12:10 85

[0032] Therefore, by swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record to be processed and changing the call type value, the first target call detail record obtained is:

[0033] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:10 85

[0034] For example, suppose the first pending call detail record is:

[0035] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:22 88

[0036] Therefore, by swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record to be processed and changing the call type value, the first target call detail record obtained is:

[0037] 139xxxx1414 139xxxx3503 Caller 2021.8.27 09:12:22 88

[0038] Of course, the above example of a specific call detail record (CDR) to be processed and its transformed target CDR is only used to illustrate how to swap the field attribute values ​​of the master number and the peer number, how to change the call type value, and to visually demonstrate the result of transforming the first CDR to be processed into the first target CDR. Those skilled in the art should understand that this example does not impose any limitations on this embodiment.

[0039] S330: Compare the first target call detail record (CDR) with each CDR in the deduplication record table.

[0040] In one possible implementation, the first target call detail record (CDR) is compared with every CDR in the deduplication record table to determine whether the first target CDR matches any of the CDRs in the deduplication record table. Illustratively, assume the deduplication record table contains N CDRs (N is a positive integer). As the deduplication record table is formed as described above, these N CDRs are distinct. Therefore, comparing the first target CDR with these N CDRs in the deduplication record table will have two possible results: one is that the first target CDR does not match any of the N CDRs, and the other is that the first target CDR matches one of the N CDRs.

[0041] Whether two call detail records (CDRs) match (e.g., a first target CDR and a CDR in the deduplication table) depends on the corresponding matching rules. For example, a matching rule might be: if the originating number, the peer number, the call type, the start time, and the duration are all the same, then the two CDRs match; if any one of these matching conditions is not met, then the two CDRs do not match. For instance, if the originating number of the first target CDR is different from that of a CDR in the deduplication table, then the first target CDR does not match this CDR; if the start time of the first target CDR is different from that of a CDR in the deduplication table, then the first target CDR does not match this CDR; if the peer number and the call type value of the first target CDR are both different from those of a CDR in the deduplication table, then the first target CDR does not match this CDR; if the originating number, peer number, call type, start time, and duration of the first target CDR are all the same as those of a CDR in the deduplication table, then the first target CDR matches this CDR, and so on.

[0042] S340: If the first target call detail record (CDR) does not match any of the CDRs in the deduplication record table, the first CDR to be processed is determined to be a call detail record where the caller and the called party are inconsistent.

[0043] In one possible implementation, if the first target call detail record (CDR) does not match any of the CDRs in the deduplication record table, then the original first pending CDR corresponding to the first target CDR can be determined to be a caller-called inconsistency CDR. In step S310, before determining whether the first pending CDR is a caller-called inconsistency CDR, this embodiment can have two processing methods: one is to directly determine whether the first pending CDR is a caller-called inconsistency CDR; the other is to first record the first pending CDR obtained above in the deduplication record table and then perform the caller-called inconsistency CDR determination. In the former case, the first pending CDR has already been recorded in the deduplication record table, so no additional processing is needed for the first pending CDR; for the latter case, if the first target CDR does not match any of the CDRs in the deduplication record table, after determining that the first pending CDR is a caller-called inconsistency CDR, the first pending CDR (already determined to be a caller-called inconsistency CDR) can be recorded in the deduplication record table.

[0044] In one possible implementation, the structure of the deduplication record table may include a flag field. The value of the flag field includes a first value or a second value, wherein the first value is used to indicate inconsistent call detail records (CDRs) between the calling and called parties, and the second value is used to indicate non-inconsistent CDRs between the calling and called parties. When the first pending CDR is determined to be an inconsistent CDR between the calling and called parties, it is marked with the first value; when the first pending CDR is determined to be a non-inconsistent CDR between the calling and called parties, it is marked with the second value. Illustratively, "1" indicates that no matching record has been found for the other party's CDR, and the first value is marked as "1"; "2" indicates that a matching record has been found for the other party's CDR, and the second value is marked as "2". Of course, using "1" and "2" to represent the first and second values ​​is only for illustrating this implementation and is not intended to limit this implementation in any way.

[0045] In one possible implementation, if a network element fails to generate a qualified billing call detail record (CDR) due to certain factors, or if there is a time difference between the CDRs arriving at the billing system from both the calling and called parties, then the first pending CDR marked as a calling-called inconsistent CDR will have two possible scenarios. One scenario is that the CDR from the other end of the first pending CDR also arrives at the billing system or is in the deduplication record table. In this case, the first pending CDR is determined to be a calling-called inconsistent CDR (i.e., the first pending CDR is determined to be a genuine calling-called inconsistent CDR). The other scenario is that the CDR from the other end of the first pending CDR does not arrive at the billing system or is in the deduplication record table when the calling-called inconsistent CDR is being judged from the first pending CDR. In this case, the determination that the first pending CDR is a calling-called inconsistent CDR may be a misjudgment (i.e., the first pending CDR itself is not a calling-called inconsistent CDR, but is judged as a calling-called inconsistent CDR for other reasons). To reduce misjudgments of the first pending call detail record (CDR) and improve the accuracy of determining inconsistent call detail records, this embodiment, after determining that the first pending CDR is inconsistent with the called party, may further include:

[0046] When the first target call detail record (CDR) (i.e., the target CDR after transformation of the second CDR that needs to be judged as having inconsistency between the calling and receiving parties) matches the second CDR to be processed in the deduplication record table (i.e., the CDR to be processed after the inconsistency judgment in the aforementioned steps), if the second CDR to be processed is marked as having inconsistency between the calling and receiving parties, then the second CDR to be processed is marked as a non-inconsistent CDR. At this time, the first CDR to be processed marked as having inconsistency between the calling and receiving parties (or the second CDR to be processed in the subsequent judgment process) is the finally determined inconsistent CDR, reducing the possibility of it being misjudged as having inconsistency between the calling and receiving parties and improving the accuracy of judging whether the CDR to be processed is having inconsistency between the calling and receiving parties.

[0047] For illustrative purposes, suppose the first pending call detail record is:

[0048] 139xxxx1414 139xxxx3503 Caller 2021.8.27 09:12:10 85

[0049] Therefore, by swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record to be processed and changing the call type value, the first target call detail record obtained is:

[0050] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:10 85

[0051] The first target call detail record (CDR) is compared with each CDR in the deduplication record table. If no matching CDR is found, this first pending CDR (main caller number: 139xxxx1414) is marked as a caller-called mismatch CDR. In the second case, since the counterparty CDR of the first pending CDR has not yet reached the billing system, the determination of the first pending CDR as a caller-called mismatch CDR may be a misjudgment. When another first pending CDR reaches the billing system or the deduplication record table, let's assume the current first pending CDR is:

[0052] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:10 85

[0053] Therefore, by swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record to be processed and changing the call type value, the first target call detail record is obtained as follows:

[0054] 139xxxx1414 139xxxx3503 Caller 2021.8.27 09:12:10 85

[0055] At this point, the first target call detail record (CDR) is compared with each CDR in the deduplication record table. The matching result is as follows: if the first target CDR matches the second pending CDR (originally the first pending CDR) in the deduplication record table, and the second pending CDR is marked as a caller-called inconsistency CDR, then the second pending CDR is marked as a non-caller-called inconsistency CDR.

[0056] This application discloses a method for determining inconsistent call detail records (CDRs). The method involves determining that a first CDR to be processed does not match a CDR in a deduplication record table, where the deduplication record table records processed CDRs. A first target CDR is obtained by swapping the field attribute values ​​of the calling and receiving numbers in the first CDR to be processed. The call type value of the first target CDR differs from that of the first CDR to be processed, and the call type value includes either calling or receiving. The first target CDR is then compared with each CDR in the deduplication record table. If the first target CDR does not match any of the CDRs in the deduplication record table, the first CDR to be processed is determined to be an inconsistent call detail record. This method effectively improves the resource utilization of the billing system and enhances the timeliness of inconsistent call detail record judgment, achieving near-synchronous output of the inconsistent judgment result and the CDR output, enabling maintenance personnel to promptly obtain the determination result of the inconsistent call detail record. The determination method in this embodiment solves the problem that the inconsistency judgment (or audit) of the calling party and the called party requires a lot of additional system resources. It incorporates the inconsistency judgment process of the calling party and the called party into the overall billing process. By utilizing the similarity of the processing logic of the billing deduplication link, the inconsistency judgment of the calling party and the called party is broken down into parts, and a solution is achieved within the existing system resource framework without the need to add new resources.

[0057] Another embodiment of this application provides a method for determining inconsistent call detail records (CDRs) between the calling and called parties. Figure 4 This is a flowchart illustrating a method for determining inconsistent call detail records (CDRs) provided in another embodiment of this application, as shown below. Figure 4 As shown, it includes the following steps:

[0058] S410: Compare the newly arrived call detail record (CDR) with each CDR in the deduplication record table formed by processed CDRs in the in-memory database, focusing on key deduplication fields; S420: Determine if a CDR matches the newly arrived CDR in the deduplication record table; S430: If it exists, determine that the newly arrived CDR is a duplicate, and output it as a duplicate record in text format; S440: If it does not exist, write this newly arrived CDR (i.e., the first CDR to be processed for subsequent caller-called inconsistency judgment) into the deduplication record table in the in-memory database. Various conventional methods can implement the above deduplication process, and to avoid duplication, they will not be elaborated upon here.

[0059] S450: In the newly received call detail record (CDR), the calling number and the peer number fields are swapped, and the call type value changes from calling to called and from called to calling.

[0060] In one possible implementation, taking the first pending call detail record (CDR) recorded in the deduplication record table as an example, the first target CDR is obtained by exchanging the field attribute values ​​of the originating number and the peer number of the first pending CDR. The call type value of the first target CDR differs from the call type value of the first pending CDR, and the call type value includes either "caller" or "called party". Further implementations of this embodiment can be found in the detailed description of the method for determining inconsistent call detail records provided in the above embodiments of this application. Those skilled in the art should be able to understand the corresponding implementations, and to avoid repetition, they will not be elaborated upon here.

[0061] S460: The swapped new call detail record (i.e., the first target call detail record) is compared again with each call detail record in the deduplication record table in the memory control (the calling and called party inconsistency exclusion rules are loaded during the comparison).

[0062] In one possible implementation, the first target call detail record (CDR) is compared with every CDR in the deduplication record table to determine whether the first target CDR matches any CDR in the deduplication record table. Further implementations of this embodiment can be found in the detailed description of the method for determining inconsistent call detail records provided in the above embodiments of this application. Those skilled in the art should be able to understand the corresponding implementations, and to avoid repetition, they will not be described again here.

[0063] In one possible implementation, before obtaining the first target call detail record by swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record to be processed, or after comparing the first target call detail record with each call detail record in the deduplication record table, the determination method in this implementation may further include: determining that the secondary number of the first call detail record to be processed does not belong to a preset number, wherein the preset number includes at least one of the following: a landline phone number, a mobile number from another network operator, a mobile number from a different province, or a VoIP phone number.

[0064] ① When the other end number is a landline: The landline parameter in the parameters is used for identification. Call detail records (CDRs) for this type of other end will be generated in the network element of the telecom operator to which the landline belongs. ② When the other end number is a mobile number from another network operator: The number segment data in the parameters is used for identification. CDRs for this type of other end will be generated in the network element of the telecom operator to which the mobile number belongs. ③ When the other end number is a mobile number from outside the province: The number segment data in the parameters is used for identification. CDRs for this type of other end will be generated in the network element of the province to which the number segment belongs. ④ When the other end number is an IP (Internet Protocol) phone: The IP header is used for identification. Due to the IP communication mechanism, CDRs for this type of other end may not be generated.

[0065] Taking a landline number as an example where the peer number of the first pending call detail record (CDR) is a landline, due to the special nature of this type of peer number, the determination method shown in the embodiments of this application would classify this type of CDR as a caller-called inconsistency record. Obviously, this conclusion does not reflect reality (in this case, the first pending CDR is not a caller-called inconsistency record). Therefore, it is necessary to exclude the first pending CDR that is classified as a caller-called inconsistency record under such special or reasonable circumstances. Similarly, for reasonable cases where the peer number is a mobile number from another network operator, a mobile number from a different province, or a VoIP number, it is also necessary to exclude caller-called inconsistencies caused by these reasonable circumstances.

[0066] In one possible implementation, comparing the first target call detail record (CDR) with each CDR in the deduplication record table may further include: comparing the first target CDR with a second pending CDR in the deduplication record table; if the difference between the first target CDR and the second pending CDR is within an allowable range, determining that the first target CDR and the second pending CDR match. In this implementation, a certain redundancy can be set for whether two CDRs match (or are identical), and they do not necessarily need to be completely identical. For illustrative purposes, suppose the first pending CDR is:

[0067] 139xxxx1414 139xxxx3503 Caller 2021.8.27 09:12:10 85

[0068] At this point, if the peer call detail record (CDR) of the first pending call detail record is:

[0069] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:22 88

[0070] It can be seen that although the first pending call detail record (CDR) has a corresponding peer call detail record (PDR) and is not a call detail record with inconsistent calling and called parties, the relevant parameters of the first pending CDR and its corresponding peer call detail record may not be completely the same due to metering system errors or other reasons (in this example, the start time and duration are different).

[0071] By swapping the field attribute values ​​of the primary and secondary numbers of the first call detail record (CDR) to be processed and changing the call type value, the first target CDR is obtained as follows:

[0072] 139xxxx3503 139xxxx1414 Called 2021.8.27 09:12:10 85

[0073] At this point, when comparing the first target call detail record (CDR) with the peer CDR of the first pending CDR, they differ in start time and duration. Therefore, the first pending CDR is identified as a caller-called mismatch. However, the first pending CDR is not actually a caller-called mismatch; this difference is due to system errors or metering errors. Therefore, to eliminate this reasonable error and avoid misjudgment, a certain degree of redundancy can be set in the comparison rules. Generally, the difference in the start time and duration fields is set to within 30 seconds. According to the relevant testing standards of the Ministry of Industry and Information Technology, since the CDRs of the calling and called ends may be located in different network elements depending on the call scenario, considering the differences in network element clocks and call connection reasons, a difference of ±30 seconds in the start time and duration of the calling and called CDRs is allowed. That is, if the difference in the start time and duration field values ​​between the compared CDR and the compared CDR is within ±30 seconds, it is judged as a correct match.

[0074] S470: Can the corresponding record be found in the deduplication record table for the first target call detail record?

[0075] If the first target call detail record (CDR) does not match any of the CDRs in the deduplication record table, it means that the corresponding CDR record could not be found in the deduplication record table. If the first target CDR matches one of the CDRs in the deduplication record table, it means that the corresponding CDR record could be found in the deduplication record table.

[0076] S480: In the memory database, set the "Calling Audit" field to "2" in the original "Calling Audit" field of the corresponding call detail record (CDR record before the "Calling" and "Called" fields were swapped) before the swap. In this embodiment, records with "1" in the "Calling Audit" field can also be output daily in text format. Of course, in this embodiment, the deduplication record table structure in the memory database needs to be modified first, adding a "Calling Audit" flag field. This field uses a fixed enumeration value to identify the calling audit result. The flag field can be set to: "1" indicating that no matching CDR record has been found on the other end, and "2" indicating that a matching CDR record has been found on the other end. For a more detailed description of this embodiment, please refer to the relevant implementations of the first and second values ​​in step S340 of the above embodiments. To avoid repetition, they will not be repeated here.

[0077] S490: Set the calling and called audit fields of the original call detail record (CDR) before the swap of the calling and called fields in the memory database to "1". If the first target CDR does not match any of the CDRs in the deduplication record table, it means that the corresponding CDR record could not be found in the deduplication record table. In this case, the first CDR to be processed is a calling and called inconsistency CDR, and the calling and called audit fields are set to "1". In this embodiment, records with a calling and called audit field value of "1" in the deduplication table of the memory database can also be output at fixed time points for subsequent database entry and display.

[0078] The determination method disclosed in this application can effectively improve the resource utilization of the billing system and enhance the timeliness of call detail record (CDR) inconsistency judgment, achieving near-synchronous output of the CDR judgment result and the CDR output, enabling maintenance personnel to promptly obtain the determination result of the inconsistency. This method solves the problem that CDR inconsistency judgment (or auditing) requires a large amount of additional system resources. It integrates the CDR inconsistency judgment process into the overall billing process, utilizing the similarity of the billing deduplication logic to break down the CDR inconsistency judgment into smaller steps, achieving a solution within the existing system resource framework without requiring additional resources.

[0079] Meanwhile, the verification method provided by the embodiments described in this application was verified in a specific application scenario. From April to July 2021, in the test environment of a mobile billing system, the prototype system developed according to the verification method of this application underwent three months of trial operation and stress testing. This proved that when the inbound call volume accumulated for more than one day but less than six days (approximately 5.87 million inbound files and approximately 12.5 billion call detail records), the system could complete the processing of all accumulated call detail records within 12 hours during the deduplication process. Subsequent comparison and verification showed that the output call detail record consistency comparison results were accurate, and the efficiency of the deduplication process only decreased slightly, without affecting the overall billing system processing efficiency. Later analysis showed that the output inconsistent call detail record locations were accurate, enabling timely assistance to system maintenance personnel in identifying call detail record problems.

[0080] Another embodiment of this application provides a device for determining inconsistent call detail records (CDRs), such as... Figure 5 As shown, Figure 5 This is a schematic diagram of a device for determining inconsistent call detail records (CDRs) provided in another embodiment of this application. The device may include a first determining module 510, an exchange module 520, a comparison module 530, and a second determining module 540.

[0081] First determining module 510: used to determine that the first call detail record to be processed does not match the call detail record in the deduplication record table, wherein the deduplication record table is used to record processed call detail records.

[0082] In one possible implementation, when a pending call detail record (CDR) is received where it is uncertain whether the calling and called parties are consistent, the system determines whether the first pending CDR already exists in the deduplication record table by comparing the key deduplication fields of each CDR in the deduplication record table with those of the first pending CDR. Further implementations of the first determining module 510 can be found in the detailed description of the embodiment provided in this application, "A Method for Determining Inconsistent Call Detail Records Between Calling Parties," where those skilled in the art should understand the corresponding implementations. To avoid repetition, further details are omitted here.

[0083] The swapping module 520 is used to obtain a first target call detail record (CDR) by swapping the field attribute values ​​of the primary and secondary numbers of the first CDR to be processed. The call type value of the first target CDR differs from the call type value of the first CDR to be processed, and the call type value includes either "calling party" or "called party". The implementation of the swapping module 520 can be found in the detailed description of the method for determining inconsistencies between calling and called CDRs provided in this application. Those skilled in the art should understand the corresponding implementation methods, and to avoid repetition, they will not be described again here.

[0084] The comparison module 530 is used to compare the first target call detail record (CDR) with each CDR in the deduplication record table. The comparison module may include a correction module (not shown in the figure), which is used to mark the second CDR as a non-inconsistent call detail record if, when the first target CDR matches a second CDR in the deduplication record table, the second CDR is identified as an inconsistent call detail record. Further implementations of the comparison module 530 and the correction module can be found in the detailed description of the method for determining inconsistent call detail records provided in this application. Those skilled in the art should understand the corresponding implementations, and to avoid repetition, they will not be described again here.

[0085] The second determining module 540 is used to determine that the first call detail record (CDR) to be processed is an inconsistent call detail record between the calling and called parties when the first target CDR does not match any of the CDRs in the deduplication record table. Further implementations of the second determining module 540 can be found in the detailed description of the method for determining inconsistent calling and called party CDRs provided in this application. Those skilled in the art should be able to understand the corresponding implementations, and to avoid repetition, they will not be described again here.

[0086] In one possible implementation, the determining device may further include a call detail record (CDR) exclusion module (not shown in the figure), which is used to determine that the peer number of the first CDR to be processed does not belong to a preset number, wherein the preset number includes at least one of the following: a landline number, a mobile number from another network operator, a mobile number from a different province, or a VoIP number. Further implementations of the CDR exclusion module can be found in the detailed description of the embodiment provided in this application, "A Method for Determining Inconsistent Call Detail Records," and those skilled in the art should be able to understand the corresponding implementations. To avoid repetition, further details are omitted here.

[0087] In one possible implementation, the determining device may further include a tolerance module (not shown in the figure), which is used to compare the first target call detail record (CDR) with the second CDR to be processed in the deduplication record table. If the difference between the first target CDR and the second CDR to be processed is within an allowable range, the first target CDR and the second CDR to be processed are determined to match. Further implementations of the tolerance module can be found in the detailed description of the method for determining inconsistencies between calling and called CDRs provided in this application. Those skilled in the art should be able to understand the corresponding implementations, and to avoid repetition, they will not be described again here.

[0088] This application discloses a device for determining the consistency of call detail records (CDRs). The device determines that a first CDR to be processed does not match a CDR in a deduplication record table, where the deduplication record table records processed CDRs. It then obtains a first target CDR by swapping the field attribute values ​​of the calling and receiving numbers in the first CDR to be processed. The call type value of the first target CDR differs from that of the first CDR to be processed, and the call type value includes either calling or receiving. The first target CDR is then compared with each CDR in the deduplication record table. If the first target CDR does not match any of the CDRs in the deduplication record table, the device determines that the first CDR to be processed is an inconsistent call detail record. This device effectively improves the resource utilization of the billing system and enhances the timeliness of determining inconsistent call detail records, achieving near-synchronous output of the inconsistency determination result and the CDR output, enabling maintenance personnel to promptly obtain the determination result of the inconsistency. The determination device in this embodiment solves the problem that the inconsistency judgment (or audit) of the calling party and the called party requires a lot of additional system resources. It incorporates the inconsistency judgment process of the calling party and the called party into the overall billing process. By utilizing the similarity of the processing logic of the billing deduplication link, the inconsistency judgment of the calling party and the called party is broken down into parts, and a solution is achieved within the existing system resource framework without the need to add new resources.

[0089] The identification device provided in this embodiment can also be a component in an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0090] The device for determining inconsistencies between the calling and called party call detail records in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0091] The apparatus provided in this application embodiment can achieve... Figure 3 or Figure 4 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0092] Optionally, such as Figure 6 As shown in the figure, this application embodiment also provides an electronic device 600, including a processor 601 and a memory 602. The memory 602 stores a program or instructions that can run on the processor 601. When the program or instructions are executed by the processor 601, they implement the above-mentioned... Figure 3 or Figure 4 The steps of the method embodiments described herein can achieve the same technical effect, and will not be repeated here to avoid repetition.

[0093] Optionally, embodiments of this application also provide a storage medium, including a processor 601 and a memory 602. The memory 602 stores a program or instructions that can run on the processor 601, and when the program or instructions are executed by the processor 601, they implement the above-mentioned... Figure 3 or Figure 4 The steps of the method embodiments described herein can achieve the same technical effect, and will not be repeated here to avoid repetition.

[0094] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0095] Figure 7 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0096] The electronic device 700 includes, but is not limited to, components such as: radio frequency unit 701, network module 702, audio output unit 703, input unit 704, sensor 705, display unit 706, user input unit 707, interface unit 708, memory 709, and processor 710.

[0097] Those skilled in the art will understand that the electronic device 700 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 710 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0098] The processor 710 is used to perform the corresponding functions in the method for determining inconsistent call detail records of the calling and called parties in this application.

[0099] It should be understood that, in this embodiment, the input unit 704 may include a graphics processing unit (GPU) 7041 and a microphone 7042. The GPU 7041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 706 may include a display panel 7061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 707 includes at least one of a touch panel 7071 and other input devices 7072. The touch panel 7071 is also called a touch screen. The touch panel 7071 may include a touch detection device and a touch controller. Other input devices 7072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0100] The memory 709 can be used to store software programs and various data. The memory 709 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.), etc. The second storage area may store databases for identifying fraudulent numbers, such as a fraudulent number database, an identity information database, a device information database, a call detail record database, and a rule database. Furthermore, the memory 709 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 709 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0101] Processor 710 may include one or more processing units; optionally, processor 710 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 710.

[0102] It should be noted that, in this document, 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 that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0104] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for determining inconsistent call detail records (CDRs), characterized in that, include: It is determined that the first pending call detail record (CDR) does not match the CDR in the deduplication record table, wherein the deduplication record table is used to record processed CDRs; By swapping the field attribute values ​​of the primary end number and the secondary end number of the first call detail record to be processed, a first target call detail record corresponding to the first call detail record to be processed is obtained. The call type value of the first target call detail record is different from the call type value of the first call detail record to be processed. The call type value includes: calling or called. The first target call detail record (CDR) is compared with each CDR in the deduplication record table. If the first target call detail record (CDR) does not match any of the CDRs in the deduplication record table, the first CDR to be processed is determined to be a call detail record where the caller and the called party are inconsistent. Specifically, after determining that the first call detail record (CDR) to be processed does not match the CDR in the deduplication record table, the first CDR to be processed is recorded in the deduplication record table. If the first target CDR does not match any of the CDRs in the deduplication record table, the first CDR to be processed in the deduplication record table is marked as a caller-called inconsistency CDR; or, after determining that the first CDR to be processed is a caller-called inconsistency CDR, the first CDR to be processed is marked as a caller-called inconsistency CDR, and the marked first CDR to be processed is recorded in the deduplication record table. The method further includes: If the third target call detail record (CDR) corresponding to the third call detail record (CDR) to be processed matches the first call detail record (CDR) to be processed in the deduplication record table, the first call detail record (CDR) to be processed in the deduplication record table will be corrected and marked as a non-caller-called inconsistent CDR. The first pending call detail record (CDR) and the third pending CDR are two CDRs received sequentially, with the third pending CDR being received later than the first pending CDR.

2. The method for determining inconsistent call detail records (CDRs) according to claim 1, characterized in that, The method further includes: If the first target call detail record (CDR) matches the second CDR to be processed in the deduplication record table, and the second CDR to be processed is identified as a caller-called inconsistency CDR, then the second CDR to be processed is marked as a non-caller-called inconsistency CDR; wherein the second CDR to be processed and the first CDR to be processed are two CDRs received sequentially, and the reception time of the second CDR to be processed is earlier than that of the first CDR to be processed.

3. The method for determining inconsistent call detail records (CDRs) according to claim 1, characterized in that, The deduplication record table includes a flag field, and the flag field can take either a first value or a second value. The first value indicates inconsistent call detail records (CDRs) between the calling and called parties, and the second value indicates inconsistencies between non-calling and non-called parties.

4. The method for determining inconsistent call detail records (CDRs) according to claim 1, characterized in that, Before obtaining the first target call detail record (CDR) by swapping the field attribute values ​​of the primary and secondary numbers of the first CDR to be processed, or after comparing the first target CDR with each CDR in the deduplication record table, the process includes: It is determined that the peer number of the first call detail record to be processed does not belong to a preset number, wherein the preset number includes at least one of the following: landline number, mobile number of other network operators, mobile number of different provinces, and VoIP number.

5. The method for determining inconsistent call detail records (CDRs) according to claim 1, characterized in that, The first target call detail record (CDR) is compared with each CDR in the deduplication record table, including: comparing the first target CDR with the second pending CDR in the deduplication record table; if the difference between the first target CDR and the second pending CDR is within an allowable range, the first target CDR and the second pending CDR are determined to be a match; wherein the second pending CDR and the first pending CDR are two CDRs received sequentially, and the reception time of the second pending CDR is earlier than that of the first pending CDR.

6. A device for determining inconsistent call detail records (CDRs), characterized in that, include: First determination module: used to determine that the first call detail record to be processed does not match the call detail record in the deduplication record table, wherein the deduplication record table is used to record processed call detail records; The swapping module is used to obtain a first target call detail record (CDR) corresponding to the first CDR by swapping the attribute values ​​of the main end number and the peer end number fields of the first CDR to be processed. The call type value of the first target CDR is different from the call type value of the first CDR to be processed. The call type value includes: calling or called. The comparison module is used to compare the first target call detail record (CDR) with each CDR in the deduplication record table; The second determining module is used to determine that the first call detail record to be processed is a call detail record that is inconsistent between the caller and the called party when the first target call detail record does not match any of the call detail records in the deduplication record table. Wherein, the first determining module is further configured to, after determining that the first call detail record to be processed does not match the call detail record in the deduplication record table, record the first call detail record to be processed in the deduplication record table; the second determining module is further configured to, after determining that the first call detail record to be processed is a call detail record of inconsistency between the calling and called parties, mark the first call detail record to be processed in the deduplication record table as a call detail record of inconsistency between the calling and called parties; or, the second determining module is further configured to, after determining that the first call detail record to be processed is a call detail record of inconsistency between the calling and called parties, mark the first call detail record to be processed as a call detail record of inconsistency between the calling and called parties, and record the marked first call detail record to the deduplication record table; The device further includes: The correction module is used to correct and mark the first call detail record (CDR) in the deduplication record table as a non-inconsistent call detail record when the third target CDR corresponding to the third CDR matches the first CDR in the deduplication record table; wherein the first CDR and the third CDR are two CDRs received sequentially, and the reception time of the third CDR is later than the reception time of the first CDR.

7. An electronic device, characterized in that, include: A processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions being executed by the processor to implement the steps of the method for determining inconsistent call detail records as described in any one of claims 1-5.

8. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions, which, when executed by a processor, implement the steps of the method for determining inconsistent call detail records as described in any one of claims 1-5.

Images