Number backfilling method, device and equipment based on URL (Uniform Resource Locator) and storage medium

Abstract

The invention discloses a URL-based number backfilling method and device, equipment and a storage medium, and belongs to the technical field of communication. According to the method, the first XDR information corresponding to the current business process is acquired, the first target URL is determined from the URLs carried by the first XDR information under the condition that the first XDR information does not carry the calling and called number information, and then the calling and called number information associated with the first target URL is queried from the preset memory database. And backfilling the queried calling and called number information to the first XDR information. According to the method and the device, backfilling of the XDR calling and called numbers of the business process which does not carry the calling and called number information can be realized.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a URL-based number backfilling method, apparatus, device and storage medium. Background Art

[0002] With the rapid development of the 5G industry, China Mobile and other operators have gradually launched some 5G feature applications, such as 5G New Calls. 5G New Calls are ultra-clear voice calls, video call services and related value-added services based on 5G networks, including 5G VoNR (Voice over NR, 5G voice solution) ultra-clear video calls, 5G video customer service, intelligent translation functions, screen sharing, remote collaboration and AR fun calls, etc., which can provide users with visual, multimedia and highly perceived ultra-clear call experience.

[0003] In order to ensure the normal and stable operation of the 5G new call network, the 5G new call core network is equipped with a signaling monitoring system to monitor the key indicators of data service operation in real time, eliminate network risks in advance, and quickly locate sudden failures. The output product of the 5G new call signaling monitoring system is XDR (X Data Recording). The two key information in XDR are the calling user number and the called user number. These two key information must be filled in to identify which two users triggered the XDR service.

[0004] During a 5G new call, service interactions between multiple NFs (Network Functions) will be triggered in the call network. For each service interaction between NFs, the signaling monitoring system will collect the corresponding signaling and output an XDR. However, only some individual service processes between NFs carry the calling user number information and the called user number information in the signaling. Most service process signaling between NFs does not carry the calling user number information, resulting in the output XDR not carrying the calling user number information, and unable to identify which two users triggered the service process corresponding to this XDR, so that the key operating indicators of these service processes cannot be effectively monitored. Summary of the invention

[0005] The main purpose of the present application is to provide a URL (Uniform Resource Locator)-based number backfilling method, device, equipment and storage medium, aiming to realize number backfilling for XDR of a business process that does not carry the calling and called number information.

[0006] To achieve the above purpose, the present application provides a URL-based number backfilling method, comprising: Obtain the first XDR information corresponding to the current business process; In the case that the first XDR information does not carry the calling or called number information, determining a first target URL from the URL carried in the first XDR information, wherein the first target URL is a URL carried in both the signaling of the current service process and the signaling of the previous service process; The calling and called number information associated with the first target URL is queried from a preset memory database, and the queried calling and called number information is filled back into the first XDR information.

[0007] In addition, to achieve the above purpose, the present application also provides a URL-based number backfilling device, including: An XDR receiving module, configured to obtain first XDR information corresponding to a current business process; The business processing module is configured to determine a first target URL from the URL carried by the first XDR information when the first XDR information does not carry the calling or called number information, wherein the first target URL is a URL carried jointly in the signaling of the current business process and the previous business process; query the calling or called number information associated with the first target URL from a preset memory database, and fill the queried calling or called number information back into the first XDR information.

[0008] In addition, to achieve the above-mentioned purpose, the present application also provides a URL-based number backfill device, which includes: a memory, a processor, and a URL-based number backfill program stored on the memory and executable on the processor, and when the URL-based number backfill program is executed by the processor, the URL-based number backfill method as described above is implemented.

[0009] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, which is a computer-readable storage medium, and a URL-based number backfill program is stored on the computer-readable storage medium. When the URL-based number backfill program is executed by the processor, the URL-based number backfill method as described above is implemented.

[0010] The present application proposes a URL-based number backfilling method, apparatus, device and storage medium. In the URL-based number backfilling method, the technical solution of the embodiment of the present application is to obtain the first XDR information corresponding to the current business process, and when the first XDR information does not carry the calling number or called number information, determine the first target URL from the URL carried by the first XDR information, wherein the first target URL is the URL carried in the signaling of the current business process and the previous business process, and then query the calling number or called number information associated with the first target URL from a preset memory database, and backfill the queried calling number or called number information into the first XDR information. In specific implementation, the first target URL can be used as the key to query the calling and called number information in the memory database. If the query is successful, the calling and called number information is retrieved and placed in the first XDR information corresponding to the current business process to complete the backfilling of the calling and called number of the XDR of the current business process. When the 5G new call signaling monitoring system receives HTTP / 2 (Hypertext Transfer Protocol Version 2) related signaling that does not carry the calling and called user number information, it can backfill the calling and called number of the XDR of these business processes, so that these business processes can identify which two users triggered the XDR service, thereby effectively monitoring the key operating indicators of these business processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying any creative work.

[0012] Figure 1 This is a flowchart of the first embodiment of the URL-based number backfilling method of the present application; Figure 2 This is a flow chart of the second embodiment of the URL-based number backfilling method of the present application; Figure 3 This is a schematic diagram of the structure of a URL-based number backfilling device according to an embodiment of the present application; Figure 4 A schematic diagram of a 5G new call network architecture according to an example of the present application; Figure 5 This is a call control flow chart of interface 3 and interface 9 in the embodiment of the present application; Figure 6 This is a processing flow chart of call event control in an embodiment of the present application; Figure 7 This is a business control flow chart of interface 5 and interface 9 in the embodiment of the present application; Figure 8 This is a flow chart of media stream duplication control of interface 5, interface 7 and interface 9 in an embodiment of the present application; Fig. 9 This is a flow chart of the playback control of interface 5 and interface 9 in the embodiment of the present application; Fig.10 This is a flowchart of the number receiving control of interface 5 and interface 9 in the embodiment of the present application; Fig.11 This is a flow chart of media element synthesis control of interface 5 and interface 9 in the embodiment of the present application; Fig.12 This is a flow chart of intelligent translation control according to an example of this application; Fig.13 This is a fun call control flow chart of an example of this application; Fig.14 This is a DC data interaction control flow chart of an example of this application; Fig.15 This is a schematic diagram of the functional modules of the URL-based number backfilling device according to an embodiment of the present application; Fig.16 This is a schematic diagram of the hardware structure of a URL-based number backfill device involved in an embodiment of the present application.

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

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

[0015] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0016] It should be noted that all directional indications in the embodiments of the present application (such as up, down, left, right, front, back, etc.) are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0017] In this application, unless otherwise clearly specified and limited, the terms "connection", "fixation", etc. should be understood in a broad sense. For example, "fixation" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, it can be the internal connection of two elements or the interaction relationship between two elements, unless otherwise clearly defined. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0018] In addition, in this application, descriptions such as "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in this field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0019] During a 5G new call, service interactions between multiple NFs (Network Functions) will be triggered in the call network. For each service interaction between NFs, the signaling monitoring system will collect the corresponding signaling and output an XDR. However, only some individual service processes between NFs carry the calling user number information and the called user number information in the signaling. Most service process signaling between NFs does not carry the calling user number information, resulting in the output XDR not carrying the calling user number information, and unable to identify which two users triggered the service process corresponding to this XDR, so that the key operating indicators of these service processes cannot be effectively monitored.

[0020] Based on this, the embodiment of the present application provides a method for backfilling numbers based on URLs, referring to Figure 1 , Figure 1 The following is a flow chart of an embodiment of a method for backfilling numbers based on a URL of the present application. In this embodiment, the method for backfilling numbers based on a URL includes: Step S10, obtaining first XDR information corresponding to the current business process; In this embodiment, the types of business processes include but are not limited to call control processes of the 5G new call core network, media stream replication control processes, playback control processes, number collection control processes, media element synthesis control processes, intelligent translation control processes, fun call control processes and DC data interaction control processes.

[0021] The first XDR information refers to the XDR (X Data Recording) information corresponding to the current service process. Those skilled in the art will know that XDR information is generally the output product of the signaling monitoring system, and XDR includes two key information: the calling user number and the called user number. These two key information must be filled in to identify which two users triggered the call.

[0022] Exemplarily, in step S10, first XDR information corresponding to the current business process is obtained.

[0023] In this embodiment, the first XDR information may be the XDR information output by the signaling monitoring system after being decoded by TLV (Type Length Value) decoding or fixed structure decoding. That is, obtaining the first XDR information corresponding to the current service process should also include the protection scope of "obtaining the XDR encoding information output by the signaling monitoring system, decoding the XDR encoding information, and obtaining the first XDR information corresponding to the current service process".

[0024] After step S10, executing step S20, when the first XDR information does not carry the calling and called number information, determining a first target URL from the URL carried in the first XDR information, wherein the first target URL is a URL carried in both the signaling of the current service process and the previous service process; Step S30: query the calling and called number information associated with the first target URL from a preset memory database, and fill the queried calling and called number information back into the first XDR information.

[0025] In this embodiment, the memory database stores multiple URLs and the calling and called number information associated with each URL in a one-to-one correspondence. Therefore, the calling and called number information associated with the first target URL can be obtained by querying from the preset memory database.

[0026] It is known that the first XDR information does not carry the calling and called number information, indicating that the current business process does not carry the calling user number information and the called user number information in the signaling for business interaction. In order to realize the backfilling of the calling and called number of the signaling, therefore, this embodiment determines the first target URL from the URL carried by the first XDR information, wherein the first target URL is the URL carried in the signaling of the current business process and the previous business process, and then queries the calling and called number information associated with the first target URL from the preset memory database, and backfills the queried calling and called number information into the first XDR information, thereby completing the filling of the calling and called number of the XDR.

[0027] Exemplarily, after the step of backfilling the queried calling and called number information into the first XDR information in step S30, the method further includes: Step A10: sending the first XDR information after backfilling the calling and called number information to a third-party application.

[0028] In this embodiment, it should be noted that before sending the first XDR information after filling in the calling and called number information to the third party, it can be encoded by TLV (Type Length Value) encoding or fixed structure encoding and then sent to the third-party application. That is, sending the first XDR information after filling in the calling and called number information to the third-party application should also include the protection scope of "encoding the first XDR information after filling in the calling and called number information and then sending it to the third-party application".

[0029] In this embodiment, the third-party application is an application platform other than the signaling monitoring system. In another example, the execution subject of the embodiment of the present application is the first NF unit, and the third-party application may be a second NF unit that performs service interaction with the first NF unit. In another example, the execution subject of the embodiment of the present application is the first signaling interface device, and the third-party application may be a second signaling interface device that performs service interaction with the first signaling interface. In another example, the execution subject of the embodiment of the present application is the first communication device, and the third-party application may be a second communication device that performs service interaction with the first communication device. This embodiment does not make specific limitations on this.

[0030] This embodiment fills the calling and called number information back into the first XDR information and then sends it to the third-party application, so that the embodiment of the present application can establish a link with the signaling monitoring system through Socket and receive the XDR output by the signaling monitoring system. It also uses Socket to establish a link with the third-party application backward and sends the processed XDR to the third-party application. As a result, when the signaling monitoring system receives relevant signaling that does not carry the calling and called user number information, it can backfill the calling and called number of the XDR of these business processes.

[0031] In the URL-based number backfilling method, the technical solution of the embodiment of the present application is to obtain the first XDR information corresponding to the current business process, and when the first XDR information does not carry the calling number information, determine the first target URL from the URL carried by the first XDR information, wherein the first target URL is the URL carried in the signaling of the current business process and the previous business process, and then query the calling number information associated with the first target URL from the preset memory database, and backfill the queried calling number information into the first XDR information. In the specific implementation, the first target URL can be used as a key to query the calling number information in the memory database. If the query is successful, the calling number information is taken out and placed in the first XDR information corresponding to the current business process to complete the XDR calling number backfilling of the current business process, thereby realizing the XDR calling number backfilling output by the 5G new call signaling monitoring system when receiving HTTP / 2 related signaling that does not carry the calling user number information, so that these business processes can identify which two users are triggered by the call of this XDR business, thereby effectively monitoring the key operating indicators of these business processes.

[0032] Based on the first embodiment of the present application, a second embodiment of the URL-based number backfilling method of the present application is proposed. Please refer to Figure 2 After the step of obtaining the first XDR information corresponding to the current service process, the method further includes: Step S40: When the first XDR information carries the calling and called number information, determine whether the second XDR information corresponding to the next service flow carries the calling and called number information; Step S50, when it is determined that the second XDR information does not carry the calling or called number information, determine a second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; Step S60: Associating the calling and called number information carried in the first XDR information with the second target URL to obtain first associated data, and storing the first associated data in the memory database.

[0033] The second XDR information refers to the XDR information corresponding to the next business process.

[0034] In this embodiment, the first XDR information carries the calling and called number information, indicating that the current business process carries the calling user number information and the called user number information in the signaling for business interaction. Therefore, the first XDR information carrying the calling and called number information can be directly sent to the third-party application. However, it should be noted that since the XDR information of the next business process (i.e., the second XDR information) may not carry the calling and called number information, the next business process cannot identify which two users triggered the XDR service due to the lack of the calling and called number information, and thus cannot effectively monitor the key operating indicators of these business processes. Based on this, the embodiment of the present application determines whether the second XDR information corresponding to the next business process carries the calling and called number information when the first XDR information carries the calling and called number information. When it is determined that the second XDR information does not carry the calling and called number information, the second target URL is determined from the URL carried by the first XDR information, wherein the second target URL is the URL carried jointly in the signaling of the current business process and the next business process, and then the calling and called number information carried in the first XDR information is associated with the second target URL to obtain the first associated data, and then the first associated data is stored in the memory database, so as to facilitate the next business process to accurately query the corresponding calling and called number information from the preset memory database according to the target URL in the signaling of the business interaction, and fill the queried calling and called number information back into the second XDR information, thereby completing the filling of the calling and called number of the XDR, and thus ensuring the effective monitoring of the key operating indicators of the business process.

[0035] To help with understanding, for example, since the 5G new call network is designed using the REST (Representational State Transfer) principle, this design principle regards the call information stored on each NF (Network Function) as a resource. The business interactions between the NFs of the 5G new call are actually operations on the resources on each NF. The core services of the 5G new call are all implemented around the different operations on the audio and video resources and audio and video derivative resources created on the VONR+ media plane NF, as well as the various call session resources created on the media capability platform NF. In combination with the 5G new call service specifications, it can be found that the service operation URLs between the NFs will basically appear in the HTTP / 2 signaling of the previous business process, which means that the two business processes can be linked through this URL. For the first service flow that carries the calling and called number information, if its signaling carries the URL of the subsequent second service flow (the second service flow is the next service flow of the first service flow) (i.e. the URL carried in the signaling of the second service flow and the first service flow), the first service flow uses the URL of the second service flow as the key, and the calling and called number information is saved as the value in the Key-Value memory database. If the subsequent signaling of the second service flow does not carry the calling and called number information, the second service flow uses the URL as the key to query the calling and called number information in the memory database. If the query is successful, the calling and called number information is retrieved and placed in the XDR of the second service flow, completing the filling of the XDR calling and called number of the second service flow. In particular, if the second business process also carries the URL of the third business process (the third business process is the next business process of the second business process) (that is, the URL carried in the signaling of the third business process and the second business process), then the second business process needs to use the URL of the third business process as the Key, and save the calling and called number information backfilled from the first business process as the Value in the memory database. In this way, the calling and called number information is gradually passed back to the process XDR that does not carry the calling and called number through the URL, thereby completing the filling of the calling and called number of these process XDRs.

[0036] It should be noted that although the above-mentioned specific embodiments show many details, they are only used to help understand the technical concepts or technical principles of the embodiments of the present application, and do not constitute a limitation on the present application. More simple transformations based on the technical concepts should all be within the scope of protection of the present application.

[0037] In a possible implementation manner, after the step of determining the first target URL from the URL carried in the first XDR information, the method further includes: Step B10, caching the first XDR information into a preset information cache area; The information buffer area is a buffer pool used to temporarily buffer XDR information.

[0038] Step B20, after the step of querying the calling and called number information associated with the first target URL from the preset memory database, the method further includes: Step B30: after receiving the query response result of the associated calling and called number information, extract the first XDR information from the information buffer area.

[0039] In this embodiment, if the first XDR information does not carry the calling and called number information, the business processing module of the execution subject of the embodiment of the present application will generate a query message, carry the URL (i.e., the first target URL) and send it to the data maintenance module, so that the data maintenance module queries the calling and called number information associated with the URL from the preset memory database (i.e., for the XDR that does not carry the calling and called number information, generate a query request message and send it to the data maintenance module to request to fill in the calling and called number information). Since it is necessary to wait for the query response message, it is necessary to send the first XDR information to the XDR cache module for caching, and after receiving the query response message (i.e., the above-mentioned query response result), the first XDR information is taken out from the information cache area, and the queried calling and called number information is filled back into the first XDR information, and then the first XDR information after filling in the calling and called number information is sent to the third-party application, so as to further ensure that the signaling monitoring system can effectively realize the backfilling of the calling and called number of the XDR of these business processes when receiving the relevant signaling that does not carry the calling and called user number information.

[0040] In a possible implementation, the method further includes: Step C10, counting the cumulative time from when the first XDR information is cached in the information cache area; Step C20: when the accumulated time reaches a preset time threshold and the query response result has not been received, extract the first XDR information from the information buffer area for transmission.

[0041] In this embodiment, the preset time threshold can be set by those skilled in the art according to actual conditions, and this embodiment does not make any specific limitation. For example, the preset time threshold can be 1.2 seconds or 3 seconds.

[0042] Exemplarily, after the step of extracting the first XDR information from the information buffer area, the method further includes: Step C30: sending the extracted first XDR information to a third-party application.

[0043] In this embodiment, it should be noted that before sending the extracted first XDR information to the third party, it can be encoded by TLV (Type Length Value) encoding or fixed structure encoding and then sent to the third-party application. That is, sending the extracted first XDR information to the third-party application should also include the protection scope of "encoding the extracted first XDR information and then sending it to the third-party application".

[0044] In order to avoid abnormal reasons such as abnormal network signal, slow response or crash of memory database instability, and data loss of memory database, which lead to the delay in receiving the query response result of the calling and called number information, that is, the calling and called number information associated with the first target URL cannot be queried from the preset memory database for a long time, so that the first XDR information is cached in the information cache area and cannot be sent to the third-party application, resulting in interruption of the business process, waste of resources and impact on upper-layer business analysis. Therefore, this embodiment counts the cumulative time from the time when the first XDR information is cached in the information cache area, and when the cumulative time reaches the preset time threshold and the query response result is still not received, the first XDR information is extracted from the information cache area and sent directly to the third-party application, so that when it is detected that the cached XDR has not been taken out after exceeding a certain threshold time, it is forced to be taken out and sent directly to the XDR sending module for sending, avoiding interruption of the business process, waste of resources and impact on upper-layer business analysis, so as to achieve continuous provision of normal and stable business service functions for users and improve the user's business experience.

[0045] Further, in order to help understand the technical principles of the embodiments of the present application, a specific embodiment 1 is listed, referring to Figure 3 , Figure 3 This is a schematic diagram of the structure of a URL-based number filling device according to an embodiment of the present application. The number filling device includes: The XDR receiving module establishes a link with the 5G new call signaling monitoring system, receives its output XDR, and then forwards it internally to the business processing module.

[0046] The business processing module determines whether the current XDR carries the calling and called number information. If the XDR carries the calling and called number information, and carries the URL of other subsequent business processes (i.e., the URL carried together), the business processing module generates a learning request message, carries the URL of the subsequent process and the calling and called number information, and sends it to the data maintenance module, and learns the relationship into the memory database (i.e., associates the calling and called number information carried in the first XDR information with the second target URL to obtain the first associated data, and stores the first associated data in the memory database). Since the XDR carries the calling and called number information, after sending the learning request message, the XDR is forwarded to the XDR sending module, and the processing is completed. If the XDR does not carry the calling and called number information, the business processing module generates a query message, carries the URL and sends it to the data maintenance module, so that the data maintenance module receives the query request message, queries the calling and called number information from the memory database, and generates a query response message and sends it to the business processing module (i.e., queries the calling and called number information associated with the first target URL from the preset memory database). It should be noted that since it is necessary to wait for the query response message, the current XDR needs to be sent to the XDR cache module for caching. After receiving the query response message, the XDR is taken out from the XDR cache module, the filled-in calling and called number information is filled in, and then sent to the XDR sending module to complete the processing.

[0047] The XDR cache module handles two types of requests from the business processing module: XDR cache requests and XDR requests to retrieve the cache. When an XDR cache request is received, the XDR cache is put into the cache pool (i.e., the information cache area mentioned above). When an XDR request to retrieve the cache is received, the cached XDR is retrieved from the cache pool and sent to the business processing module. In order to avoid the loss of the XDR request to retrieve the cache, which causes the XDR to be cached in the cache pool all the time, causing resource waste and affecting the upper-layer business analysis, the XDR cache module adds a mechanism to add a packet receiving timestamp to the XDR received in the cache. When the cache duration of the XDR exceeds a certain threshold time and is still not retrieved, it is forcibly retrieved and sent directly to the XDR sending module.

[0048] The data maintenance module is responsible for maintaining the memory database. When receiving a learning request message, it learns the calling and called numbers into the memory database; when receiving a query request message, it queries the calling and called number information from the memory database and generates a query response message to send to the business processing module.

[0049] The XDR sending module receives the XDR from the business processing module or the XDR buffer module, and then sends it back to the third-party application.

[0050] It should be noted that specific embodiment 1 is only used to help understand the technical concept of the embodiment of the present application, and does not constitute a limitation on the URL-based number backfilling device of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0051] In a possible implementation manner, after the step of backfilling the queried calling and called number information into the first XDR information, the method includes: Step D10, determining whether the second XDR information corresponding to the next service flow carries the calling and called number information; Step D20, when it is determined that the second XDR information does not carry the calling or called number information, determine the second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; Step D30, associating the queried calling and called number information with the second target URL to obtain second associated data, and storing the second associated data in the memory database.

[0052] In this embodiment, since the XDR information of the next business process (i.e., the second XDR information) may not carry the calling and called number information, the next business process cannot identify which two users triggered the XDR service due to the lack of the calling and called number information, and thus cannot effectively monitor the key operating indicators of the business process. Based on this, the embodiment of the present application determines the second target URL from the URL carried by the first XDR information when it is determined that the second XDR information does not carry the calling or called number information, wherein the second target URL is the URL carried jointly in the signaling of the current business process and the next business process, and associates the queried calling or called number information with the second target URL to obtain second associated data, and then stores the second associated data in the memory database, thereby facilitating the next business process to accurately query the corresponding calling or called number information from the memory database according to the target URL in the business interaction signaling, and fill the queried calling or called number information back into the second XDR information, thereby completing the filling of the calling or called number of the XDR, and further ensuring the effective monitoring of the key operating indicators of the business process, and through real-time monitoring of the key operating indicators of the data business, early warning can be used to eliminate network risks, sudden failures can be quickly demarcated and located, and the user experience perception can be improved.

[0053] In order to further help understand the technical concept or technical principle of the embodiment of the present application, a specific embodiment 2 is listed to illustrate the specific business application scenario of the URL-based number backfilling method of the embodiment of the present application. The business application scenario includes but is not limited to the call control process of the 5G new call core network (refer to Figure 5 and Figure 6 )、Media stream replication control process (refer to Figure 8 )、Playback control process (refer to Fig. 9 )、Number collection control process (refer to Fig.10 ), media element synthesis control process (refer to Fig.11 )、Intelligent translation control process (refer to Fig.12 )、Interesting call control process (refer to Fig.13 ) and DC data interaction control process (refer to Fig.14 ), the following will describe these exemplary business application scenarios in detail with reference to the accompanying drawings: In order to realize the backfilling of the calling and called numbers in the XDR output by the signaling monitoring system when the 5G new call signaling monitoring system receives HTTP / 2 related signaling that does not carry the calling and called user number information. This embodiment proposes an algorithm for how to implement the backfilling of the calling and called numbers in the business processes of interface 3, interface 5, interface 7, interface 8, interface 9 and interface 17. This algorithm solution is not limited to the above interfaces. This method can be used for the XDR number filling problem generated by the use of HTTP / 2 for business exchange. The following is a detailed description of the number backfilling implemented by the number backfilling device of this embodiment in conjunction with the accompanying drawings: The 5G new call network architecture is as follows Figure 4 As shown, the HTTP / 2 related interface description is shown in the following table (I): (one) Among them, the service operation signaling sent by the service AS (Application Server) of interface 9 will be forwarded to the VoLTE (Voice over LTE, 4G voice solution) AS through interface 3 via the VONR+ (Enhanced Voice over NR, 5G+ voice solution) capability network element or forwarded to the VONR+ media plane through interface 5; the interface 3 VoLTE AS notification signaling will be forwarded to the service AS through interface 9 via the VONR+ capability network element, and the interface 5 VONR+ media plane notification signaling will be forwarded to the service AS through interface 9 via the VONR+ capability network element. This means that interface 9 has the same service process as interface 3 or interface 5.

[0054] Furthermore, specific scenario examples of XDR learning or backfilling in each process in interface 3, interface 5, interface 7, interface 8, interface 9, and interface 17 are described below respectively: 1. Call control flow in interface 3 and interface 9 There are three processes related to call control between interface 3 and interface 9, namely, call event notification process, call event control process and call control result notification process. The order of triggering each process is as follows: Figure 5 As shown, including: S101: When the VoLTE AS receives a call event subscribed by the calling user, it carries the session resource {VoLTEAS_callUrl} and the calling and called numbers on the VoLTE AS, and initiates a notification to the VONR+ capability network element to inform the type of the current call event. {VoLTEAS_callUrl} represents the call resource link on the VoLTE AS. The VONR+ capability network element can access the call through this link and actively access / control the call resources.

[0055] S102 (optional): When the service AS subscribes to the corresponding call event type, the VONR+ capability network element forwards the request to the service AS.

[0056] S103 (optional): The service AS returns a response message to the VONR+ capability network element.

[0057] S104: The VONR+ capability network element returns a response message to the VoLTE AS.

[0058] The call event notification process carries {VoLTEAS_callUrl} used by the call event control process, and also carries the calling and called number information. Therefore, it is necessary to generate a learning request message to the data maintenance module to learn {VoLTEAS_callUrl} and the calling and called number information into the memory database.

[0059] S105 (optional): The service AS determines that call control is required based on the reported call event, and initiates a call event control request to the VoLTE AS through the VONR+ capability network element. The request URL is {VoLTEAS_callUrl} / call-control, where {VoLTEAS_callUrl} is the call resource identifier of the operation, and call-control indicates that the operation taken on the resource is call control. The specific control action type will be carried in the message body, usually with audio and video anchoring actions, instructing VoLTEAS to create and anchor audio and video resources on the VONR+ media plane, and DC (Data Channel) creation actions to create DC resources on the VONR+ media plane. At the same time, the request signaling will carry {callbackUrl1}, which is used for VoLTE AS to notify the service AS of the result after completing the call control, and when creating the DC action, it will also carry {DC_appUrl} for the service AS to receive DC data sent by the VONR+ media plane.

[0060] S106: Forward the call control request sent by the service AS, or the VONR+ capability network element determines that call control is required based on the reported call event received. Different from the S105 process, if the call control is triggered by the VONR+ capability network element itself, {callbackUrl1} and {DC_appUrl} are provided by the VONR+ capability network element.

[0061] S107: The VoLTE AS returns a response message to the VONR+ capability network element.

[0062] S108 (optional): The VONR+ capability network element returns a response message to the service AS.

[0063] The call event control process does not carry the calling or called number information in the request or response signaling, so the XDR cannot fill in the calling or called number, and the calling or called number needs to be filled in. The steps of the call record in the business processing module are as follows Figure 6As shown, S201, the business processing module uses {VoLTEAS_callUrl} in the request URL as the Key (the first target URL, which will not be repeated below), generates a query request message and sends it to the data maintenance module to fill in the calling and called numbers; S202, while waiting for the query response, the XDR of the process is sent to the XDR cache module for caching. S203 When the business processing module receives the query response, S204, the business processing module takes out the XDR from the XDR cache module and writes the backfilled calling and called numbers into the XDR. After backfilling the calling and called numbers, S205 generates a learning request message and sends it to the data maintenance module to learn {callbackUrl1} and the calling and called number information into the memory database; if it is a DC action to create, S206 generates a learning request message and sends it to the data maintenance module to learn {DC_appUrl} and the calling and called number information into the memory database.

[0064] S109: If the call control instruction sent by the service AS is audio and video anchoring or DC creation, the VoLTE AS will initiate a media resource creation or update request, requesting the creation of audio and video resources and DC resources on the VONR+ media plane. When DC resources are created, the VoLTE AS needs to tell the VONR+ media plane the {DC_appUrl} for receiving DC data provided by the service AS or the VONR+ capability network element.

[0065] S110: After the VONR+ media plane completes the creation of audio and video resources or DC resources, it returns the audio and video resources {streamUrl} and {DC_dataUrl} of the DC data received by the VONR+ media plane to the VoLTE AS.

[0066] S111: After the VoLTE AS completes the specified action, it initiates a call control result notification request with the request Url being {callbackUrl1}, notifying the VONR+ capability network element of the control result. If the indicated action is successfully completed, for audio and video anchoring actions, the audio and video resources {streamUrl} created on the VONR+ media plane will be carried in the message body, and for DC creation actions, the {DC_dataUrl} for receiving DC data created on the VONR+ media plane will be carried in the message body.

[0067] S112 (optional): The VONR+ capability network element forwards the control result to the service AS.

[0068] S113 (optional): The service AS returns a response message to the VONR+ capability network element.

[0069] S114: The VONR+ capability network element returns a response message to the VoLTE AS.

[0070] The call control result notification request or response signaling does not carry the calling and called number information, so the XDR cannot fill in the calling and called number. It is necessary to backfill the calling and called number. Use the request URL {callbackUrl1} as the key to generate a query request message and send it to the data maintenance module to backfill the calling and called number. While waiting for the query response, the XDR of this process should be sent to the XDR cache module for caching. When the query response is received, the XDR is taken out from the XDR cache module, and the backfilled calling and called numbers are written into the XDR. Since there are business operations on audio and video resources or DC resources on the VONR+ media plane on subsequent interfaces 5, 9, 7, and 17, it is necessary to generate learning request messages respectively and send {streamUrl} and the calling and called number information, {DC_dataUrl} and the calling and called number information to the data maintenance module, and learn to enter the memory database.

[0071] The new 5G call service can only be carried out after the audio and video are re-anchored to the VONR+ media plane and the DC channel is established. The following service control processes of interface 5 and interface 9, and all service processes of interface 7, interface 8 and interface 17 are triggered after the audio and video are re-anchored to the VONR+ media plane and the DC channel is established.

[0072] 2. Business Control Flow in Interface 5 and Interface 9 The service control related process signaling in interface 5 and interface 9 does not carry the calling and called number information. After the VONR+ media plane completes the creation of audio and video resources, the service AS obtains the {streamUrl} of the audio and video resources through interface 9, and can perform various service operations on the audio and video resources according to the service selected by the user. The issuance of these service operation instructions is first forwarded through interface 9 through the VONR+ capability network element and then issued to the VONR+ media plane through interface 5, such as Figure 7 The request URL format of most business operations is {streamUrl} / operation type. These business operation request URLs are shown in the following table (II).

[0073] (two) After receiving the XDR of these processes, take out {streamUrl} in the request URL as the key, generate a query request message and send it to the data maintenance module to fill in the calling and called numbers. While waiting for the query response, the XDR of these processes should be sent to the XDR cache module for caching (there is a caching process during the business process XDR filling in the calling and called numbers, which will not be repeated below). After receiving the query response, take out the XDR from the XDR cache module and write the filled in calling and called numbers into the XDR.

[0074] Some business control processes carry URLs of other processes. Therefore, after backfilling the calling and called numbers, it is necessary to generate a learning request message to learn the relevant URL (second target URL) and the calling and called number information into the memory database.

[0075] like Figure 8 As shown, the S405-S406 media stream duplication application will carry two URLs, {duplication_url} and {controlUrl}, in the response signaling, where {duplication_url} represents the duplication resource link created on the VONR+ media plane, and {controlUrl} represents the media stream duplication receiving end control resource URL created on the media capability platform. After the media stream duplication application process uses {streamUrl} to fill in the calling and called numbers, it is necessary to generate a learning request message to send {duplication_url} and the calling and called number information, and {controlUrl} and the calling and called number information to the data maintenance module, and the learning is entered into the memory database.

[0076] When the service AS needs to stop media stream duplication, S409-S410 uses {duplication_url} as the request URL (i.e. the URL carried together, which will not be described in detail below) to initiate a media stream duplication stop request to the VONR+ media plane via the VONR+ capability network element. After receiving the media stream duplication stop process XDR, the request URL is directly used as the key to generate a query request message and send it to the data maintenance module to fill in the calling and called number information.

[0077] like Fig. 9 As shown, the S501-S502 playback request will carry the playback result notification URL {callbackUrl2} in the request signaling. After the playback request process uses {streamUrl} to fill back the calling and called numbers, it is necessary to generate a learning request message to send {callbackUrl2} and the calling and called number information to the data maintenance module, and the learning is entered into the memory database.

[0078] S505-S506 When the VONR+ media interface completes the playback, {callbackUrl2} is used as the request URL to notify the service AS of the playback result through the VONR+ capability network element. After receiving the playback result notification process XDR, the request URL is directly used as the key to generate a query request message and send it to the data maintenance module to fill in the calling and called number information.

[0079] like Fig.10As shown, the S601-S602 number collection request will carry the number collection result notification URL {dtmfCollectCallbackUrl} in the request signaling, and the S603-S604 response signaling will carry the number collection resource URL {dtmfCollect_url} created on the VONR+ media plane. After the number collection request process uses {streamUrl} to fill in the calling and called numbers, it is necessary to generate a learning request message to send {dtmfCollectCallbackUrl} and the calling and called number information, and {dtmfCollect_url} and the calling and called number information to the data maintenance module, and the learning is entered into the memory database.

[0080] S605-S606 When VONR+ media interface completes the number collection, {dtmfCollectCallbackUrl} is used as the request URL, and the VONR+ capability network element notifies the service AS of the number collection result. After receiving the number collection result notification process XDR, directly use the request URL as the key to generate a query request message and send it to the data maintenance module to fill in the calling and called number information.

[0081] S609-S610 When the service AS needs to stop collecting numbers, use {dtmfCollect_url} as the request URL and initiate a collection stop request to the VONR+ media plane via the VONR+ capability network element. After receiving the collection stop process XDR, directly use the request URL as the key to generate a query request message and send it to the data maintenance module to fill in the calling and called number information.

[0082] like Fig.11 As shown, the S703-S704 media element synthesis application will carry the media element synthesis resource URL {videoCompositionUrl} created on the VONR+ media plane in the response signaling. After the media element synthesis request process uses {streamUrl} to fill in the calling and called numbers, it is necessary to generate a learning request message to send {videoCompositionUrl} and the calling and called number information to the data maintenance module, and the learning is entered into the memory database.

[0083] S705-S706 When the service AS needs to stop media element synthesis, use {videoCompositionUrl} as the request URL and initiate a media element synthesis stop request to the VONR+ media plane via the VONR+ capability network element. After receiving the media element synthesis stop process XDR, directly use the request URL as the key to generate a query request message and send it to the data maintenance module to fill in the calling and called number information.

[0084] like Fig.12As shown, the S909-S910 subtitle stream synthesis application will carry the subtitle stream receiving resource URL {receiveUrl} created on the VONR+ media plane in the response signaling. After the subtitle stream synthesis application process uses {streamUrl} to fill in the calling and called numbers, it is necessary to generate a learning request message to send {receiveUrl} and the calling and called number information to the data maintenance module, and the learning enters the memory database.

[0085] 3. Business Control Flow of Interface 7 The HTTP / 2 signaling of this interface does not carry the calling and called number information. This interface mainly completes the control of audio and video media stream resource replication and the notification of intelligent translation results.

[0086] For push media copy process, such as Figure 8 As shown, the S403 request URL {mcpUrl} is a non-session-level URL and does not indicate a specific call resource. Therefore, the calling and called numbers cannot be filled in through the request URL. However, the S404 push media replication process response signaling will carry two URLs: {callbackUrl3} and {controlUrl}, where {callbackUrl3} is the media stream replication receiving end resource URL created on the media capability platform, and {controlUrl} is the media stream replication receiving end control resource URL created on the media capability platform. {controlUrl} will be transmitted to the VONR+ capability network element through the S405 media stream replication application response signaling of interface 5, and the VONR+ capability network element will transmit it to the service AS through interface 9 S406. As can be seen from the above, after the media stream replication application process of interface 5 and interface 9 is filled in to the calling and called numbers through {streamUrl}, {controlUrl} and the calling and called number information will be learned into the memory database. Therefore, for the push media replication process of interface 7, the XDR of the process is received, and {controlUrl} is used as the key to fill in the calling and called number information. After the calling and called number information is filled back, a learning request message is generated and {callbackUrl3} and the calling and called number information are sent to the data maintenance module, and the learning is entered into the memory database.

[0087] For the media stream replication update S407-S408 and media stream replication stop S411-S412 of interface 7, the VONR+ media interface will use {callbackUrl3} as the request URL to send a media stream replication control update or stop request to the media capability platform. When receiving the XDR of these two processes, it will directly use the request URL as the Key to generate a query request message and send it to the data maintenance module to fill in the calling and called numbers.

[0088] For the intelligent translation result notification process under the interface 7 video solution, such as Fig.12 As shown, S913 has a request URL {notifyUrl1} / translationResult, {notifyUrl1} is the receiving resource URL for receiving the translation result on the VONR+ media plane, and this URL is the {receiveUrl} carried in the response signaling of the subtitle stream synthesis application process of interface 5 S909 and interface 9 S910. As mentioned above, after the subtitle stream synthesis request process of interface 5 and interface 9 is backfilled to the called number through {streamUrl}, {receiveUrl} and the called number information will be learned into the memory database. Therefore, for the intelligent translation result notification process under the interface 7 video solution, after receiving the XDR of the process, {notifyUrl1} can be used as the key to backfill the called number information.

[0089] For the intelligent translation result notification process under the interface 7 DC solution, such as Fig.12 As shown, the request URL of S915 is {notifyUrl1} / send, where {notifyUrl1} is the URL of the receiving resource for receiving the translation result on the VONR+ media plane. This URL is the attached URL under the DC solution. Figure 5 , {DC_dataUrl} is carried in the call control result notification process request signaling of S111 in interface 3 and S112 in interface 9. As mentioned above, after the call control result notification process of interface 3 and interface 9 fills back the called number through {callbackUrl1}, {DC_dataUrl} and the called number information will be learned into the memory database. Therefore, for the intelligent translation result notification process under the DC solution of interface 7, after receiving the XDR of the process, {notifyUrl1} can be used as the key to fill back the called number information.

[0090] 4. Business control process of interface 8 The signaling of this interface also does not carry the calling and called number information. This interface is mainly used for business command and result interaction.

[0091] For the interface 8 intelligent translation control process, see the attached Fig.12, the S911 request URL is {callbackUrl4} / translationcontrol. As a sub-process of the entire 5G new call intelligent translation service, this process needs to trigger the S901-S906 media stream replication process of interface 9, interface 5 and interface 7 to copy the voice stream to the media capability platform before triggering the intelligent translation control process of interface 8. The response signaling of the media stream replication process carries the media capability platform to copy the receiving end control resource URL {controlUrl} and finally passes it to the service AS. This URL is the {callbackUrl4} in the request URL. The translation result of the media capability platform needs to be transmitted to the VONR+ media plane through the {notifyUrl1} carried by the request signaling. For the intelligent translation service implemented under the video solution, {notifyUrl1} is the {reciverUrl} carried in the response signaling of the subtitle stream synthesis process 909-S910; for the intelligent translation service implemented under the DC solution, {notifyUrl1} is the attached Figure 5 {DC_dataUrl} carried in the S111-S112 call control result notification process in interface 3 and interface 9.

[0092] As can be seen from the above, the media stream copy application process of interface 9 and interface 5 will learn {controlUrl} and the called number information into the memory database after filling {streamUrl} back to the called number. The subtitle stream synthesis request process of interface 9 and interface 5 will learn {reciverUrl} and the called number information into the memory database after filling {streamUrl} back to the called number. The call control result notification process in interface 3 and interface 9 will learn {DC_dataUrl} and the called number information into the memory database after filling {callbackUrl1} back to the called number.

[0093] After receiving the intelligent translation control process XDR, this embodiment can use either {callbackUrl4} or {notifyUrl1} as the key to fill in the calling and called number information. In addition, the intelligent translation control process request signaling will carry the fault notification URL {faultNotifyUrl1}. After the intelligent translation control process fills in the calling and called number through {callbackUrl4} or {notifyUrl1}, {faultNotifyUrl1} and the calling and called number information need to be learned into the memory database.

[0094] For the interface 8 interesting call control process, see the attached Fig.13, S1007 request URL is {callbackUrl5} / interestingcallcontrol. As a sub-process of the entire 5G new call interesting call service, before triggering the interesting call control process of interface 8, it is necessary to trigger the S1001-S1006 media stream replication related processes of interface 9, interface 5 and interface 7 to copy the audio and video media streams to the media capability platform. The response signaling of the media stream replication process carries the media capability platform media stream replication receiving end control resource URL {controlUrl} and is finally passed to the service AS. This URL is {callbackUrl5} in the request URL.

[0095] As can be seen from the above, the interface 9 and interface 5 media stream replication application process, after filling in the called number with {streamUrl}, will learn {controlUrl} and the called number information into the memory database. After receiving the interesting call control process XDR, this embodiment uses {callbackUrl5} as the key to fill in the called number information. In addition, the interesting call control process request signaling will carry the fault notification URL {faultNotifyUrl2} and the interesting call identification result notification URL {notifyUrl3}. When the interesting call control process fills in the called number information through {callbackUrl5}, it is necessary to learn {faultNotifyUrl2} and the called number information, and {notifyUrl3} and the called number information into the memory database respectively.

[0096] For the attached Fig.13 , Interface 8 Interesting call identification result notification process, S1009 request URL is {notifyUrl3} / interestingcallResult. After receiving the interesting call identification result notification process XDR, this embodiment uses {notifyUrl3} as the Key to fill in the calling and called number information.

[0097] For the attached Fig.12 , S917 and attached Fig.13, S1011 fault notification process, its request URLs are {faultNotifyUrl1} / faultNotify and {faultNotifyUrl2} / faultNotify, {faultNotifyUrl1} is the {faultNotifyUrl1} carried by the intelligent translation control request signaling, and {faultNotifyUrl2} is the {faultNotifyUrl2} carried by the fun call control request signaling. After receiving the fault notification process XDR, this embodiment uses {faultNotifyUrl1} or {faultNotifyUrl2} as the key to fill in the calling and called number information.

[0098] 5. DC data interaction process between interface 5 and interface 17 The process used to transmit DC data between VONR+ capability network element and VONR+ media plane in interface 5 also does not carry the calling and called number information. The entire interface 17 is used to transmit DC data between service AS and VONR+ media plane, and the signaling of this interface also does not carry the calling and called number information.

[0099] Reference Fig.14 When the service AS / VONR+ capability network element needs to send a DC message to the user terminal through the VONR+ media plane, it constructs an HTTP / 2 request signaling, where the S1101 request URL is the DC receiving resource URL {DC_dataUrl} created on the VONR+ media plane. As mentioned above, after the call control result notification process in interface 3 and interface 9 fills {callbackUrl1} back to the called number and the called number, {DC_dataUrl} and the called number information will be learned into the memory database.

[0100] When the user terminal needs to send a DC message to the service AS / VONR+ capability network element through the VONR+ media plane, it constructs an HTTP / 2 request signaling, in which the S1103 request URL is the DC receiving resource URL {DC_appUrl} on the service AS / VONR+ capability network element. As mentioned above, after the call control process in interface 3 and interface 9 fills in the calling and called numbers with {VoLTEAS_callUrl}, it will learn {DC_appUrl} and the calling and called number information into the memory database.

[0101] Therefore, for the XDR output by the DC data interaction process of interface 5 and interface 17, whether the service AS / VONR+ capability network element sends DC data to the terminal or the user terminal sends DC data to the service AS / VONR+ capability network element, when the XDR is received, this embodiment uses the request URL as the Key to fill in the calling and called number information.

[0102] It should be noted that what is disclosed above are only several specific implementation scenarios of the number backfilling method of the embodiment of the present application. Of course, this cannot be used to limit the protection scope of the present application. Ordinary technicians in this field can understand that all or part of the processes of the above embodiments and the equivalent changes made in accordance with the claims of the present invention are still within the scope covered by the present application.

[0103] That is to say, the above-mentioned specific embodiment 2 is only used to help understand the technical concept or technical principle of the embodiment of the present application, and does not constitute a limitation of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0104] In addition, the embodiment of the present application also proposes a URL-based number backfilling device, referring to Fig.15 , Fig.15 This is a functional module diagram of an embodiment of a URL-based number backfilling device of the present application.

[0105] In this embodiment, the URL-based number backfilling device includes: An XDR receiving module 10 is configured to obtain first XDR information corresponding to a current business process; The business processing module 20 is configured to determine a first target URL from the URL carried by the first XDR information when the first XDR information does not carry the calling or called number information, wherein the first target URL is a URL carried jointly in the signaling of the current business process and the previous business process; query the calling or called number information associated with the first target URL from a preset memory database, and fill the queried calling or called number information back into the first XDR information.

[0106] In some embodiments, the service processing module 20 is further configured to: In the case where the first XDR information carries the calling number and the called number information, determining whether the second XDR information corresponding to the next service flow carries the calling number and the called number information; When it is determined that the second XDR information does not carry the calling or called number information, determine the second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; The URL-based number backfilling device also includes a data maintenance module 30, which is configured to: associate the calling and called number information carried in the first XDR information with the second target URL to obtain first associated data, and store the first associated data in the memory database.

[0107] In some embodiments, the URL-based number backfilling device further includes an XDR cache module 40, and the XDR cache module 40 is configured to: Cache the first XDR information into a preset information cache area; After the step of querying the calling and called number information associated with the first target URL from the preset memory database, the service processing module 20 is further configured to: After receiving the query response result of the associated calling and called number information, the first XDR information is extracted from the information buffer area.

[0108] In some embodiments, the XDR cache module 40 is further configured to: The accumulated time from when the first XDR information is cached in the information cache area is counted, and when the accumulated time reaches a preset time threshold and the query response result has not been received, the first XDR information is extracted from the information cache area and sent to the XDR sending module 50 for transmission.

[0109] The URL-based number backfilling device further includes an XDR sending module 50, which is configured to: The extracted first XDR information is sent to a third-party application.

[0110] In some embodiments, the service processing module 20 is further configured to: Determine whether the second XDR information corresponding to the next service process carries the calling and called number information; When it is determined that the second XDR information does not carry the calling or called number information, determine the second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; The data maintenance module 30 is further configured to: The queried calling and called number information is associated with the second target URL to obtain second associated data, and the second associated data is stored in the memory database.

[0111] After the step of filling the queried calling and called number information back into the first XDR information, the XDR sending module 50 is further configured to: The first XDR information after backfilling the calling and called number information is sent to the third-party application.

[0112] The URL-based number backfilling device provided in this embodiment and the URL-based number backfilling method provided in the above-mentioned embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be found in the embodiment of the above-mentioned URL-based number backfilling method. This embodiment has the same beneficial effects as the embodiments of the URL-based number backfilling method, which will not be repeated here.

[0113] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0114] In addition, the embodiment of the present application also provides a URL-based number backfill device, referring to Fig.16 , Fig.16 A hardware structure diagram of a URL-based number backfill device provided in an embodiment of the present application. Fig.16 As shown, the URL-based number backfill device may include: a processor 1001, a communication bus 1002, a user interface 1003, a network interface 1004 and a memory 1005. Among them, the processor 1001 may be a central processing unit (CPU). The communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a wireless fidelity (WIreless-FIdelity, WI-FI) interface). The memory 1005 may be a high-speed random access memory (Random Access Memory, RAM), or a stable non-volatile memory (Non-Volatile Memory, NVM), such as a disk storage. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0115] Those skilled in the art will understand that Fig.16 The structure shown in the figure does not constitute a limitation on the URL-based number backfilling device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. Fig.16 As shown, the memory 1005 as a storage medium may include an operating system, a data storage module, a network communication module, a user interface module, and a URL-based number backfill program.

[0116] exist Fig.16 In the URL-based number backfill device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in this embodiment can be set in the communication device, and the communication device calls the URL-based number backfill program stored in the memory 1005 through the processor 1001, and executes the URL-based number backfill method provided in any of the above embodiments.

[0117] The device proposed in this embodiment and the URL-based number backfilling method proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be referred to any of the above embodiments, and this embodiment has the same beneficial effects as executing the URL-based number backfilling method.

[0118] In addition, an embodiment of the present application also proposes a storage medium, which is a computer-readable storage medium, and the computer-readable storage medium can be a non-volatile computer-readable storage medium. A URL-based number backfill program is stored on the computer-readable storage medium, and when the URL-based number backfill program is executed by the processor, the URL-based number backfill method of the present application as described above is implemented.

[0119] The various embodiments of the URL-based number backfilling device and computer-readable storage medium of the present application can all refer to the various embodiments of the URL-based number backfilling method of the present application, which will not be repeated here.

[0120] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

[0121] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0122] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for enabling a URL-based number backfilling device to execute the methods described in each embodiment of the present application.

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

Claims

1. A method for backfilling numbers based on URL, characterized in that: include: Obtain the first XDR information corresponding to the current business process; In the case that the first XDR information does not carry the calling or called number information, determining a first target URL from the URL carried in the first XDR information, wherein the first target URL is a URL carried in both the signaling of the current service process and the signaling of the previous service process; The calling and called number information associated with the first target URL is queried from a preset memory database, and the queried calling and called number information is filled back into the first XDR information.

2. The URL-based number backfilling method according to claim 1, characterized in that: After the step of acquiring the first XDR information corresponding to the current service process, the method further includes: In the case where the first XDR information carries the calling number and the called number information, determining whether the second XDR information corresponding to the next service flow carries the calling number and the called number information; When it is determined that the second XDR information does not carry the calling or called number information, determine the second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; The calling and called number information carried in the first XDR information is associated with the second target URL to obtain first associated data, and the first associated data is stored in the memory database.

3. The URL-based number backfilling method according to claim 1, characterized in that: After the step of determining the first target URL from the URL carried in the first XDR information, the method further includes: Cache the first XDR information into a preset information cache area; After the step of querying the calling and called number information associated with the first target URL from the preset memory database, the method further includes: After receiving the query response result of the associated calling and called number information, the first XDR information is extracted from the information buffer area.

4. The URL-based number backfilling method according to claim 3, characterized in that: The method further comprises: Counting the cumulative time from when the first XDR information is cached in the information cache area; When the accumulated time reaches a preset time threshold and the query response result has not been received, the first XDR information is extracted from the information buffer area for transmission.

5. The URL-based number backfilling method according to claim 4, characterized in that: After the step of extracting the first XDR information from the information buffer area, the method further includes: The extracted first XDR information is sent to a third-party application.

6. The URL-based number backfilling method according to claim 1, characterized in that: After the step of backfilling the queried calling and called number information into the first XDR information, the method includes: Determine whether the second XDR information corresponding to the next service process carries the calling and called number information; When it is determined that the second XDR information does not carry the calling or called number information, determine the second target URL from the URL carried in the first XDR information, wherein the second target URL is a URL carried in both the signaling of the current service flow and the next service flow; The queried calling and called number information is associated with the second target URL to obtain second associated data, and the second associated data is stored in the memory database.

7. The URL-based number backfilling method according to any one of claims 1 to 6, characterized in that: After the step of backfilling the queried calling and called number information into the first XDR information, the method further includes: The first XDR information after backfilling the calling and called number information is pre-processed and then sent to the third-party application.

8. A URL-based number backfilling device, characterized in that: include: An XDR receiving module, configured to obtain first XDR information corresponding to a current business process; a service processing module, configured to determine a first target URL from a URL carried in the first XDR information when the first XDR information does not carry the calling and called number information, wherein the first target URL is a URL carried in both the signaling of the current service process and the signaling of the previous service process; The calling and called number information associated with the first target URL is queried from a preset memory database, and the queried calling and called number information is filled back into the first XDR information.

9. A URL-based number backfill device, characterized in that: include: A memory, a processor, and a URL-based number backfilling program stored in the memory and executable on the processor, wherein the URL-based number backfilling program, when executed by the processor, implements the URL-based number backfilling method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, on which a URL-based number backfill program is stored. When the URL-based number backfill program is executed by a processor, the URL-based number backfill method according to any one of claims 1 to 7 is implemented.

Images