Method, device, electronic equipment, medium and product for checking duplicate calls

Abstract

The present application discloses a method, device, electronic device, medium and product for checking duplicate calls, and relates to the field of data query technology. In the present application, when checking duplicate calls, the billing system will check duplicate calls in a preset online duplicate check information table on the online side and in a preset offline duplicate check information table on the offline side based on the session identifier of the session in which the call message is located, and then combine the two query results to determine whether it is a duplicate call. Therefore, in the present application, the two scenarios are combined to share information, so as to avoid the problem of duplicate check omissions as much as possible.

Description

Technical Field

[0001] The present application relates to the technical field of data query, and in particular to a method, device, electronic device, medium and product for checking duplicate calls. Background Art

[0002] Call record duplication check refers to the process of checking the user's call records to find and exclude duplicate billing in order to ensure the accuracy of billing in the communications industry. Among them, duplication check can include offline duplication check and online duplication check. However, it is worth noting that in the existing duplication check method, the implementation logic of online and offline duplication check is independent of each other, and the storage of duplication check information is also independent of each other. For example, the online side uses the sequence number related to the information as the primary key for duplication check, and the online duplication check table saves all online call records in the session in the form of a data list. On the offline side, the key field information in the call record is used as the key value for duplication check, such as the key field can be START_TIME, USER_NUMBER, SGSN_ADDRESS, CHARGING_ID, REC_SEQ_NO, SERVICE_CODE, etc. The offline corresponding duplication check table stores the duplication check information in units of call records, that is, each call record in the database corresponds to a record. Therefore, in the existing duplication check method, the above two scenarios are independent of each other, and the query process cannot communicate with each other, which leads to the problem of duplication omission in some scenarios.

[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0004] The main purpose of this application is to provide a call record duplication checking method, device, electronic device, medium and product, aiming to solve the technical problem that in the existing duplication checking method, the above two scenarios are independent of each other and the query processes cannot communicate with each other, which leads to duplication omissions in certain scenarios.

[0005] To achieve the above purpose, the present application proposes a method for checking duplicate calls, which comprises the following steps:

[0006] Receive a call record message, and determine a session identifier of a session in which the call record message belongs;

[0007] Based on the session identifier, query in a preset online duplicate checking information table, and if no first session record corresponding to the session identifier is found, update the preset online duplicate checking information table according to the call list message;

[0008] Based on the session identifier, a query is performed in the preset offline duplicate checking information table. If no second session record corresponding to the session identifier is found, the call list message updates the preset offline duplicate checking information table and outputs the call list message as a non-duplicate message.

[0009] Optionally, after the step of querying a preset online duplicate checking information table based on the session identifier, the method further includes:

[0010] In the case where a first session record corresponding to the session identifier is queried, determining whether there is a first field block having the same record sequence number as the call bill message in the first session record;

[0011] If there is no first field block with the same record sequence number, the first conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

[0012] Optionally, after the step of determining whether there is a first field block having the same record sequence number as that of the call record message in the first conversation record, the method includes:

[0013] If there is a first field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the first field block indicates that it has been recorded, wherein the corresponding bit of the call record message is determined by the field sequence number and the bit sequence number of the call record message;

[0014] If the representation is not recorded, the first field block is updated, and the step of querying the preset offline duplicate checking information table based on the session identifier is returned to execute;

[0015] If the representation has been recorded, the call bill message is output as a duplicate bill.

[0016] Optionally, after the step of querying a preset offline duplicate checking information table based on the session identifier, the method includes:

[0017] In the case where a second session record corresponding to the session identifier is queried, determining whether there is a second field block having the same record sequence number as the call record message in the second session record;

[0018] If there is no second field block with the same record sequence number, the second conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

[0019] Optionally, after the step of determining whether there is a second field block having the same record sequence number as that of the call record message in the second conversation record, the method includes:

[0020] If there is a second field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the second field block indicates that it has been recorded;

[0021] If the representation is not recorded, the second field block is updated, and the call record message is output as a non-duplicate record;

[0022] If the representation has been recorded, the call bill message is output as a duplicate bill.

[0023] Optionally, the preset online duplication checking information table and the preset offline duplication checking information table are both stored in units of sessions to form session records. For any bit of the field block in the session record, the numerical value on the bit represents that the bit corresponds to the record status of the call record.

[0024] Optionally, after the step of determining the session identifier of the session to which the call record message belongs, the method includes:

[0025] Determine a message sequence number of the call record message in the session;

[0026] Determine the record sequence number of the field block where the call record message is located according to the message sequence number and the unit interval size of the field block;

[0027] According to the message sequence number and the unit length of the field in the field block, the field sequence number of the call record message in the field block and the bit sequence number in the field corresponding to the field sequence number are determined.

[0028] In addition, to achieve the above-mentioned purpose, the present application also proposes an electronic 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 record duplication checking method as described above.

[0029] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the call record duplicate checking method as described above are implemented.

[0030] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the call record duplicate checking method as described above.

[0031] One or more technical solutions proposed in this application have at least the following technical effects:

[0032] In an embodiment of the present application, the billing system will receive a call bill message, determine the session identifier of the session where the call bill message is located; query the preset online duplicate check information table based on the session identifier, and if the first session record corresponding to the session identifier is not found, update the preset online duplicate check information table according to the call bill message; query the preset offline duplicate check information table based on the session identifier, and if the second session record corresponding to the session identifier is not found, the call bill message updates the preset offline duplicate check information table, and outputs the call bill message as a non-duplicate. That is, when checking for duplicates on a call bill, based on determining the session identifier of the session where the call bill message is located, check for duplicates in the preset online duplicate check information table on the online side, and check for duplicates in the preset offline duplicate check information table on the offline side, and then merge the two query results to determine whether it is a duplicate. Therefore, in the present application, the two scenarios are merged to share information, so as to avoid the problem of duplicate checking omissions as much as possible. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0035] Figure 1 This is a flow chart of the first embodiment of the method for checking duplicate calls in this application;

[0036] Figure 2 This is a flow chart of the second embodiment of the method for checking duplicate calls in this application;

[0037] Figure 3 This is a flow chart of the third embodiment of the method for checking duplicate calls in this application;

[0038] Figure 4 This is a schematic diagram of the first scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0039] Figure 5 This is a schematic diagram of the second scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0040] Figure 6 This is a schematic diagram of the third scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0041] Figure 7This is a schematic diagram of the fourth scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0042] Figure 8 This is a schematic diagram of the fifth scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0043] Fig. 9 This is a sixth scenario schematic diagram of the duplicate checking information table in the call record duplicate checking method of this application;

[0044] Fig.10 This is a schematic diagram of the seventh scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0045] Fig.11 This is a schematic diagram of the eighth scenario of the duplicate checking information table in the call record duplicate checking method of this application;

[0046] Fig.12 This is a schematic diagram of the overall process of the call record duplicate checking method for this application;

[0047] Fig.13 This is a schematic diagram of the device structure of the hardware operating environment involved in the call record duplicate checking method in the embodiment of the present application.

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

[0049] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0050] 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.

[0051] Call record duplication check refers to the process of checking the user's call records to find and exclude duplicate billing in order to ensure the accuracy of billing in the communications industry. Among them, duplication check can include offline duplication check and online duplication check. However, it is worth noting that in the existing duplication check method, the implementation logic of online and offline duplication check is independent of each other, and the storage of duplication check information is also independent of each other. For example, the online side uses the sequence number related to the information as the primary key for duplication check, and the online duplication check table saves all online call records in the session in the form of a data list. On the offline side, the key field information in the call record is used as the key value for duplication check, such as the key field can be START_TIME, USER_NUMBER, SGSN_ADDRESS, CHARGING_ID, REC_SEQ_NO, SERVICE_CODE, etc. The offline corresponding duplication check table stores the duplication check information in units of call records, that is, each call record in the database corresponds to a record. Therefore, in the existing duplication check method, the above two scenarios are independent of each other, and the query process cannot communicate with each other, which leads to the problem of duplication omission in some scenarios.

[0052] The main solution of the embodiment of the present application is: receiving a call record message and determining the session identifier of the session to which the call record message belongs; querying in a preset online duplicate checking information table based on the session identifier, and if the first session record corresponding to the session identifier is not found, updating the preset online duplicate checking information table according to the call record message; querying in a preset offline duplicate checking information table based on the session identifier, and if the second session record corresponding to the session identifier is not found, updating the preset offline duplicate checking information table with the call record message, and outputting the call record message as a non-duplicate.

[0053] That is, when the billing system checks for duplicates on a call sheet, it will check for duplicates in the preset online duplicate check information table on the online side and in the preset offline duplicate check information table on the offline side based on the session identifier of the session in which the call sheet message is located, and then combine the two query results to determine whether it is a duplicate order. Therefore, in this application, the two scenarios are integrated to share information, so as to avoid the problem of duplicate checking omissions as much as possible.

[0054] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a cloud platform, a computer, a mobile phone, etc., or an electronic device that can realize the above functions.

[0055] Based on the above introduction, the present application embodiment provides a method for checking duplicate calls. Figure 1 , which is a flow chart of the first embodiment of the call record duplicate checking method of the present application.

[0056] In this embodiment, the method for checking duplicate calls includes steps S10 to S30:

[0057] Step S10, receiving a call record message, and determining a session identifier of the session to which the call record message belongs;

[0058] It should be noted that, in the present embodiment, the above-mentioned method for checking duplicate calls can be applied to the billing system. The billing system can record the expenses incurred by the user for related business activities, and can implement the above-mentioned method for checking duplicate calls to avoid the problem of repeated billing. In addition, it should be noted that the actual checking of duplicate calls is divided into two scenarios, one is online and the other is offline. Among them, the real-time performance of the online side is higher than that of the offline side. Therefore, when a new call bill is generated, it is usually first checked for duplicate records for the information recorded on the online side. That is, if there is a record on the online side, a message of a duplicate call is returned. If there is no record, a message of a non-duplicate call is returned. For the offline side, after an abnormality occurs in the system, a duplicate check is performed again. It should be noted here that the duplicate checking process described above is only a simple summary of the overall framework.

[0059] Exemplarily, the above-mentioned call bill message is usually a call bill message for duplicate checking on the offline side, that is, after an abnormal situation occurs, the call bill message for the offline side can be generated. For example, in the process of real-time query (i.e. sending a real-time query message to the online side) to check the duplicate records, a short-term abnormality occurs in the communication between the gateway that sends the message to the billing system and the billing system, resulting in a real-time query message not being successfully sent out. At this time, the gateway can record the query message and form a call bill message to send to the offline side of the billing system for duplicate checking. Alternatively, the gateway successfully sends a real-time query message to the billing system, but does not normally receive the receipt confirmation message fed back by the billing system. At this time, the gateway generates a call bill message based on the query message and sends it to the offline side of the billing system for duplicate checking.

[0060] Exemplarily, the billing system may receive a call record message sent by the gateway, and the call record message may include relevant information about the session where the call record is located, for example, the ID (Identity Document) number of the session. It is understandable that a session may refer to a call, and multiple call records may be generated in a session. For example, different services may be consumed in a session, and for the call itself, periodic charges may also be generated, thereby forming multiple call records. Similarly, the call record message may also include the serial number of the call record, and the serial number of a certain call record may represent the order in which the call record is generated in the corresponding session. After receiving the call record message, the session identifier of the session where the call record message is located is first determined, such as extracting the session ID from the call record message, and the session ID may be directly used as the above-mentioned session identifier, or the session ID may be calculated by MD5 (Message-Digest Algorithm 5, a password expansion function) to obtain the above-mentioned session identifier.

[0061] Step S20, querying in a preset online duplicate checking information table based on the session identifier, and updating the preset online duplicate checking information table according to the call list message when no first session record corresponding to the session identifier is found;

[0062] It should be noted that since the real-time performance of the online side is higher than that of the offline side, priority is given to querying from the preset online duplicate checking information table.

[0063] Exemplarily, a query is performed in a preset online duplicate check information table based on a session identifier, wherein the online duplicate check information table will be saved in units of sessions to form records, and accordingly, each record can be saved using the session identifier of the corresponding session as the primary key. Accordingly, if a session record identical to the above-mentioned session identifier is found in the preset online duplicate check information table, it indicates that the first session record corresponding to the session identifier has been queried, otherwise, it indicates that the first session record corresponding to the session identifier has not been queried. It can be understood that if the first session record corresponding to the session identifier is not queried, the preset online duplicate check information table can be updated according to the call list message, for example, a new session record is added to the preset online duplicate check information table, thereby obtaining the above-mentioned first session record. At the same time, it can also indicate that the call sheet corresponding to the above-mentioned call list message may not be a duplicate sheet, but it needs to be further checked in the preset offline duplicate check information table in subsequent steps before being determined.

[0064] Step S30, based on the session identifier, query the preset offline duplication check information table. If the second session record corresponding to the session identifier is not found, the call list message updates the preset offline duplication check information table and outputs the call list message as a non-duplicate list.

[0065] Exemplarily, if the first session record corresponding to the session identifier is not found, a query is further performed in the preset offline duplication check information table based on the above session identifier. It is worth noting that the format or structure of the information stored in the preset offline duplication check information table is the same as that in the preset online duplication check information table, so the query process can refer to the above content and will not be repeated here. Similarly, if the second session record corresponding to the session identifier is not found in the preset offline duplication check information table (the first and second representations in the first session record and the second session record are derived from different tables), the above call list message (or the call list corresponding to the call list message) can be characterized as a non-duplicate list, and similarly, the preset offline duplication check information table is updated.

[0066] In this embodiment, the billing system will receive a call bill message, determine the session identifier of the session where the call bill message is located; query the preset online duplicate check information table based on the session identifier, and update the preset online duplicate check information table according to the call bill message when the first session record corresponding to the session identifier is not found; query the preset offline duplicate check information table based on the session identifier, and update the preset offline duplicate check information table according to the call bill message when the second session record corresponding to the session identifier is not found, and output the call bill message as a non-duplicate. That is, when checking for duplicates on a call bill, based on determining the session identifier of the session where the call bill message is located, check for duplicates in the preset online duplicate check information table on the online side and in the preset offline duplicate check information table on the offline side, and then merge the two query results to determine whether it is a duplicate. Therefore, in this application, the two scenarios are merged to share information, so as to avoid the problem of duplicate checking omissions as much as possible.

[0067] In a feasible implementation manner, the preset online duplication checking information table and the preset offline duplication checking information table are both stored in units of sessions to form session records. For any bit of the field block in the session record, the numerical value on the bit represents that the bit corresponds to the record status of the call record.

[0068] It should be noted that in this embodiment, in order to integrate and communicate the two scenarios, the storage data formats of the two tables will be unified. Exemplarily, in the preset online duplicate checking information table and the preset offline duplicate checking information table, the session will be stored in units of sessions to form a session record. For example, the session record may include the session identifier of the session and a field block representing the record status of each call sheet under the session. Among them, the field block includes multiple bytes, each byte includes eight bits, and the value on the bit represents the record status of the call sheet corresponding to the bit. For example, if the first bit in the field block of a session record is 1, it represents that the first call sheet generated under the session corresponding to the session record has been recorded. On the contrary, if it is 0, it represents that it has not been recorded.

[0069] Exemplarily, the storage model of the online duplicate checking information table is shown in Table 1 below:

[0070]

[0071]

[0072] Table 1

[0073] Exemplarily, the storage model of the offline duplicate checking information table is shown in Table 2 below:

[0074]

[0075] In the above table, m_szDupKey can represent the phone number involved in the session, m_iVbufferIndex can represent the correspondence between the record number and the field block, and m_llLockKey can represent the object lock obtained after obtaining the MD5 value of the session ID. m_llVbuffer0~4 represents fields 0 to 4 under the field block corresponding to the record number. m_llUpdateTime can represent the update time. It should be understood that in actual applications, technicians can refer to the contents in the above table to set the storage model, so it will not be repeated here.

[0076] Taking a specific example, the SESSION_ID (ID number) of the session can be used as the primary key, and the MD5 value of the SESSION_ID can be used as the M object lock (i.e., m_llLockKey). When performing business operations, the SESSION_ID value is used as the minimum granularity of the business lock to ensure data consistency in the scenario where the call records (including online and offline call records) of the same user and the same session are concurrently checked for duplicates.

[0077] The duplicate check information is stored in 5 8-byte (8-bit per byte) fields (m_llVbuffer0-4), and the processed message sequence numbers (SEQUENCE_NO) are stored in order from low to high. Each record in the two tables can store the duplicate check information of 320 (5[m_llVbuffer0-4]*8[bytes]*8[bits]) call records 0 in a session. When the call record sequence number (SEQUENCE_NUMBER) in the session is greater than or equal to 320, a duplicate check record will be added, and the value of the 4-byte m_iVbufferIndex will be set to 1.

[0078] The value range of the 4-byte m_iVbufferIndex is [0,2,147,483,647]. Therefore, from a design perspective, for the same session, the duplicate check information table can store a maximum of 2,147,483,648*320=687,194,767,360 call records of duplicate check information. This design upper limit far exceeds the maximum number of call records that may be generated in the same session in actual situations, thus ensuring that call record overflow does not occur.

[0079] Reference Figure 2 , is a flow chart of a second embodiment of the method for checking duplicate calls in the present application, which is proposed based on the first embodiment of the method for checking duplicate calls in the present application. In this embodiment, the same or similar contents as those in the above embodiment can be referred to the above introduction, and will not be repeated later. After the step of querying in the preset online duplicate checking information table based on the session identifier, the method further includes steps S21 to S22:

[0080] Step S21, when a first session record corresponding to the session identifier is found, determining whether there is a first field block having the same record sequence number as the call bill message in the first session record;

[0081] Step S22: If there is no first field block with the same record number, the first conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

[0082] It should be noted that if a query is performed in the preset online duplicate checking information table based on the session identifier, and the first session record corresponding to the above session identifier is found, a more detailed query is required.

[0083] Exemplarily, it is further determined whether there is a first field block with the same record sequence number as the call list message in the first session record. For example, the record sequence number of the call list message can be calculated first, and the record sequence number can be calculated by the sequence number of the call list message and the unit size of the field block. After obtaining the record sequence number, it can be determined whether there is a m_iVbufferIndex value that is the same as the record sequence number. If so, it indicates whether there is a first field block with the same record sequence number as the call list message in the first session record. On the contrary, if it does not exist, it indicates that there is no first field block with the same record sequence number. At this time, the first session record can also be updated based on the call list message, such as adding a new field block under the first session record. At the same time, the information that the call list message is not a duplicate message can also be fed back to the gateway, or a duplicate check party can be requested.

[0084] In a feasible implementation manner, after the step of determining whether there is a first field block with the same record sequence number as the call bill message in the first conversation record, the method includes steps S211 to S213:

[0085] Step S211, if there is a first field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the first field block indicates that it has been recorded, wherein the corresponding bit of the call record message is determined by the field sequence number and the bit sequence number of the call record message;

[0086] Step S212: if the representation is not recorded, the first field block is updated, and the step of querying the preset offline duplicate checking information table based on the session identifier is returned to execute;

[0087] Step S213: if the representation has been recorded, output the call bill message as a duplicate bill.

[0088] Exemplarily, if the first field block with the same record number is queried, a search is required. That is, determine whether the value of the corresponding bit of the call list message in the first field block indicates that it has been recorded. Similarly, the field number and bit number of the call list message can be calculated, and then the field number and bit number can be used to search for the bit corresponding to the call list message in the first field block. If the value on the corresponding bit is 1, it indicates that it has been recorded. If the value on the corresponding bit is 0, it indicates that it has not been recorded. Correspondingly, if it indicates that it has not been recorded, the first field block is updated, such as setting the value on the corresponding bit to 1. In order to ensure the accuracy of the duplicate check, the step of querying the preset offline duplicate check information table based on the session identifier is returned to determine whether it is a non-duplicate order. If it indicates that it has been recorded, the call list message is output as a duplicate order to the duplicate check requesting party.

[0089] In a feasible implementation manner, after the step of querying the preset offline duplicate checking information table based on the session identifier, the method includes steps S31 to S32:

[0090] Step S31, when a second session record corresponding to the session identifier is found, determining whether there is a second field block having the same record sequence number as the call record message in the second session record;

[0091] Step S32: If there is no second field block with the same record number, the second conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

[0092] It should be noted that the process of checking for duplicates by presetting an offline duplicate checking information table on the offline side is basically the same as the process of checking for duplicates by presetting an online duplicate checking information table on the online side. Therefore, the above process can also be referred to.

[0093] Exemplarily, if a second session record corresponding to the above session identifier is found in the preset offline duplicate check information table, further detailed query is required. That is, it is determined whether there is a second field block with the same record number as the call slip message in the second session record. If there is no identical second field block, it means that the call slip message is not a duplicate message, and accordingly, a message that the call slip message is not a duplicate message is fed back to the duplicate check requesting party. At the same time, the second session record is updated based on the call slip message, such as adding a second field block corresponding to the call slip message in the second session record.

[0094] In a feasible implementation manner, after the step of determining whether there is a second field block with the same record sequence number as the call record message in the second conversation record, the method includes steps S311 to S313:

[0095] Step S311, if there is a second field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the second field block indicates that it has been recorded;

[0096] Step S312: if the representation is not recorded, the second field block is updated, and the call bill message is output as a non-duplicate bill;

[0097] Step S313: if the representation has been recorded, output the call bill message as a duplicate bill.

[0098] Exemplarily, if there is a second field block with the same record sequence number in the second session record, it can be further determined whether the value of the corresponding bit of the call bill message in the second field indicates that it has been recorded. Similarly, if the value is 0, it indicates that it has not been recorded, and the second field block is updated, that is, the value is set to 1, and then the call bill message is output as a non-duplicate to the duplicate check requesting party. If the value is 1, it indicates that it has been recorded, and the call bill message is output as a duplicate to the duplicate check requesting party.

[0099] It can be understood that the above process is a process of integrating offline and online scenarios. After the formats of storing information in the preset online duplication checking information table and the preset offline duplication checking information table are unified, the same method can be used to query in the two tables.

[0100] Reference Figure 3 , is a flow chart of a third embodiment of the method for checking duplicate calls in the present application, which is proposed based on the first embodiment and the second embodiment of the method for checking duplicate calls in the present application. In this embodiment, the same or similar contents as those in the above embodiments can be referred to the above description, and will not be described in detail later. After the step of determining the session identifier of the session in which the call record message is located, the method includes steps S01 to S03:

[0101] Step S01, determining the message sequence number of the call record message in the current session;

[0102] Step S02, determining the record sequence number of the field block where the call record message is located according to the message sequence number and the unit interval size of the field block;

[0103] Step S03, determining the field sequence number of the call record message in the field block and the bit sequence number in the field corresponding to the field sequence number according to the message sequence number and the unit length of the field in the field block.

[0104] It should be noted that after the step of determining the session identifier of the session in which the call record message is located, the record sequence number, field sequence number and bit sequence number of the call record message can be uniformly calculated. Alternatively, they can be calculated when needed during the duplicate checking process.

[0105] Exemplarily, the message sequence number of the call record message in the session is determined, such as the message sequence number can be directly extracted from the call record message, that is, the sequence number of the call record corresponding to the call record message. According to the message sequence number and the unit interval size of the field block, the record sequence number of the field block where the call record message is located is calculated. For example, in this embodiment, a field block is set to include five fields, each field includes eight bytes, and each byte includes eight bits, and one bit can store the record status of a call record. Therefore, a field block can store the record status of 320 call records, that is, the unit interval size of the field block is 320. When calculating the record sequence number, the result of dividing the message sequence number by the unit interval size of the field block can be used to obtain the record sequence number. If the message sequence number is 30 and divided by 320, 0 is obtained and the remainder is 30, then the record sequence number is 0. Of course, due to the existence of the remainder, it can also be carried forward by one bit to obtain the record sequence number of 1. Specifically, the calculation process can also be set by the technical personnel, which will not be repeated here.

[0106] Similarly, based on the above example, each field includes eight bytes, and each byte includes eight bits, so the unit length of the field is 64. If the message sequence number is 0 and the remainder is 30, divide 30 by 64, and you will get 0 with a remainder of 30, so the field sequence number can be 0, and accordingly, 30 is the bit sequence number. Referring to the above process, you can get the message sequence number, record sequence number, and bit sequence number.

[0107] In addition, in order to clearly illustrate the present solution, it will be described in the form of diagrams.

[0108] For example, when the SEQUENCE_NO (also known as SEQUENCE_NUMBER, the message sequence number of the call record or call record message) of the message received by the online side of the billing system is 0, after checking the message for duplicates, the duplicate checking information recorded in the CDupSession table (blue) is as follows: Figure 4 As shown in the figure, in the field block with record number 0, the value of the first bit in the field with field number 0 is 1.

[0109] When the SEQUENCE_NO of the received message is 1, after checking the message for duplicates, the duplicate checking information recorded in the CDupSession table (blue) is as follows: Figure 5 As shown in the figure, in the field block with record number 0, the value of the bit at the second position in the field with field number 0 is 1.

[0110] When the SEQUENCE_NO of the received message is 2, after checking the message for duplicates, the duplicate checking information recorded in the CDupSession table (blue) is as follows: Figure 6 As shown in the figure, in the field block with record number 0, the value of the bit at the third position in the field with field number 0 is 1.

[0111] The SEQUENCE_NO of the received message is 4, and assuming that the message with SEQUENCE_NO 3 has not been received, after checking the duplicate of the message, the duplicate checking information recorded in the CDupSession table (blue) is as follows Figure 7 As shown in the figure, in the field block with the record number 0, the value of the bit at the fifth position in the field with the field number 0 is 1.

[0112] When the SEQUENCE_NO of the message received by online billing is 65, and assuming that the bills with SEQUENCE_NOs 5 to 63 have been received, after checking the duplicate of the message, the duplicate checking information recorded in the CDupSession table (blue) is as follows Figure 8 shown.

[0113] For the message with SEQUENCE_NO=3, the gateway recognizes that the message with SEQUENCE_NO=3 has not been sent successfully, and then sends it again to the offline side of the billing system. Correspondingly, if the offline side receives a call sheet with SEQUENCE_NO=3, after checking the duplicates of the offline side, the duplicate checking information recorded in the CDupSession (blue) and CRedoDup (green) tables are as follows: Fig. 9 and Fig.10 As shown. In both tables, in the field block with record number 0, the value of the bit at the third position in the field with field number 0 is 1.

[0114] When the billing system receives a message with SEQUENCE_NO 320, assuming that it has received bills with SEQUENCE_NO 65 to 319, when the bill sequence number (SEQUENCE_NUMBER) in the session is greater than or equal to 320, a new record will be added to the CDupSession table, and the m_iVbufferIndex with a length of 4 bytes will be set to 1. After checking the message for duplicates, the duplicate checking information recorded in the CDupSession table (blue) is as follows: Fig.11 As shown in the figure, in the field block with record number 1, the value of the first bit in the field with field number 0 is 1.

[0115] In addition, refer to Fig.12 , is a schematic diagram of the overall process of the application duplication checking method. As shown in the figure:

[0116] Step 1: Get the SESSION_ID.

[0117] Step 2: Obtain the MD5 value of SESSION_ID and use it as the MDB object lock (m_llLockKey, also known as the session identifier).

[0118] Step 3: Get the message sequence number of the call record (or call record message): SEQUENCE_NUMBER.

[0119] Step 4: Divide the message sequence number by the size of the duplicate checking interval (i.e., the unit interval size of the field block) to obtain the corresponding record sequence number: m_iVbufferIndex = SEQUENCE_NUMBER / 320.

[0120] Step 5: After taking the modulus of the message sequence number and the duplicate checking interval, divide it by the length of a single m_llVBuffer field, 64 (that is, the unit length of the field), and obtain the field sequence number corresponding to a single record: m_llVBuffer0~4=mod(SEQUENCE_NUMBER,320) / 64.

[0121] Step 6: After taking the modulus of the message sequence number and the duplicate checking interval, take the modulus of the length of a single m_llVBuffer field, 64, and calculate the bit sequence number in the corresponding single m_llVBuffer field: mod(mod(SEQUENCE_NUMBER,320),64).

[0122] Step 7: Query table CDupSession (i.e. the preset online duplicate checking information table).

[0123] Step 8: Based on the query results, determine whether there is duplicate checking information for the current session (such as the first session record) in the table CDupSesion.

[0124] Step 8.1: If it does not exist, add a new duplicate check record in the CDupSession table according to the current call list information (that is, update the preset online duplicate check information table), and then jump to step 11.

[0125] Step 8.2: If it exists, it is necessary to determine whether there is duplicate check information with the same sequence number as the current call record.

[0126] Step 9: Determine whether there is duplicate check information (such as the first field block) with the same sequence number as the current call bill record.

[0127] Step 9.1: If it does not exist, add a new duplicate check record in the CDupSession table according to the information of the current call record (that is, update the first session record), and then return a non-duplicate order mark.

[0128] Step 9.2: If it exists, it is necessary to determine whether the bit value of the bit sequence number in the single m_llVBuffer field corresponding to the current call record is 1.

[0129] Step 10: Determine whether the bit value of the bit sequence number in the single m_llVBuffer field corresponding to the current call record is 1.

[0130] Step 10.1: If it is not 1, update the corresponding bit in the m_llVBuffer field of the table CDupSession to 1 (that is, update the first field block), and then jump to step 11.

[0131] Step 10.2: If it is 1, return the duplicate order mark to confirm that it is a duplicate order.

[0132] Step 11: Query table CRedoDup (that is, the preset offline duplication checking information table).

[0133] Step 12: Based on the query results, determine whether there is duplicate checking information for the current session in the CRedoDup table.

[0134] Step 12.1: If it does not exist, add a duplicate check record in the CRedoDup table based on the current call order information, and then return a non-duplicate order mark.

[0135] Step 12.2: If it exists, determine whether there is duplicate check information with the same sequence number as the current call list record.

[0136] Step 13: Determine whether there is duplicate information with the same sequence number as the current call record.

[0137] Step 13.1: If it does not exist, add a duplicate check record in the CRedoDup table based on the current call order information, and then return a non-duplicate order mark.

[0138] Step 13.2: If it exists, it is necessary to determine whether the bit value of the bit sequence number in the single m_llVBuffer field corresponding to the current call record is 1.

[0139] Step 14: Determine whether the bit value of the bit sequence number in the single m_llVBuffer field corresponding to the current call record is 1.

[0140] Step 14.1: If it is not 1, update the corresponding bit in the m_llVBuffer field of table CRedoDup to 1, and then return the non-duplicate order flag.

[0141] Step 14.2: If it is 1, return the duplicate order mark to confirm that it is a duplicate order.

[0142] It can be understood that in this embodiment, the duplicate checking record at the call sheet level in the existing duplicate checking scheme is adjusted to a session level duplicate checking record. And a duplicate checking record at the call sheet level is changed to occupy only one BIT position (bit) in the session level record. At the same time, an index is used to accurately locate the BIT position of the serial number of the current call sheet in the session level duplicate checking record, and it is verified and checked for duplicates, thereby improving the efficiency of duplicate checking. It also reduces the waste of duplicate checking memory resources, improves the efficiency of duplicate checking, reduces the use of mdb (a storage file), and is easy to maintain.

[0143] Further, refer to Table 3 and Table 4 below:

[0144] Number of call records (millions) Memory usage 5 15.13 6 17.38 7 23.92 8 25.49 9 28.96 10 29.49 11 35.49 12 40.49 13 41.93 14 43.41 15 48.98 16 52.35 17 57.48 18 61.38

[0145] Table 3

[0146] Number of call records (millions) Memory usage 5 5.04 6 5.79 7 7.24 8 7.49 9 7.94 10 8.37 11 8.87 12 10.12 13 12.48 14 14.47 15 16.79 16 15.47 17 17.49 18 18.34

[0147] Table 4

[0148] Among them, Table 3 shows the memory usage of the existing duplicate checking scheme in the face of different scales of call record storage scenarios. Table 4 shows the memory usage of the duplicate checking method of this application in the face of different scales of call record storage scenarios under the same hardware conditions. Obviously, the way of recording call records in the call record duplication checking method of this application can greatly reduce the storage space.

[0149] Reference below Fig.13, which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to mobile terminals such as computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and fixed terminals such as computers. Fig.13 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0150] like Fig.13 As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the electronic device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0151] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a 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 through a communication device, or installed from a storage device 1003, or installed from a ROM 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 executed.

[0152] The electronic device provided by the present application adopts the method for checking duplicate calls in the above embodiment, which can solve the technical problem that the above two scenarios are independent of each other and the query process cannot communicate with each other in the existing checking duplicate method, resulting in omissions in checking duplicate calls in certain scenarios. Compared with the prior art, the beneficial effects of the electronic device provided by the present application are the same as the beneficial effects of the method for checking duplicate calls in the above embodiment, and the other technical features of the electronic device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0153] It should be understood that the various parts disclosed in this application can be implemented by 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.

[0154] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0155] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the method for checking duplicate calls in the above-mentioned embodiment.

[0156] The computer-readable storage medium provided in the present application 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 of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0157] The computer-readable storage medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0158] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by an electronic device, the electronic device:

[0159] Receive a call record message, and determine a session identifier of a session in which the call record message belongs;

[0160] Based on the session identifier, query in a preset online duplicate checking information table, and if no first session record corresponding to the session identifier is found, update the preset online duplicate checking information table according to the call list message;

[0161] Based on the session identifier, a query is performed in the preset offline duplicate checking information table. If no second session record corresponding to the session identifier is found, the call list message updates the preset offline duplicate checking information table and outputs the call list message as a non-duplicate message.

[0162] 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 separate 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 through 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).

[0163] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the 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 square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0164] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0165] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned method for checking duplicate calls, and can solve the technical problem that the above-mentioned two scenarios are independent of each other and the query processes cannot communicate with each other in the existing method for checking duplicate calls, which leads to omissions in checking duplicate calls in certain scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the method for checking duplicate calls provided by the above-mentioned embodiment, and will not be elaborated here.

[0166] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned call record duplicate checking method when executed by a processor.

[0167] The computer program product provided by this application can solve the technical problem of duplicate call check. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the duplicate call check method provided by the above embodiment, which will not be repeated here.

[0168] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for checking duplicate calls, characterized in that: The call record duplicate checking method comprises: Receive a call record message, and determine a session identifier of a session in which the call record message belongs; Based on the session identifier, query in a preset online duplicate checking information table, and if no first session record corresponding to the session identifier is found, update the preset online duplicate checking information table according to the call list message; Based on the session identifier, a query is performed in the preset offline duplicate checking information table. If no second session record corresponding to the session identifier is found, the call list message updates the preset offline duplicate checking information table and outputs the call list message as a non-duplicate message.

2. The method for checking duplicate calls as claimed in claim 1, characterized in that: After the step of querying in a preset online duplicate checking information table based on the session identifier, the method further includes: In the case where a first session record corresponding to the session identifier is queried, determining whether there is a first field block having the same record sequence number as the call bill message in the first session record; If there is no first field block with the same record sequence number, the first conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

3. The method for checking duplicate calls as claimed in claim 2, characterized in that: After the step of determining whether there is a first field block having the same record sequence number as that of the call record message in the first conversation record, the method includes: If there is a first field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the first field block indicates that it has been recorded, wherein the corresponding bit of the call record message is determined by the field sequence number and the bit sequence number of the call record message; If the representation is not recorded, the first field block is updated, and the step of querying the preset offline duplicate checking information table based on the session identifier is returned to execute; If the representation has been recorded, the call bill message is output as a duplicate bill.

4. The method for checking duplicate calls as claimed in claim 1, characterized in that: After the step of querying the preset offline duplicate checking information table based on the session identifier, the method includes: In the case where a second session record corresponding to the session identifier is queried, determining whether there is a second field block having the same record sequence number as the call record message in the second session record; If there is no second field block with the same record sequence number, the second conversation record is updated based on the call record message, and the call record message is output as a non-duplicate record.

5. The method for checking duplicate calls as claimed in claim 4, characterized in that: After the step of determining whether there is a second field block having the same record sequence number as that of the call record message in the second conversation record, the method includes: If there is a second field block with the same record sequence number, determining whether the value of the corresponding bit of the call record message in the second field block indicates that it has been recorded; If the representation is not recorded, the second field block is updated, and the call record message is output as a non-duplicate record; If the representation has been recorded, the call bill message is output as a duplicate bill.

6. The method for checking duplicate calls according to any one of claims 1 to 5, characterized in that: The preset online duplicate checking information table and the preset offline duplicate checking information table are both stored in units of sessions to form session records. For any bit of the field block in the session record, the value on the bit represents that the bit corresponds to the record status of the call record.

7. The method for checking duplicate calls according to any one of claims 1 to 5, characterized in that: After the step of determining the session identifier of the session in which the call record message is located, the method includes: Determine a message sequence number of the call record message in the session; Determine the record sequence number of the field block where the call record message is located according to the message sequence number and the unit interval size of the field block; According to the message sequence number and the unit length of the field in the field block, the field sequence number of the call record message in the field block and the bit sequence number in the field corresponding to the field sequence number are determined.

8. An electronic device, characterized in that: The electronic device comprises: a processor, a memory, and a call record duplication checking program stored in the memory and executable on the processor, wherein the call record duplication checking program implements the steps of the call record duplication checking method as claimed in any one of claims 1 to 6 when executed.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a call record duplication checking program, and when the call record duplication checking program is executed, the steps of the call record duplication checking method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product includes a call record duplication checking program, and when the call record duplication checking program is executed by a processor, the steps of the call record duplication checking method according to any one of claims 1 to 6 are implemented.

Images