CN117768577A - Outbound task processing method and device, storage medium and electronic equipment - Google Patents

Abstract

The invention discloses an outbound task processing method, an outbound task processing device, a storage medium and electronic equipment. The method relates to the field of wireless communication and terminals, and comprises the following steps: responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the target outbound task is failed to initiate; determining at least two extensions based on the extension registration information under the condition that the extension registration verification passes based on the extension registration information; calling a target server to carry out extension bridging on at least two extensions, simulating a call environment between an outbound initiating terminal and an outbound receiving terminal, and obtaining target voice streams after extension bridging; and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault. The invention solves the technical problems of low outbound efficiency and extravagant outbound resources caused by the fact that the silent reason of the outbound task after being connected cannot be accurately identified in the related technology.

Description

Outbound task processing method and device, storage medium and electronic equipment

Technical Field

The invention relates to the field of wireless communication and terminals, in particular to an outbound task processing method, an outbound task processing device, a storage medium and electronic equipment.

Background

In the outbound service, the phenomenon of silence after the outbound is connected sometimes occurs, which may be caused by network delay, hardware fault, extension registration failure, background configuration and other reasons, and the method is difficult to quickly locate to specific reasons, and the traditional method needs to manually grasp packets and manually check corresponding application, port, log and other information, so that not only is a great deal of outbound data wasted, but also service efficiency and customer experience are seriously affected, and even further customer complaints may be caused, so that an efficient and real-time method for detecting and locating the problems is still lacking.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the invention provides an outbound task processing method, an outbound task processing device, a storage medium and electronic equipment, which at least solve the technical problems of low outbound efficiency and extravagant outbound resources caused by incapability of accurately identifying silent reasons after an outbound task is connected in the related technology.

According to an aspect of the embodiment of the present invention, there is provided an outbound task processing method, including: responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator; determining at least two extensions based on the extension registration information under the condition that the extension registration verification is passed based on the extension registration information; calling the target server to carry out extension bridging on the at least two extensions, simulating a call environment between the outbound initiating terminal and the outbound receiving terminal, and acquiring a target voice stream after extension bridging; judging whether the target voice stream is a mute voice stream or not; and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault.

According to another aspect of the embodiment of the present invention, there is also provided an outbound task processing device, including: the response module is used for responding to a target outbound task initiated by an outbound initiating terminal, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiating terminal; a first determining module, configured to determine at least two extensions based on the extension registration information when the extension registration verification is passed based on the extension registration information; the calling module is used for calling the target server to carry out extension bridging on the at least two extensions, simulating a call environment between the outbound initiating terminal and the outbound receiving terminal, and acquiring a target voice stream after extension bridging; the judging module is used for judging whether the target voice stream is a mute voice stream or not; and the second determining module is used for determining that the audio file corresponding to the target outbound task has a fault under the condition that the target voice stream is not the mute voice stream.

According to another aspect of the embodiments of the present invention, there is also provided a nonvolatile storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform any one of the outbound task processing methods.

According to another aspect of the embodiment of the present invention, there is also provided an electronic device including one or more processors and a memory for storing one or more programs, where the one or more programs, when executed by the one or more processors, cause the one or more processors to implement any one of the outbound task processing methods.

In the embodiment of the invention, a target outbound task initiated by an outbound initiating terminal is responded, and when the initiation of the target outbound task fails, extension registration information corresponding to the target outbound task is acquired through a target server, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiating terminal; determining at least two extensions based on the extension registration information under the condition that the extension registration verification is passed based on the extension registration information; calling the target server to carry out extension bridging on the at least two extensions, simulating a call environment between the outbound initiating terminal and the outbound receiving terminal, and acquiring a target voice stream after extension bridging; judging whether the target voice stream is a mute voice stream or not; under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault, and achieving the purposes of sequentially carrying out extension registration verification, mute voice stream identification based on outbound task simulation and audio file fault identification, accurately and comprehensively identifying outbound silence reasons, thereby improving the accuracy of identifying the outbound task silence reasons, further improving outbound efficiency, saving the technical effect of outbound resources, and further solving the technical problems of low outbound efficiency and extravagant outbound resources caused by incapability of accurately identifying the silence reasons after the outbound task is connected in the related technology.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiments of the invention and together with the description serve to explain the invention and do not constitute a limitation on the invention. In the drawings:

fig. 1 is a schematic diagram of an outbound task processing method according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of an alternative outbound task processing method according to an embodiment of the invention;

FIG. 3 is a schematic diagram of another alternative outbound task processing method according to an embodiment of the invention;

fig. 4 is a schematic diagram of an outbound task processing device according to an embodiment of the present invention.

Detailed Description

In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

First, in order to facilitate understanding of the embodiments of the present invention, some terms or nouns referred to in the present invention will be explained below:

kafka (Apache Kafka, kafka) is a distributed stream processing platform for high reliability, high throughput processing of large-scale real-time data streams. It provides a publish-subscribe model for communicating and processing data between multiple applications or systems. Kafka is used for processing real-time data flow, and can perform message publishing and subscribing in a distributed environment, so that high-performance and high-reliability data transmission is realized.

ESL (Event Socket Library ), an open source communication library for communicating with FreeWITCH. The ESL provides an application program interface that interacts with FreeSWITCH, which can interact with commands and events over a network connection. The ESL is used for communicating with FreeWITCH, sending commands and receiving events, and realizing control and monitoring of the FreeWITCH.

FreeSWITCH, an open source telephone exchange and a soft switching platform (i.e., server) provide real-time communication capabilities for voice, video, messaging and data. It can be used to construct a variety of communication applications such as IP telephony, voice conferencing, call centers, etc. FreeSWITCH is used to implement real-time communications, support the transmission and processing of voice, video and data, and provide telephony and softswitch functions.

According to an embodiment of the present invention, there is provided a method embodiment of outbound task processing, it being noted that the steps shown in the flowchart of the figures may be performed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be performed in an order other than that shown or described herein.

Fig. 1 is a flowchart of an outbound task processing method according to an embodiment of the present invention, as shown in fig. 1, the method including the steps of:

step S102, responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the target outbound task is initiated to fail, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator.

Optionally, when the target outbound task is on but no sound signal is detected, i.e. the target outbound task is on but silent, determining that the target outbound task has failed to initiate.

Alternatively, steps S102 to S110 may be implemented based on Kafka message middleware, and the target server is a FreeSWITCH server, and the FreeSWITCH outbound on silence cause is checked based on Kafka message middleware. The following settings are also required before the above step S102 is performed: and starting a call at an outbound call initiator, and opening an interaction channel of a Kafka message queue and an event socket library ESL, freeSWITCH of the Kafka. The method specifically comprises the following steps: the bridging user (i.e., outbound originating terminal) a-LEG initiates a call with the extension device B-LEG. Setting the Kafka theme: the Kafka theme is created for transceiving FreeSWITCH events and log data from the ESL. Set-up Kafka ESL producer, ESL consumer: in the FreeSWITCH environment, freeSWITCH events and log data are published and subscribed to the Kafka topic by ESL.

Optionally, under the condition that the target outbound task is connected with silence, the silence reason needs to be further determined, and the silence reason is possibly caused by the extension registration reason, based on which extension registration information can be acquired, and extension registration verification is performed based on the extension registration information, so that the purpose of comprehensively determining the extension registration reason is achieved, and the analysis efficiency and the analysis accuracy of the extension registration reason are improved.

In an alternative embodiment, in response to a target outbound task initiated by an outbound initiator, in a case that the initiation of the target outbound task fails, obtaining, by a target server, extension registration information corresponding to the target outbound task, including: responding to the target outbound task, and detecting whether a Real-time transport protocol (Real-time Transport Protocol, RTP) port corresponding to the target outbound task and a session initiation protocol (Session Initiation Protocol, SIP) are successfully configured under the condition that the initiation of the target outbound task fails; under the condition that the RTP port and the SIP registration port are successfully configured, the extension registration information is acquired from the target server based on the SIP registration signaling corresponding to the outbound initiating terminal.

Optionally, the reason for silent outbound may relate to the configuration situation of the RTP port and the SIP registration port, based on which, before the acquisition of the extension registration information, the configuration of the RTP port and the SIP registration port is detected, and only if the port configuration is successful, the further acquisition of the extension registration information is needed to determine the subsequent reason for silent outbound, otherwise, the further acquisition of the extension registration information is not needed. The method directly determines that the silence source is the silence of the outbound call caused by the configuration reasons of the RTP port and the SIP registration port, so as to achieve the aim of comprehensively analyzing the silence source of the outbound call.

In an alternative embodiment, detecting whether the RTP port and the SIP registration port corresponding to the target outbound task are configured successfully includes: inquiring whether a port range corresponding to the RTP port is opened or not; under the condition that the port range corresponding to the RTP port is inquired to be opened, inquiring whether the SIP registration port is opened or not; under the condition that the SIP registration port is detected to be opened, determining that the RTP port and the SIP registration port are successfully configured; and under the condition that the SIP registration port is not opened, determining that the RTP port and the SIP registration port are failed to be configured.

Optionally, in the FreeSWITCH configuration file, the configuration of the RTP port is generally searched and confirmed through vars.xml or sofia.conf.xml, if the port range of the RTP port is searched to be opened, whether the SIP registration port is opened is further searched, if the SIP registration port is also opened, it is indicated that the silence of the outbound call is not caused by the configuration reasons of the RTP port and the SIP registration port, and further detection of the silence reason needs to be performed by acquiring the extension registration information. If the SIP registration port is inquired not to be opened, stopping subsequent operation, and determining that silence after the external call is connected is caused by the configuration failure of the RTP port and the SIP registration port.

In an alternative embodiment, after determining that the RTP port and the SIP registered port are configured to fail in the case that the SIP registered port is detected to be unopened, the method further includes: and under the condition that the port range corresponding to the RTP port is not opened, modifying the port range corresponding to the RTP port, and opening the SIP registration port.

Optionally, in the FreeSWITCH configuration file, the configuration of the RTP port is usually found and confirmed by a vars.xml file or a sofia.conf.xml file, where vars.xml is usually used to define variables and parameters, and the file usually contains some global variable and parameter settings for reference and use by other configuration files; the Sofia. Conf. Xml file contains configuration information of various SIP terminals and gateways, and related parameter settings, which are typically used to configure the SIP communication protocol stack (Sofia) in FreeSWITCH. If the port range is not set, the RTP port range is modified, the SIP registration port is opened, and FreeWITCH is restarted. And (3) circularly traversing the set port range, and transmitting socket. Connect (socket connection function, namely socket connection function) through a transmitting thread sender of Kafka to perform connection test. If the connection is successful, it will output a message that the port has been opened, if the connection fails, it will output a message that the port has been closed, and finally send specific port connection details to the Kafka proxy server (i.e., kafka brooker). By the above mode, the real-time correction of the configuration of the RTP port and the SIP registration port can be realized, so that the silence of the outbound call caused by the configuration of the RTP port and the SIP registration port is eliminated, and the interference of the configuration factors of the RTP port and the SIP registration port on the silence of the outbound call is reduced.

Step S104, when the extension registration verification is passed based on the extension registration information, at least two extensions are determined based on the extension registration information.

Alternatively, two extensions may be randomly fetched, but not limited to, by extension registration information obtained by the Kafka thread. The method is used for determining the silence reason after the external call is connected in a subsequent call simulation mode.

In an alternative embodiment, in the case that the verification of the extension registration is performed based on the extension registration information, before determining at least two extensions based on the extension registration information, the verification of the extension registration needs to be performed, and the specific verification process includes: based on extension registration information, determining SIP signaling corresponding to an outbound originating terminal; inquiring whether the SIP signaling reaches an outbound receiving end; under the condition that the SIP signaling reaches an outbound receiving end, determining a public network address for transmitting the SIP signaling and a network communication state corresponding to the public network address; and under the condition that the network communication state corresponding to the public network address is detected to be in a normal state, determining that the extension registration check passes.

Optionally, the SIP registration signaling may be sent according to the SIP registration port and the RTP port, and the extension number corresponding to the generated port is stored in the FreeSWITCH default table, and the sender thread is called by the event socket library ESL to send a preset command to the FreeSWITCH, so as to obtain extension registration information from the FreeSWITCH.

Optionally, network address translation (Network Address Translation, NAT) and real port rport functionality are further enabled: NAT features refer to network address translation that allows communication between a private network and a public network, translating IP addresses in the private network to IP addresses recognizable by the public network; the rport function refers to the "rport" parameter defined in RFC3581, which is used to solve the problem of bidirectional NAT. When the client is behind the NAT, the rport function allows FreeSWITCH to obtain the real IP address and port information of the client. And starting NAT characteristic in FreeWITCH, starting rport function, thereby ensuring that SIP signaling can reach appointed terminal (i.e. outbound receiving end) correctly after network penetration, if SIP signaling reaches outbound receiving end correctly, further configuring public network address of SIP, requesting to judge whether local public network layer communication is normal or not based on the previously acquired request source network address (i.e. IP address of equipment or user initiating SIP request), if network communication state is normal, determining that hierarchical registration check is passed, and further executing subsequent silence cause determination flow after outbound connection. If the network communication state is abnormal, the result of the silence of the outbound call caused by the abnormal network communication state is put into a Kafka double-end queue.

In an alternative embodiment, the method further comprises: and under the condition that the SIP signaling does not reach the outbound receiving end, determining that the establishment of the channel between the outbound initiating end and the target server fails.

Optionally, the NAT feature is enabled in FreeSWITCH, and the rport function is started, so as to ensure that the SIP signaling can correctly reach the designated terminal (i.e., the outbound receiving end) after network penetration, and if the SIP signaling is sent back to the recovery_timer_outbound in the following table 1 after the start, the SIP signaling is indicated to not reach the outbound receiving end, and is regarded as a problem of network outbound, and is put into the Kafka double-end queue.

TABLE 1

In an alternative embodiment, in a case that the extension registration check is passed based on the extension registration information, determining at least two extensions based on the extension registration information includes: transmitting an echo detection instruction to a target server under the condition that extension registration verification passes based on extension registration information; inquiring whether gateway routing information corresponding to the echo detection instruction is registered or not; judging whether an echo detection return result returned by the target server aiming at the echo detection instruction is received or not under the condition that gateway routing information corresponding to the echo detection instruction is registered; and under the condition that an echo detection return result is received, acquiring at least two extensions based on the extension registration information.

Optionally, after subscribing to a specific Kafka Broker theme, an echo detection command is sent to FreeSWITCH by calling the event socket library ESL through the Kafka thread, where the command is as follows: an original software/gateway/line name/test handset number & echo (), where "original" is a command in FreeSWITCH for initiating a new call. It allows the user to specify the origin and destination of the call. The line name may obtain registered gateway line information through a Sofia status, which is a command in FreeWITCH to view registered gateway line information. It provides information about the status of the SIP gateway, the number of channels, the success rate of the call, etc. If the query result is unregistered, the line fault is indicated, and the line fault is placed in a Kafka double-ended queue.

Optionally, analyzing the echo detection return result, if the echo detection return result is abnormal, regarding as a line fault, if the echo detection return result is normal, indicating that the line communication is normal, regarding no echo as a problem of the RTP network outgoing direction, and finally placing the result into the Kafka double-end queue. By the method, when the silence cause is determined after the outbound is connected, whether the silence is caused by gateway route registration information, echo abnormity and other reasons is analyzed, so that the comprehensiveness of the analysis of the silence cause of the outbound is improved, and the analysis efficiency of the silence cause of the outbound is further improved.

Step S106, calling a target server to carry out extension bridging on at least two extensions, simulating a call environment between an outbound initiating terminal and an outbound receiving terminal, and obtaining a target voice stream after extension bridging;

step S108, judging whether the target voice stream is a mute voice stream;

step S110, determining that the audio file corresponding to the target outbound task has a fault under the condition that the target voice stream is not the mute voice stream.

Optionally, the registered extension registration information is acquired through the Kafka thread, and at least two extensions (such as extension 1 and extension 2) are randomly fetched. Taking two extensions taken randomly as an example, sending a command to the ESL through a Kafka thread to call FreeWITCH to bridge the two extensions selected randomly, simulating a call between registered users, creating a call environment, calling the ESL to obtain a voice stream after the extensions are bridged, and putting the voice stream into a Kafka double-end queue, wherein the bridging command is as follows:

registration user/extension 1& bridge user/extension 2

The method comprises the steps that an original user represents an initiating user in two extensions, a bridge user represents a bridging user in the two extensions, an event socket library consumes a voice stream returned by the bridging of the extensions (namely a target voice stream), a silence detection module is called to judge whether the target voice stream is a silence voice stream, and if the bridging return result of the extensions is that the target voice stream is the silence voice stream, the result that the target voice stream is the silence voice stream is put into a Kafka double-end queue; if the extension bridge returns that the target voice stream is not the mute voice stream, the description is an audio file problem, the backstage management configuration is checked, and the result is put into a Kafka double-end queue.

Through the steps from S102 to S110, the purposes of sequentially performing extension registration verification, silence voice stream recognition based on outbound task simulation and audio file fault recognition, and accurately and comprehensively recognizing the outbound silence cause can be achieved, so that the accuracy of recognition of the outbound task silence cause is improved, the outbound efficiency is further improved, the technical effect of outbound resources is saved, and the technical problems that the outbound efficiency is low and the outbound resources are wasted due to incapability of accurately recognizing the silence cause after the outbound task is switched on in the related technology are solved.

Based on the foregoing embodiment and the optional embodiments, the present invention proposes an optional implementation, fig. 2 is a flowchart of an optional outbound task processing method according to an embodiment of the present invention, and fig. 3 is a flowchart of another optional outbound task processing method according to an embodiment of the present invention, as shown in fig. 2 and fig. 3, where the method includes:

step S1, starting a call, and starting an interactive channel of a Kafka message queue, an event socket library ESL and a free switch FreeWITCH. The method specifically comprises the following substeps:

step S11, the bridging user (i.e. the outbound originating terminal) A-LEG and the extension equipment B-LEG start calling.

In step S12, a Kafka message queue, which may be a Kafka double-ended queue, is opened.

Step S13, setting the Kafka theme: the Kafka theme is created for transceiving FreeSWITCH events and log data from the ESL.

In step S14, the Kafka ESL producer and ESL consumer are set, and in the FreeWITCH environment, freeWITCH events and log data are published and subscribed to the Kafka theme through the ESL.

Step S2, checking the RTP port and the SIP registration port under the condition that the failure of the initiation of the outbound task initiated by the outbound initiator is detected, namely that the outbound task is connected but silent. The method specifically comprises the following substeps:

step S21, checking the configuration file: in the FreeSWITCH configuration file, the configuration of the RTP port is usually found and confirmed through vars.xml or sofia.conf.xml, and if the port range is not set, the RTP port range is modified, the SIP registration port is opened, and the FreeSWITCH is restarted.

Step S22, port connection test: and (5) circularly traversing the set port range, and transmitting socket. If the connection is successful, it will output a message that the port has been opened, if the connection is failed, it will output a message that the port has been closed, and finally send specific port connection details to the Kafka brooker.

And S3, checking extension registration details, and guaranteeing normal SIP signaling communication. The method specifically comprises the following substeps:

step S31, according to the SIP registration port and RTP port in step S2, the SIP registration signaling is sent, the extension number corresponding to the generated port is stored in the FreeWITCH default table, the sender thread is called by the event socket library ESL to send a preset command to the FreeWITCH, and the extension registration information is obtained from the FreeWITCH.

Step S32, enabling NAT and actual port rport functions. When the client is behind the NAT, the rport function allows FreeSWITCH to obtain the real IP address and port information of the client. And starting NAT characteristic in FreeWITCH, starting rport function, thereby ensuring that SIP signaling can reach appointed terminal (namely outbound receiving end) correctly after network penetration, if so, sending back SIP signaling to RECOVERY ON_TIMER_EXPIRE, regarding outbound silence cause as outbound silence caused by network outbound problem, and putting outbound silence cause caused by network outbound problem into Kafka double-end queue.

Step S33, configuring public network address corresponding to SIP signaling, requesting to judge whether local public network layer communication is normal based on the previously acquired request source network address (i.e. IP address of equipment or user initiating SIP request), if the network communication state is normal, determining that the hierarchical registration check is passed, and further executing subsequent silence cause determination flow after external call is connected. If the network communication state is abnormal, the result of the silence of the outbound call caused by the abnormal network communication state is put into a Kafka double-end queue.

Step S4, echo detection, specifically comprising the following sub-steps:

step S41, based on the step S1 to the step S3, after subscribing to a specific Kafka Broker theme, calling an event socket library ESL through a Kafka thread to send an echo detection command to FreeWITCH, wherein the command is as follows:

an original software/gateway/line name/test handset number & echo (), where "original" is a command in FreeSWITCH for initiating a new call. It allows the user to specify the origin and destination of the call. The line name may obtain registered gateway line information through a Sofia status, which is a command in FreeWITCH to view registered gateway line information. It provides information about the status of the SIP gateway, the number of channels, the success rate of the call, etc. If the query result is unregistered, the explanation is a line fault, and the result of the line fault, which leads to silence of the outbound call, is put into a Kafka double-ended queue.

Step S42, analyzing the echo detection return result, if the echo detection return result is abnormal, regarding the echo detection return result as a line fault, if the echo detection return result is normal, indicating that the line communication is normal, regarding the silence reason as an RTP network outbound problem, and finally placing the result of the RTP network outbound fault, which leads to outbound silence, into a Kafka double-end queue.

Step S5, simulating a call, which specifically comprises the following sub-steps:

step S51, obtaining the extension registration information registered in the step S3 through a Kafka thread, and randomly taking out two extensions.

Step S52, sending a command to call FreeWITCH through the ESL of the event socket library by using the Kafka thread, bridging the two randomly selected extensions, simulating the call between registered users, creating a call environment, calling the ESL of the event socket library to obtain the voice stream after the extension bridging, and putting the voice stream into a Kafka double-end queue, wherein the bridging command is as follows:

registration user/extension 1& bridge user/extension 2

Step S53, the event socket library consumes the voice stream returned by the extension bridge (namely, the target voice stream), calls a silence detection module to judge whether the target voice stream is the silence voice stream, and if the extension bridge returns that the target voice stream is the silence voice stream, puts the result that the target voice stream is the silence voice stream into a Kafka double-end queue; if the extension bridging returns that the target voice stream is not the mute voice stream, the description is an audio file problem, the background management configuration is checked, and the result that the audio file problem causes the outbound silence is put into a Kafka double-end queue.

Through the mode, the embodiment of the invention fully plays the synergistic effect of Kafka and FreeWITCH, and combines multiple verification and analysis steps to realize the rapid detection and positioning of the silent problem after the external call is connected. At least one of the following effects can be achieved by the implementation of the invention: 1) Fast localization of the cause of silence after the outbound call is on: the embodiment of the invention aims to realize the rapid positioning of the silent reason after the external call is connected and return the result by combining the Kafka message queue and the FreeWITCH. By analyzing the real-time data flow, the return reasons can be rapidly resolved, so that operation and maintenance developers can be helped to rapidly take appropriate measures, and the duration of call faults is reduced. 2) Avoiding the waste of outbound resources: the embodiment of the invention is beneficial to avoiding the problems of call interruption, invalid call, timing charge, data waste and the like caused by the silence problem, and avoids the waste of subsequent resources and time by timely finding and solving the problems and sending the silence reason to a developer for processing in the first time in the modes of automatic callback mail, outbound, short message and the like of Kafka. 3) The processing efficiency of outbound tasks is improved: the embodiment of the invention also aims to improve the overall efficiency of the outbound service by rapidly positioning and solving the silent problem after the outbound is connected due to the problem of an application layer. The silent problem may affect customer experience and service promotion, and through the embodiment of the invention, the enterprise can more effectively develop outbound activities, and customer satisfaction and service success rate are improved.

The embodiment also provides an outbound task processing device, which is used for implementing the foregoing embodiments and preferred embodiments, and is not described in detail. As used below, the terms "module," "apparatus" may be a combination of software and/or hardware that implements a predetermined function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

According to an embodiment of the present invention, there is further provided an embodiment of an apparatus for implementing the outbound task processing method, and fig. 4 is a schematic structural diagram of an outbound task processing apparatus according to an embodiment of the present invention, as shown in fig. 4, where the outbound task processing apparatus includes: a response module 400, a first determination module 402, a call module 404, a judgment module 406, a second determination module 408, wherein:

a response module 400, configured to respond to a target outbound task initiated by an outbound initiator, and obtain, by using a target server, extension registration information corresponding to the target outbound task in case that the initiation of the target outbound task fails, where the extension registration information is used to indicate registration status information of extension equipment corresponding to the outbound initiator;

A first determining module 402, connected to the responding module 400, for determining at least two extensions based on the extension registration information in case that the extension registration check is passed based on the extension registration information;

the calling module 404 is connected to the first determining module 402, and is configured to call the target server to perform extension bridging on at least two extensions, simulate a call environment between the outbound initiating terminal and the outbound receiving terminal, and obtain a target voice stream after extension bridging;

the judging module 406 is connected to the calling module 404, and is configured to judge whether the target voice stream is a mute voice stream;

the second determining module 408 is connected to the judging module 406, and is configured to determine that the audio file corresponding to the target outbound task has a fault if the target voice stream is not a mute voice stream.

In the embodiment of the present invention, a response module 400 is provided, which is configured to respond to a target outbound task initiated by an outbound initiator, and obtain, by using a target server, extension registration information corresponding to the target outbound task in case that the initiation of the target outbound task fails, where the extension registration information is used to indicate registration status information of extension equipment corresponding to the outbound initiator; a first determining module 402, connected to the responding module 400, for determining at least two extensions based on the extension registration information in case that the extension registration check is passed based on the extension registration information; the calling module 404 is connected to the first determining module 402, and is configured to call the target server to perform extension bridging on at least two extensions, simulate a call environment between the outbound initiating terminal and the outbound receiving terminal, and obtain a target voice stream after extension bridging; the judging module 406 is connected to the calling module 404, and is configured to judge whether the target voice stream is a mute voice stream; the second determining module 408 is connected to the judging module 406, and is configured to determine that, when the target voice stream is not a mute voice stream, there is a fault in the audio file corresponding to the target outbound task, so as to achieve the purposes of sequentially performing extension registration verification, mute voice stream recognition based on outbound task simulation, and audio file fault recognition, and accurately and comprehensively recognizing the outbound silence cause, thereby improving the accuracy of recognition of the outbound task silence cause, further improving the outbound efficiency, saving the technical effect of outbound resources, and further solving the technical problems of low outbound efficiency and extravagant outbound resources caused by the fact that the silence cause after the outbound task is switched on cannot be accurately recognized in the related art.

In an alternative embodiment, the response module includes: the first response sub-module is used for responding to the target outbound task and detecting whether the real-time transport protocol RTP port corresponding to the target outbound task and the session initiation protocol SIP registration port are successfully configured or not under the condition that the target outbound task is connected but no sound signal is detected; and the first acquisition sub-module is used for acquiring extension registration information from the target server based on the SIP registration signaling corresponding to the outbound initiating terminal under the condition that the RTP port and the SIP registration port are successfully configured.

In an alternative embodiment, the first response submodule includes: the first inquiry submodule is used for inquiring whether the voice range port corresponding to the RTP port is opened or not; the second inquiry submodule is used for inquiring whether the SIP registration port is opened or not under the condition that the voice range port corresponding to the RTP port is inquired to be opened; the first determining submodule is used for determining that the RTP port and the SIP registration port are successfully configured under the condition that the SIP registration port is detected to be opened; and the second determining submodule is used for determining that the RTP port and the SIP registration port are failed to be configured under the condition that the SIP registration port is detected to be unopened.

In an alternative embodiment, the apparatus further comprises: and the first modification submodule is used for modifying the voice range port corresponding to the RTP port and opening the SIP registration port under the condition that the voice range port corresponding to the RTP port is not opened.

In an alternative embodiment, the apparatus further comprises: a third determining submodule, configured to determine an SIP signaling corresponding to the outbound originating terminal based on extension registration information; a third query sub-module, configured to query whether the SIP signaling reaches an outbound receiver; a fourth determining submodule, configured to determine a public network address used for transmitting the SIP signaling and a network communication state corresponding to the public network address when the SIP signaling is queried to reach the outbound receiving end; and the fifth determining submodule is used for determining that the extension registration check passes under the condition that the network communication state corresponding to the public network address is detected to be in a normal state.

In an alternative embodiment, the apparatus further comprises: and a sixth determining submodule, configured to determine that the channel establishment between the outbound originating terminal and the target server fails when the SIP signaling is queried to reach the outbound receiving terminal.

In an alternative embodiment, the first determining module includes: the first sending submodule is used for sending an echo detection instruction to the target server under the condition that extension registration verification is passed based on extension registration information; a fourth query sub-module, configured to query whether gateway routing information corresponding to the echo detection instruction is registered; the first judging sub-module is used for judging whether an echo detection return result returned by the target server aiming at the echo detection instruction is received or not under the condition that gateway routing information corresponding to the echo detection instruction is inquired; and the second acquisition sub-module is used for acquiring at least two extensions based on the extension registration information under the condition that an echo detection return result is received.

It should be noted that each of the above modules may be implemented by software or hardware, for example, in the latter case, it may be implemented by: the above modules may be located in the same processor; alternatively, the various modules described above may be located in different processors in any combination.

It should be noted that, the response module 400, the first determining module 402, the calling module 404, the judging module 406, and the second determining module 408 correspond to steps S102 to S110 in the embodiment, and the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the foregoing embodiments. It should be noted that the above modules may be run in a computer terminal as part of the apparatus.

It should be noted that, the optional or preferred implementation manner of this embodiment may be referred to the related description in the embodiment, and will not be repeated herein.

The outbound task processing device may further include a processor and a memory, where the response module 400, the first determining module 402, the calling module 404, the judging module 406, the second determining module 408, etc. are stored in the memory as program modules, and the processor executes the program modules stored in the memory to implement corresponding functions.

The processor comprises a kernel, the kernel accesses the memory to call the corresponding program module, and the kernel can be provided with one or more than one. The memory may include volatile memory, random Access Memory (RAM), and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM), among other forms in computer readable media, the memory including at least one memory chip.

According to an embodiment of the present application, there is also provided an embodiment of a nonvolatile storage medium. Optionally, in this embodiment, the nonvolatile storage medium includes a stored program, where the program is controlled to execute any one of the outbound task processing methods by a device in which the nonvolatile storage medium is located when the program runs.

Alternatively, in this embodiment, the above-mentioned nonvolatile storage medium may be located in any one of the computer terminals in the computer terminal group in the computer network or in any one of the mobile terminals in the mobile terminal group, and the above-mentioned nonvolatile storage medium includes a stored program.

Optionally, the program controls the device in which the nonvolatile storage medium is located to perform the following functions when running: responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator; determining at least two extensions based on the extension registration information under the condition that the extension registration verification passes based on the extension registration information; calling a target server to carry out extension bridging on at least two extensions, simulating a call environment between an outbound initiating terminal and an outbound receiving terminal, and obtaining target voice streams after extension bridging; judging whether the target voice stream is a mute voice stream or not; and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault.

According to an embodiment of the present application, there is also provided an embodiment of a processor. Optionally, in this embodiment, the processor is configured to run a program, where any one of the outbound task processing methods is executed when the program runs.

According to an embodiment of the present application, there is also provided an embodiment of a computer program product adapted to perform a program initialized with the steps of any one of the outbound task processing methods described above when executed on a data processing device.

Optionally, the computer program product mentioned above, when executed on a data processing device, is adapted to perform a program initialized with the method steps of: responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator; determining at least two extensions based on the extension registration information under the condition that the extension registration verification passes based on the extension registration information; calling a target server to carry out extension bridging on at least two extensions, simulating a call environment between an outbound initiating terminal and an outbound receiving terminal, and obtaining target voice streams after extension bridging; judging whether the target voice stream is a mute voice stream or not; and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault.

The embodiment of the invention provides an electronic device, which comprises a processor, a memory and a program stored on the memory and capable of running on the processor, wherein the following steps are realized when the processor executes the program: responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator; determining at least two extensions based on the extension registration information under the condition that the extension registration verification passes based on the extension registration information; calling a target server to carry out extension bridging on at least two extensions, simulating a call environment between an outbound initiating terminal and an outbound receiving terminal, and obtaining target voice streams after extension bridging; judging whether the target voice stream is a mute voice stream or not; and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault.

The above-described order of embodiments of the invention is merely for illustration and does not represent the advantages or disadvantages of the embodiments.

In the foregoing embodiments of the present invention, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed technology content may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the modules may be a logic function division, and there may be another division manner when actually implemented, for example, a plurality of modules or components may be combined or may be integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with respect to each other may be through some interface, module or indirect coupling or communication connection of modules, electrical or otherwise.

The modules described above as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules.

The integrated modules described above, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable non-volatile storage medium. Based on such understanding, the technical solution of the present invention may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a non-volatile storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the embodiments of the present invention. And the aforementioned nonvolatile storage medium includes: a U-disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely a preferred embodiment of the present invention and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present invention, which are intended to be comprehended within the scope of the present invention.

Claims (10)

1. An outbound task processing method, comprising:

responding to a target outbound task initiated by an outbound initiator, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiator;

determining at least two extensions based on the extension registration information under the condition that the extension registration verification is passed based on the extension registration information;

calling the target server to carry out extension bridging on the at least two extensions, simulating a call environment between the outbound initiating terminal and the outbound receiving terminal, and acquiring a target voice stream after extension bridging;

judging whether the target voice stream is a mute voice stream or not;

and under the condition that the target voice stream is not the mute voice stream, determining that the audio file corresponding to the target outbound task has a fault.

2. The method according to claim 1, wherein the obtaining, by the target server, extension registration information corresponding to the target outbound task in the case that the target outbound task is initiated to fail, in response to the target outbound task initiated by the outbound initiator, includes:

Responding to the target outbound task, and detecting whether a real-time transport protocol (RTP) port corresponding to the target outbound task and a Session Initiation Protocol (SIP) registration port are successfully configured under the condition that the initiation of the target outbound task fails;

and under the condition that the RTP port and the SIP registration port are successfully configured, acquiring the extension registration information from the target server based on the SIP registration signaling corresponding to the outbound initiating terminal.

3. The method according to claim 2, wherein the detecting whether the RTP port and the SIP registration port corresponding to the target outbound task are successfully configured includes:

inquiring whether a port range corresponding to the RTP port is opened or not;

under the condition that the port range corresponding to the RTP port is inquired to be opened, inquiring whether the SIP registration port is opened or not;

under the condition that the SIP registration port is detected to be opened, determining that the RTP port and the SIP registration port are successfully configured;

and under the condition that the SIP registration port is detected not to be opened, determining that the RTP port and the SIP registration port are failed to be configured.

4. A method according to claim 3, wherein upon said determining that said RTP port and said SIP registered port configuration failed if said SIP registered port is detected not to be open, said method further comprises:

And under the condition that the port range corresponding to the RTP port is not opened, modifying the port range corresponding to the RTP port, and opening the SIP registration port.

5. The method according to claim 1, wherein, in case an extension registration check is passed based on the extension registration information, before determining at least two extensions based on the extension registration information, the method further comprises:

based on the extension registration information, determining the SIP signaling corresponding to the outbound originating terminal;

inquiring whether the SIP signaling reaches the outbound receiving end;

under the condition that the SIP signaling reaches the outbound receiving end, determining a public network address for transmitting the SIP signaling and a network communication state corresponding to the public network address;

and under the condition that the network communication state corresponding to the public network address is detected to be in a normal state, determining that the extension registration check passes.

6. The method of claim 5, wherein the method further comprises:

and under the condition that the SIP signaling does not reach the outbound receiving end, determining that the channel establishment between the outbound initiating end and the target server fails.

7. The method according to any one of claims 1 to 6, wherein said determining at least two extensions based on said extension registration information in case an extension registration check passes based on said extension registration information, comprises:

transmitting an echo detection instruction to the target server under the condition that extension registration verification passes based on extension registration information;

inquiring whether gateway routing information corresponding to the echo detection instruction is registered or not;

judging whether an echo detection return result returned by the target server for the echo detection instruction is received or not under the condition that gateway routing information corresponding to the echo detection instruction is registered;

and under the condition that the echo detection return result is received, acquiring the at least two extensions based on the extension registration information.

8. An outbound task processing device, comprising:

the response module is used for responding to a target outbound task initiated by an outbound initiating terminal, and acquiring extension registration information corresponding to the target outbound task through a target server under the condition that the initiation of the target outbound task fails, wherein the extension registration information is used for indicating registration state information of extension equipment corresponding to the outbound initiating terminal;

A first determining module, configured to determine at least two extensions based on the extension registration information when the extension registration verification is passed based on the extension registration information;

the calling module is used for calling the target server to carry out extension bridging on the at least two extensions, simulating a call environment between the outbound initiating terminal and the outbound receiving terminal, and acquiring a target voice stream after extension bridging;

the judging module is used for judging whether the target voice stream is a mute voice stream or not;

and the second determining module is used for determining that the audio file corresponding to the target outbound task has a fault under the condition that the target voice stream is not the mute voice stream.

9. A non-volatile storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the outbound task processing method of any one of claims 1 to 7.

10. An electronic device comprising one or more processors and a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the outbound task processing method of any of claims 1 to 7.