Call control method, device and system, electronic equipment and storage medium

Abstract

The invention provides a call control method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a call parameter in a call event in response to the call event triggered by a multimedia server according to a first routing strategy; the first routing strategy is used for triggering call events of the same type for a plurality of different call parameters; matching a call parameter in the call event with a plurality of routing table entries in a second routing strategy, and determining a routing table entry matched with the call parameter in the call event from the plurality of routing table entries; screening the third-party device according to the matched routing table item, sending a control instruction to the third-party device, and obtaining response data from the third-party device; and generating a call instruction corresponding to the response data, wherein the call instruction is used for indicating the multimedia server to execute call processing. According to the mode, the execution efficiency of the calling system is improved, and the problem that a communication link is complex due to the fact that the multimedia server executes too many service control functions is avoided.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular to a call control method, device, system, electronic device, and storage medium. Background Art

[0002] A call system typically includes a media softswitch platform (such as a multimedia server), a Computer Telecommunication Integration (CTI) device, and external third-party devices. In related technologies, the media softswitch platform requires pre-configured complex routing policies. Accordingly, upon receiving a call request, the media softswitch platform must perform the following processing:

[0003] First, the media soft switch platform dynamically determines the third-party device used to handle this call based on the pre-configured routing strategy; then, the media soft switch platform dynamically generates a call event of the corresponding type based on the determination result; finally, based on the specific type of call event, it chooses to send the call event directly to the corresponding third-party device, or to send the call event to the computer telecommunications integration device.

[0004] It can be seen that in the above method, in addition to performing media-related processing, the media soft switch platform also needs to perform complex logical judgments, such as route matching, event type classification, etc., which leads to complex processing logic and low execution efficiency. Summary of the Invention

[0005] The present disclosure provides a call control method, device, system, electronic device and storage medium, which can simplify the execution logic of a media soft switching platform and improve system operation efficiency.

[0006] In a first aspect, the present disclosure provides a call control method, the method comprising:

[0007] In response to a call event triggered by the multimedia server according to a first routing policy, obtaining a call parameter in the call event; the first routing policy is used to trigger the same type of call event for multiple different call parameters;

[0008] matching the call parameters in the call event with a plurality of routing table entries in a second routing policy, and determining a routing table entry that matches the call parameters in the call event from the plurality of routing table entries; wherein the second routing policy is used to trigger different types of call events according to the plurality of different call parameters, and each routing table entry in the second routing policy corresponds to a matching condition;

[0009] screening a third-party device according to the matched routing table entry, sending a control instruction to the third-party device, and obtaining response data from the third-party device;

[0010] A call instruction corresponding to the response data is generated, where the call instruction is used to instruct the multimedia server to perform call processing.

[0011] In a second aspect, the present disclosure provides a call control device, the call control device comprising:

[0012] an acquisition module adapted to acquire, in response to a call event triggered by the multimedia server according to a first routing policy, a call parameter in the call event; the first routing policy being used to trigger the same type of call event for a plurality of different call parameters;

[0013] a matching module, adapted to match the call parameters in the call event with a plurality of routing table entries in a second routing policy, and determine a routing table entry that matches the call parameters in the call event from the plurality of routing table entries; wherein the second routing policy is used to trigger different types of call events according to the plurality of different call parameters, and each routing table entry in the second routing policy corresponds to a matching condition;

[0014] a sending module, adapted to screen a third-party device according to the matched routing table entry, send a control instruction to the third-party device, and obtain response data from the third-party device;

[0015] The calling module is adapted to generate a calling instruction corresponding to the response data, wherein the calling instruction is used to instruct the multimedia server to execute a call process.

[0016] In addition, the present disclosure also provides a call system, including: the above-mentioned call control device, a multimedia server, and multiple third-party devices.

[0017] In a third aspect, the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and one or more of the computer programs are executed by the at least one processor to enable the at least one processor to execute the above-mentioned call control method.

[0018] In a fourth aspect, the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-mentioned call control method when executed by a processor.

[0019] In a fifth aspect, the present disclosure provides a computer program product comprising a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above-mentioned call control method.

[0020] In the call control method provided in the embodiments of the present disclosure, a computer-telecommunications integrated device can select a third-party device from multiple third-party devices according to a second routing policy based on call parameters in a call event sent by a multimedia server based on a first routing policy. Accordingly, a control instruction corresponding to the call parameters is generated and sent to the third-party device. After receiving response data returned by the third-party device, a call instruction corresponding to the response data is generated, causing the multimedia server to perform call processing based on the call instruction. Thus, in this method, a first routing policy and a second routing policy are pre-established, with the first routing policy being used to trigger the same type of call event for multiple different call parameters, and the second routing policy being used to trigger different types of call events for multiple different call parameters. Accordingly, the multimedia server itself does not need to implement service routing functionality; regardless of the call parameters, the computer-telecommunications integrated device only needs to uniformly send a single type of call event. Accordingly, the computer-telecommunications integrated device, as the executing entity in this method, performs service routing processing based on the second routing policy to select the third-party device from the multiple third-party devices. Furthermore, the computer-telecommunications integrated device can also send a corresponding call instruction to the multimedia server based on the response data returned by the third-party device. In this approach, the multimedia server only needs to perform media-related processing, without having to perform complex logical judgments. This simplifies the processing logic on the media side and improves execution efficiency. Furthermore, this approach decouples the media side (multimedia server) from the service side (third-party device). On the one hand, this eliminates the need for the multimedia server to communicate with multiple third-party devices separately, thereby simplifying the configuration complexity of the multimedia server. On the other hand, it eliminates the need for third-party devices to communicate with the multimedia server, also simplifying the configuration complexity of the third-party devices. In short, this approach improves the execution efficiency of the call system and avoids the problem of complex communication links caused by the multimedia server performing too many service control functions.

[0021] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing detailed example embodiments with reference to the accompanying drawings. In the accompanying drawings:

[0023] Figure 1 An application scenario diagram of the call control method and apparatus provided in an embodiment of the present disclosure;

[0024] Figure 2 A flowchart of a call control method provided by an embodiment of the present disclosure;

[0025] Figure 3 The following is an architecture diagram of a call system in the related art;

[0026] Figure 4 An architectural diagram showing an improved call system in a specific example of the present application is shown;

[0027] Figure 5 A block diagram of a call control device provided in an embodiment of the present disclosure;

[0028] Figure 6 A block diagram of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] To enable those skilled in the art to better understand the technical solutions of the present disclosure, exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0030] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0031] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0032] The terms used herein are only used to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded. Similar words such as "connected" or "connected" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0033] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined as such herein.

[0034] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution complies with relevant national laws and regulations (for example, the "Information Security Technology Personal Information Security Specification", etc.). For example: corresponding prescribed measures are taken to control access to personal information; the display of personal information is subject to prescribed restrictions; the purpose of using personal information does not exceed the scope of direct or reasonable connection; when using personal information, clear identity reference is eliminated to avoid precise positioning of specific individuals.

[0035] In the related art, the media soft switching platform needs to pre-configure complex routing strategies. Accordingly, after receiving a call request, the media soft switching platform dynamically determines the third-party device used to process the call according to the pre-configured routing strategies, dynamically generates call events of corresponding types, and selects to send the call events directly to the corresponding third-party device according to the specific type of the call event. In addition to performing media-related processing, the media soft switching platform in this method also needs to perform complex logical judgments, which leads to complex processing logic and low execution efficiency. In order to solve the above problems, the present disclosure provides a call control method, in which the decoupling between the media side (multimedia server) and the service side (third-party device) is achieved. On the one hand, the multimedia server does not need to communicate with multiple third-party devices separately, thereby simplifying the configuration complexity of the multimedia server; on the other hand, the third-party device does not need to communicate with the multimedia server, which also simplifies the configuration complexity of the third-party device.

[0036] Figure 1 This is an application scenario diagram of the call control method and device provided in the embodiment of the present disclosure. Figure 1 As shown, the application scenario of the embodiment of the present disclosure may include a multimedia server 101, a computer-telecom integration device 102, and multiple third-party devices 103. The multimedia server 101 is used to implement real-time media stream processing, communication protocol conversion, and basic call control functions. The computer-telecom integration device 102 is used to implement functions such as intelligent routing decisions and service instruction scheduling. The multiple third-party devices 103 are respectively used to implement various service functions, such as interactive voice response, manual response, and robot response. It should be noted that there are multiple third-party devices 103, and only one is used as an example in the figure.

[0037] Figure 2 This is a flowchart of a call control method provided by an embodiment of the present disclosure, which is applied to a computer telecommunications integrated device. Figure 2 , the method comprising:

[0038] Step S210: In response to a call event triggered by the multimedia server according to a first routing policy, a call parameter in the call event is obtained; the first routing policy is used to trigger the same type of call event for multiple different call parameters.

[0039] Among them, the execution subject of this embodiment is usually a computer telecommunications integration device. The computer telecommunications integration device can be a middleware layer dedicated to decision scheduling and instruction conversion in the communication system, and its core capabilities can include: (1) Intelligent routing center: dynamically allocate service nodes based on call parameters; (2) Instruction conversion: convert service responses into atomic call instructions. The multimedia server can be a hardware or software entity dedicated to processing real-time media streams in the communication system, and its core capabilities can include: (1) Basic call control: manage call establishment / release, transfer, maintenance and other life cycles; (2) Media stream forwarding and encoding and decoding: transmission, transcoding, and mixing of audio / video streams (such as conference bridges); (3) Protocol adaptation: support parsing and conversion of multiple communication protocols; (4) Atomic operation execution: only execute a single media action (playback / recording, etc.) and do not carry business decisions. For example, the multimedia server can include various forms such as FreeSWITCH, Asterisk, or a cloud-based media processing engine. For example, the multimedia server in this application may include at least one of the following: (1) an open source media server (such as FreeSWITCH / Asterisk); (2) a media processing module of a commercial communication platform (such as the media engine of Cisco UnifiedCM); (3) a media processing API service provided by a cloud service platform.

[0040] Call events are standardized notification events (such as incoming ringing events and call transfer events) generated by a multimedia server when a call state changes (e.g., after receiving a user-triggered call command). Call parameters are service decision factors embedded in call events. For example, call parameters may include the calling number (for user identification), the called number (for service type resolution), the media encoding type (for resource allocation decisions), and call time information (for distinguishing between weekdays and weekends).

[0041] It should be noted that, in order to simplify the processing logic of the multimedia server, the present application pre-builds a first routing strategy in the multimedia server. The first routing strategy is a simplified routing strategy, also called a wildcard routing strategy, which can trigger the same type of call event for multiple different call parameters through methods such as wildcards.

[0042] Step S220: Match the call parameters in the call event with multiple routing table items in the second routing policy, and determine the routing table item that matches the call parameters in the call event from the multiple routing table items; wherein the second routing policy is used to trigger different types of call events for multiple different call parameters, and each routing table item in the second routing policy corresponds to a matching condition.

[0043] Among them, compared with the first routing strategy, the second routing strategy is a complex routing strategy, also called a diversified routing strategy, which can trigger multiple different types of call events for multiple different call parameters to achieve complex routing processing. Accordingly, each routing table item in the second routing strategy corresponds to at least one matching condition. For example, the second routing strategy can be a set of rules pre-set in a computer telecommunications integrated device, in which each routing table item at least contains a mapping relationship between a routing decision condition (i.e., a matching condition) and a corresponding third-party device. Among them, the number of third-party devices is usually multiple, and they can be independent modules for providing vertical field business capabilities, which can be used to receive standard instruction input and return structured responses. For example, the third-party device can include multiple categories such as automatic voice interaction units, manual service interaction units, and intelligent business execution units. Among them, the second routing strategy can include one or more of the following: (1) Skill group routing method: mapping to a pre-configured professional skill agent group based on the key code input by the user. (2) Load balancing routing method: real-time monitoring of the resource occupancy rate (CPU / memory) of each third-party device, and allocating new calls to the device node with the least load. (3) Priority routing method: allocating the corresponding third-party device based on the user priority and / or business priority of the calling user. In addition, routing can also be performed based on various factors such as call type and call time. Accordingly, based on the matching results between the call parameters in the call event and the multiple routing table entries in the second routing policy, the routing table entry that matches the call parameters in the call event can be determined, and then the corresponding routing processing is performed based on the matching routing table entry.

[0044] This step parses key business factors (such as calling number / called number) in the call event and automatically allocates execution nodes using dynamic routing rules, thus achieving physical decoupling of business logic and media processing.

[0045] Step S230: Filter third-party devices according to the matching routing table entries, send control instructions to the third-party devices, and obtain response data from the third-party devices.

[0046] Since each routing table entry contains a mapping relationship between a matching condition and a corresponding third-party device, at least one third-party device can be screened from multiple third-party devices based on the device identifier of the third-party device recorded in the matching routing table entry to process this call event. Accordingly, a control instruction is sent to the at least one screened third-party device. The control instruction may be a standardized control instruction generated based on call parameters, which is used to indicate relevant information such as the service type to the third-party device. The response data may be determined based on the response message returned by the third-party device. The response message may be a structured data packet, which may include various information such as a status code (identifying success / failure), service data (such as user key values), etc. The response data may be key business result data extracted from the response message, which is used to drive subsequent operations. For example, the response data may be various information such as the user key value (numbers 1-9) returned by a voice playback type third-party device, or the service ticket number returned by an agent type third-party device.

[0047] Step S240: Generate a call instruction corresponding to the response data, where the call instruction is used to instruct the multimedia server to perform call processing.

[0048] After generating a call instruction corresponding to the response data, the call instruction is sent to the multimedia server so that the multimedia server performs call processing according to the call instruction.

[0049] The call instruction refers to a standardized command that can be directly executed by the multimedia server. For example, it usually only includes a single media action (such as playing audio, starting recording, etc.) and does not include logical judgment (such as conditional branching).

[0050] This step converts the response data into executable instructions for the multimedia server, enabling a seamless integration of business decisions and media control while simultaneously removing the complex business logic of the multimedia server. This approach eliminates the need for the multimedia server to parse the business semantics of the instructions and allows it to simply perform the physical operations, simplifying the multimedia server's execution logic and reducing its execution costs.

[0051] As can be seen, in the disclosed embodiments, a third-party device can be selected from multiple third-party devices according to a second routing policy based on call parameters in a call event sent by a multimedia server based on a first routing policy. Accordingly, a control instruction corresponding to the call parameters is generated and sent to the third-party device. After receiving response data returned by the third-party device, a call instruction corresponding to the response data is generated, causing the multimedia server to perform call processing based on the call instruction. As can be seen, in this approach, a first routing policy and a second routing policy are pre-established. The first routing policy is used to trigger the same type of call event for multiple different call parameters, while the second routing policy is used to trigger different types of call events for multiple different call parameters. Accordingly, the multimedia server itself does not need to implement service routing functionality; it only needs to send a single type of call event regardless of the call parameters. Accordingly, the execution entity in this method performs service routing processing based on the second routing policy to select a third-party device from multiple third-party devices. Furthermore, based on the response data returned by the third-party device, a corresponding call instruction can be sent to the multimedia server. In this approach, the multimedia server only needs to perform media-related processing, eliminating the need for complex logical judgments. This simplifies the processing logic on the media side and improves execution efficiency. This approach also decouples the media side (multimedia server) from the service side (third-party devices). This eliminates the need for the multimedia server to communicate with multiple third-party devices, simplifying the multimedia server's configuration. Furthermore, it eliminates the need for third-party devices to communicate with the multimedia server, simplifying their configuration. Overall, this approach improves call system efficiency and avoids the complexity of communication links caused by the multimedia server performing too many service control functions.

[0052] In addition, those skilled in the art may also make various changes and modifications to the methods in the embodiments of the present disclosure:

[0053] In one optional implementation, matching call parameters in a call event with multiple routing table entries in a second routing policy can be accomplished by selecting at least two call parameters from the multiple call parameters in the call event; and for any routing table entry, matching the at least two call parameters with at least two matching conditions in the routing table entry. The at least two call parameters include at least two of the following: a calling call parameter, a called call parameter, a call type parameter, and a call time parameter; and the at least two matching conditions include at least two of the following: a matching condition corresponding to the calling call parameter, a matching condition corresponding to the called call parameter, a matching condition corresponding to the call type parameter, and a matching condition corresponding to the call time parameter. In this approach, a routing table entry can include at least two matching conditions, and by matching the at least two call parameters with the at least two matching conditions, complex routing functionality can be implemented. For example, multiple factors, such as the call object and the call time period, can be combined to determine routing results, thereby enhancing the intelligence of the routing policy.

[0054] In an optional implementation, the inventors discovered during the implementation of the present invention that, in conventional systems, multiple third-party devices may use different protocols. Therefore, to enable communication between the computer-telecommunications integration device and multiple third-party devices, corresponding communication rules must be defined for each third-party device, making the call system inconvenient to expand. Once a new third-party device appears, corresponding communication rules must be defined specifically for that new third-party device. To address the aforementioned issues, the present application can pre-configure multiple preset communication interfaces in the computer-telecommunications integration device, allowing multiple third-party devices to implement corresponding communication processing functions simply by invoking the preset communication interfaces. Accordingly, the computer-telecommunications integration device can obtain a response message returned by the third-party device via the preset communication interface and parse the response message according to the interface configuration rules of the preset communication interface to obtain response parameters in the response message. Accordingly, the response data returned by the third-party device can be obtained by: receiving the response message returned by the third-party device via the preset communication interface; determining the parameter type and / or number corresponding to the preset communication interface based on the interface type of the preset communication interface; parsing the response message based on the parameter type and / or number corresponding to the preset communication interface, and obtaining response data based on the parsed results. This approach simplifies the calling costs of multiple heterogeneous third-party devices by leveraging standardized communication interfaces, and can accurately extract key parameters in response messages based on predefined interface configuration rules, thereby avoiding parsing errors caused by protocol differences.

[0055] Among them, the preset communication interface can be a pre-configured data exchange channel between the computer telecommunications integration device and the third-party device, which can support synchronous / asynchronous communication modes and meet protocol independence. The response message can be the original data packet returned by the third-party device, which can include a status identification field (success / failure code), a business data field (execution result), and an auxiliary information field (timestamp, signature, etc.). The interface configuration rules can be a set of metadata used to describe the structure of the response message. For example, parameter position rules (such as the arrangement order between multiple parameters), data type rules (such as key values ​​must be preset types or preset digits), and verification logic rules (such as numerical range verification, regular expression matching, etc.) can be defined. The response parameter can be a minimum business data set extracted from the response message to drive subsequent processes (such as user key values, voice recognition text, etc.).

[0056] In an optional implementation, in order to enhance the flexibility of the preset communication interface and facilitate the flexible implementation of various business functions through the preset communication interface, the preset communication interface can support multiple custom parameters. Accordingly, the interface configuration rules of the preset communication interface are used to characterize the parameter types and / or parameter quantities of the response parameters corresponding to the preset communication interface. For example, through a preset communication interface, multiple response parameters arranged in sequence according to a preset order can be input at the same time. In addition, the preset communication interface is used to perform preset atomic operations. Accordingly, before obtaining the response data returned by the third-party device, the parameter types and / or parameter quantities of the response parameters corresponding to the preset communication interface are further configured according to the operation type of the preset atomic operation performed by the preset communication interface. This method predefines the response parameter specifications through the atomic operation type, which can strongly bind the atomic operation type to the parameter rules, and facilitates the flexible configuration of the parameter rules according to the atomic operation type.

[0057] Among them, the preset atomic operation can be an indivisible business action unit that is independently completed by a third-party device. For example, the preset atomic operation may include: (1) voice broadcast: output audio content to the caller; (2) key acquisition: receive the user's key input; (3) session transfer: transfer control to other third-party devices. The parameter type is used to characterize the business semantic classification of the response parameters, which may specifically include: resource identification class (such as audio file path), user input class (such as key value, voice recognition text), status identification class (such as operation success / failure code). The number of parameters is used to characterize the number of parameter items that must be returned in a single response (such as a key operation must return two parameters, key value and duration, or a key operation requires pressing at least two combination keys continuously).

[0058] During specific implementation, the parameter types and / or parameter quantities of the response parameters corresponding to the preset communication interface can be configured by at least one of the following methods: (1) Method 1: Static pre-configuration (applicable to fixed business scenarios): The mapping relationship between the atomic operation type and the parameter specification can be solidified when the system starts. Accordingly, the preset mapping table can be loaded before calling the interface. This method has low overhead and can be applied to high real-time scenarios (such as emergency call systems). (2) Method 2: Dynamic policy configuration (applicable to multi-tenant systems): The association relationship between atomic operations and parameter rules is configured in real time through the management platform. For example, the configuration can be dynamically loaded according to the tenant ID and tenant type when the interface is called. This method can support differentiated business needs and improve system flexibility. In short, the configuration method of the parameter type and quantity can be expanded in combination with constraints such as regular expressions, and this application does not limit the specific details.

[0059] In an optional implementation, the parameter type and / or parameter quantity of the response parameter corresponding to the preset communication interface can be determined according to the operation execution mode of the preset atomic operation executed by the preset communication interface. For example, in a voice broadcast scenario, in order to solve the problem that the traditional hard-coded single implementation mode of voice broadcast cannot take into account both efficiency and flexibility, the operation type of the preset atomic operation executed by the preset communication interface is a voice broadcast type, and accordingly, the response parameter corresponding to the preset communication interface is configured as a voice broadcast type parameter; wherein, the voice broadcast type parameter may include: audio type parameters and text type parameters; audio type parameters are used to perform voice broadcast based on the acquired audio data; text type parameters are used to perform voice broadcast based on the acquired text data. Among them, in the voice broadcast scenario, the operation category of the third-party device that needs to output voice content to the caller can include the following two types of sub-operations: (1) calling a stored audio file to broadcast a pre-recorded audio file; (2) dynamically generating a voice stream through real-time text-to-speech (TTS). Accordingly, the audio parameter can be an identifier pointing to an audio resource (such as a file path / URL), etc. The text parameter can be the original text string for conversion by the TTS engine. Accordingly, the parameter type and / or parameter quantity corresponding to the preset communication interface can be determined in the following manner: when the interface type of the preset communication interface is a voice broadcast type, the parameters corresponding to the preset communication interface include: audio parameters and text parameters; wherein the audio parameters are used to perform voice broadcast based on the acquired audio data; and the text parameters are used to perform voice broadcast based on the acquired text data.

[0060] For another example, in a key capture scenario, in order to solve the problem of easy misoperation caused by the lack of bit constraints in the traditional key input method, the operation type of the preset atomic operation performed by the preset communication interface is a key capture type. Accordingly, the response parameter corresponding to the preset communication interface is configured as a key capture type parameter; wherein the number of key combination bits supported by the key capture type parameter is usually greater than or equal to 2. Among them, the key capture type is an operation category for collecting key sequences input by the user, which is suitable for scenarios such as menu selection and number input. The number of key combination bits is used to characterize the lower limit of the number of keys required to be collected for a single operation to prevent accidental touches (such as a 1-bit key is prone to misoperation). Accordingly, the parameter type and / or parameter number corresponding to the preset communication interface can be determined in the following manner: when the interface type of the preset communication interface is a key capture type, the parameters corresponding to the preset communication interface are determined to include: key capture type parameters; wherein the number of key combination bits supported by the key capture type parameters is greater than or equal to 2; and the parameter verification rules of the key capture type parameters can be determined according to the user type of the calling user.

[0061] Among them, in order to prevent users from inputting invalid keys, and to prevent the verification rules from being out of touch with the business scenarios, parameter verification rules can also be configured for key capture type parameters. During specific implementation, the parameter verification rules for key capture type parameters can be determined based on the operation type of the preset atomic operation and / or the user type corresponding to the call parameter. For example, if the operation type of the preset atomic operation is used to input a mobile phone number, the verification rule is determined based on the number of digits in the mobile phone number; if the operation type of the preset atomic operation is used to input an ID card number, the verification rule is determined based on the number of digits in the ID card number. For another example, the user's historical business records can be determined based on the user type corresponding to the call parameter, and the verification rules can be configured based on the number of the user's historical business records. For example, if the number of the user's historical business records is determined to be N based on the user type corresponding to the call parameter, then for the atomic operation of the historical business record query type, the following verification rule can be configured: the input numeric value is not greater than N, where N is a natural number.

[0062] This approach enables intelligent adaptation of interface parameters through a dual constraint mechanism: voice broadcast parameters can accommodate multiple modes, including static and dynamic broadcasts; and key capture parameters can dynamically configure their value ranges and validation rules based on business scenarios, addressing the rigidity of parameters in traditional systems. In summary, this approach enables multimodal parameter support, enabling a single operation type to support multiple data sources. For example, in a voice broadcast scenario, audio content from audio parameters can be combined with text content from text parameters. Text parameters can be used to determine user profile information in text form, such as the user's name, identity, and attributes, facilitating text-to-speech processing tailored to the current user's profile. This allows for dynamic adjustment of voice broadcast content, ultimately achieving the goal of broadcasting different content for different users. Furthermore, validation rules can be dynamically adjusted based on user identity, further enhancing validation effectiveness. Furthermore, in key input scenarios, pre-setting the number of key combinations allows for the prevention of accidental touches through multi-digit key combinations. Furthermore, the number of key combinations can be flexibly configured based on the current business scenario, flexibly adapting to input requirements in different scenarios.

[0063] In an optional implementation, multiple rounds of communication may be performed between the computer telecommunications integration device and multiple third-party devices. Accordingly, when screening third-party devices based on matching routing table entries and sending control instructions to the third-party devices, this can be achieved by: screening at least one third-party device from the multiple third-party devices based on the matching routing table entries, and sending a first control instruction to the at least one screened third-party device. Accordingly, after obtaining response data based on the parsing results, the following steps are further performed: determining the execution device corresponding to the response data based on the data type of the response data; if the execution device corresponding to the response data is a multimedia server, generating a call instruction corresponding to the response data; if the execution device corresponding to the response data is any third-party device among the multiple third-party devices, generating a second control instruction corresponding to the response data, sending the second control instruction to any third-party device, and, for the response data returned by any third-party device, determining the execution device corresponding to the response data based on the data type of the response data, until the execution device corresponding to the response data is a multimedia server. It can be seen that in this method, the multimedia server only needs to process the final call instruction. If the computer-telecommunications integration device needs to perform multiple rounds of interaction with at least one of multiple third-party devices, it can be achieved only between the computer-telecommunications integration device and the third-party device without the participation of the multimedia server, thereby greatly reducing the overhead and processing time of the multimedia server.

[0064] In summary, this method can determine the business semantic classification of the response parameter by determining the parameter type of the response parameter in the response message: for example, if the parameter type is a media control type (such as a play / recording instruction, etc.), the corresponding execution device is determined to be a multimedia server, and accordingly, a call instruction is sent to the multimedia server so that the multimedia server executes call-related processing logic; if the parameter type is a business control type (such as a risk control verification instruction, etc.), the corresponding execution device is determined to be a third-party device, and accordingly, a control instruction is sent to the third-party device so that the third-party device performs corresponding processing based on the received control instruction, and returns response data according to the processing result.

[0065] Optionally, to reduce communication overhead between the multimedia server and the third-party device, multiple rounds of interaction can be performed between the computer-telecommunications integration device and the same third-party device. Accordingly, after determining the execution device corresponding to the response parameter based on the parameter type of the response parameter, if the execution device corresponding to the response parameter is determined to be a previously screened third-party device, a second control instruction is sent to the previously screened third-party device. The second control instruction can be an internal process continuation instruction of the third-party device (e.g., adding a key collection instruction after a voice playback instruction), and its instruction structure can inherit the context of the initial call parameters. Accordingly, the response parameters in the response message returned by the third-party device are obtained, and the step of determining the execution device corresponding to the response parameter based on the parameter type of the response parameter is repeated until the execution device corresponding to the response parameter is the multimedia server. For example, in a loop-driven process, the third-party device returns a response parameter of a business logic type (e.g., a parameter for collecting a password). Accordingly, the computer-telecommunications integration device determines that the execution device corresponding to the response parameter is still the third-party device and generates a second control instruction (e.g., an instruction for entering a 6-digit password) to cause the third-party device to continue completing the secondary response (e.g., returning the actual password value entered by the user). When the parameter type of the response parameter returned by the third-party device is a media control type, the computer telecommunication integration device will send a call instruction to the multimedia server.

[0066] This approach enables intelligent traffic diversion based on parameter types and implements a loop-driven instruction mechanism to achieve dynamic splicing and autonomous closure of service links, thus resolving the rigidity of hard-coded processes in traditional architectures. This approach automatically selects execution nodes based on parameter semantics, allowing third-party devices to autonomously continue the process, while the multimedia server only needs to handle the final atomic operation. This avoids the complex interactions caused by the traditional approach requiring the multimedia server to participate in multiple intermediate processes.

[0067] For example, in a bank transfer service, assuming that the third-party device is an IVR device, its return parameters are as follows: {"type":"business logic type","action":"confirm_amount"} (amount to be confirmed). Correspondingly, the computer-telecommunications integration device determines that the corresponding execution device is still the above-mentioned IVR device, and therefore sends the following second control instruction: {"prompt":"Please say the transfer amount"}. The IVR device returns through voice recognition: "amount":"XXX yuan". In addition, the IVR device returns the media control type parameter: "play":"transfer_success.wav", so the computer-telecommunications integration device generates a call instruction and hands it over to the multimedia server for broadcast processing. It can be seen that in this application, if multiple rounds of interaction need to be performed between the computer-telecommunications integration device and the third-party device, it can be achieved only between the computer-telecommunications integration device and the third-party device, without the participation of the multimedia server (the multimedia server only needs to process the final atomic media operation). In the traditional method, the multimedia server is highly coupled with the third-party device. The multimedia server not only needs to determine the routing results of multiple third-party devices on its own, but also needs to interact with the third-party devices in each round of interaction, resulting in each third-party device needing to communicate and adapt with the multimedia server.

[0068] Optionally, to reduce communication overhead between the multimedia server and the third-party device, multiple rounds of interaction can be performed between the computer-telecommunications integration device and at least two third-party devices. Accordingly, after determining the execution device corresponding to the response parameter based on the parameter type of the response parameter, the following steps are further performed: if the execution device corresponding to the response parameter is another third-party device selected from the plurality of third-party devices (different from the third-party device previously screened), a second control instruction is sent to the other third-party device. The other third-party device is different from the previously screened third-party device and can be dynamically selected based on the parameter type of the response parameter (e.g., a first call to an IVR device, a second call to a work order device, or a manual customer service device). The second control instruction can be a cross-device instruction that carries the context of the initial request (caller ID / session ID). Both the second control instruction and the first control instruction belong to the general category of service control and therefore need to be executed by the third-party device. However, the second control instruction and the first control instruction have different specific instruction functions (i.e., they correspond to different control functions). The above approach, through a cross-device scheduling mechanism, enables dynamic relay execution of complex service flows, thereby breaking through the capabilities of a single device. Among them, a single business link can be completed by multiple devices in collaboration, and the execution context can be automatically transferred. The multimedia server only needs to uniformly process the final output.

[0069] For example, in a scenario where multiple departments collaborate to handle user needs, the previously selected third-party device could be a basic agent system, and another third-party device could be an environmental expert agent system. During the initial response process, based on the response parameters returned by the basic agent system, it is determined that subsequent expert intervention is required and that a transfer to the environmental protection department is necessary. Therefore, the environmental expert agent system is selected from multiple third-party devices to provide environmental expert services to the user through the environmental expert agent system. Thus, the above-mentioned service chain includes multiple rounds of interaction between the computer-telecommunications integration device and multiple third-party devices. This entire interaction process does not require the participation of a multimedia server, significantly improving overall system efficiency. Furthermore, the above-mentioned solution can also be applied to other business scenarios requiring the collaboration of multiple departments, such as local customer service, remote customer service collaboration, and other business scenarios. Alternatively, it can also be applied to scenarios where multiple functional types of third-party devices collaborate to process, such as scenarios that require the sequential invocation of an IVR device, a robotic device, and a human customer service device.

[0070] In an optional implementation, the method is performed by a computer-telecommunications integrated device, and the plurality of third-party devices may include at least two of the following: a third-party device for implementing interactive voice response, a third-party device for implementing manual response, a third-party device for implementing voice messaging, and a third-party device for implementing robotic services. The interactive voice response device may include various self-service systems that implement keystrokes or voice recognition (e.g., a bank credit card inquiry menu); the manual response device may be a call center module (e.g., a hotline agent desk) that supports functions such as agent check-in, call control, and screen pop-up; the voice messaging device may implement voice recording, storage, and asynchronous playback (e.g., a telephone voicemail); and the robotic service device may be an NLP-based intelligent conversation engine (e.g., an automated question-and-answer robot).

[0071] In the case where there are multiple multimedia servers, each of the multiple multimedia servers can communicate with the computer-telecommunications integration device through different communication methods. For example, different multimedia servers can use proprietary protocols for communication, such as FreeSWITCH can use the ESL protocol, and cloud media services can use the gRPC protocol. Accordingly, in the present application, when the business logic corresponding to the third-party device is updated, the preset communication interface between the third-party device and the computer-telecommunications integration device can be updated according to the updated business logic.

[0072] Optionally, the computer telecommunications integration device further includes: an interface database for storing multiple preset communication interfaces; accordingly, the above method also includes the following operations: when it is detected that the business logic corresponding to the third-party device is updated, the preset communication interface in the interface database is updated according to the updated business logic, so that the third-party device returns a response message through the updated preset communication interface.

[0073] It can be seen that the number of interfaces and interface functions of the preset communication interface in this application can be dynamically updated according to the business functions of the third-party device. In addition, since multiple third-party devices themselves do not need to communicate with the multimedia server, after the third-party device is updated, it is only necessary to update the preset communication interface provided by the computer telecommunications integration device, without making any changes to the multimedia server. It can be seen that this application realizes the decoupling between the third-party device and the multimedia server, making the update operation of the third-party device independent of the multimedia server. The above-mentioned architectural design method has at least the following advantages:

[0074] (1) In the related art, because multiple third-party devices need to communicate directly with the multimedia server, any update of any third-party device will affect the execution logic of the multimedia server, resulting in the routing strategy and script execution strategy in the multimedia server being very complex and requiring frequent updates. The present application decouples the third-party device from the multimedia server, allowing the multimedia server to communicate only with the computer telecommunications integration device, thereby avoiding the cost of adapting the multimedia server to multiple third-party devices separately.

[0075] (2) In related art, if there are multiple multimedia servers in a call system, any third-party device needs to communicate with each multimedia server separately. Therefore, each third-party device needs to adapt to multiple multimedia servers, which makes the execution logic and communication strategy of the third-party device very complicated. This application decouples the third-party device from the multimedia server, so that the third-party device only needs to communicate with the computer telecommunications integration device, thereby avoiding the cost of the third-party device adapting to multiple multimedia servers separately.

[0076] In one optional implementation, the call event sent by the multimedia server is a single type of call event that applies to multiple call parameters. This single event type can carry any combination of parameters, allowing multiple call parameters to be mapped to the same single-point event trigger. Accordingly, obtaining call parameters from a call event sent by the multimedia server can be accomplished by: In response to a single type of call event sent by the multimedia server according to a first routing policy, obtaining call parameters from the single type of call event; wherein the first routing policy is configured to trigger a single type of call event for multiple call parameters. The first routing policy can be implemented using a filtering rule set built into the multimedia server. The first routing policy on the multimedia server can be a wildcard routing policy that actively ignores parameter differences through matching methods such as wildcards and triggers a unified event as long as basic communication conditions (such as signal connection) are met. In specific implementations, the first routing policy can be implemented using a full-parameter wildcard mode. For example, the multimedia server triggers the same event type for all valid calls (including any combination of parameters such as calling number / called number / video / audio). The technical essence of this approach is to mask parameter differences and maintain only the uniformity of event triggering. Accordingly, a single type of call event can be triggered through a unique standardized event interface provided by the multimedia server. Its event type identifier is generally constant, and actual service parameters (such as call parameters) can be encapsulated in the event payload, distinguishing different service scenarios through data fields. In addition, when executing call processing, the multimedia server can perform atomic media call processing based on the call instruction. Atomized media call processing includes at least one of the following: call transfer, media playback, recording control, and signal tone generation.

[0077] Among them, atomic media call processing means: only executing a single media action (such as playing audio). For example, the multimedia server only executes media flow control operations, and the media flow control operations do not include business logic decisions. Through the atomic media call processing method, the multimedia server is constrained to an execution terminal without decision-making capabilities, thereby greatly simplifying the execution overhead of the multimedia server and improving execution efficiency. In a specific scenario, in order to facilitate the implementation of atomic operations, an operation whitelist can be configured for the multimedia server. For example, the multimedia server can only open the following four basic operation interfaces: (1) call transfer (physical line transfer); (2) media playback (one-way audio / video stream output); (3) recording control (start / stop recording file generation); (4) signal tone generation (standard signaling tone output).

[0078] To facilitate understanding, the following uses an example to describe the technical implementation details of the above embodiment. First, some of the concepts involved in this example are explained:

[0079] IVR: (Interactive Voice Response) is a technology that interacts over the telephone and allows users to navigate the system through voice commands or keystrokes.

[0080] FreeSwitch: An open source telephone softswitch platform that supports real-time audio and video communications and conferencing, and supports multiple communication protocols such as SIP and WebRTC.

[0081] CTI: (Computer Telecommunication Integration) fully utilizes the multiple functional integration of the Internet, telecommunications networks and computer networks, as well as various existing advanced information technology means, and integrates it with the enterprise to form a complete integrated information service telephone management system (such as: task management, call management, traffic distribution, agent management, call reports, routing management, etc.).

[0082] EVENT: It is the event-driven system within FreeSwitch, which enables real-time sending and receiving of events to external programs; it supports broadcasting, and event production can be achieved through the core or external modules; common events include: CHANNEL_CREATE, CHANNEL_ANSWER, CHANNEL_PARK, CHANNEL_HANGUP, etc.

[0083] ESL: (Event Socket Library) is a mechanism provided by FreeSwitch that allows external applications to communicate with FreeSwitch through TCP / IP connections. It supports asynchronous and synchronous communication and provides bindings for multiple languages, including C, C++, Python, Java, PHP, etc. Through ESL, developers can send commands, receive events and manage calls; for example: hang up the call, transfer the call, hold the call, force insertion, force disconnection, etc.

[0084] Dialplan: It is a module in FreeSwitch responsible for routing calls (equivalent to a routing table), which determines and affects the flow of calls.

[0085] ACD (Automatic Call Distribution) is a key component in CTI. Its main function is to automatically assign incoming calls to appropriate agents according to specific rules or perform other processing, such as queuing or leaving messages.

[0086] Figure 3 FIG. 1 shows an architecture diagram of a call system in related art. Figure 3As shown, the call system in the related art includes: a soft switch platform, a computer telecommunications integration device (CTI), an agent server, an interactive voice response system (IVR), and a robot answering system. Among them, the soft switch platform can be the FreeSwitch mentioned above. The soft switch platform internally includes: a routing table, an event interface, an interactive communication script, a robot communication script, etc. Among them, the routing table inside the soft switch platform can be represented by the Dialplan mentioned above, the event interface can be the EVENT Socket interface, the interactive communication script can be a lua script for communicating with the interactive voice response system, and the robot communication script can be a lua script for communicating with the robot answering system. Among them, the interactive communication script and the interactive voice response system can communicate in two directions through the http protocol. Similarly, the robot communication script and the robot answering system can also communicate in two directions through the http protocol.

[0087] The computer-telecommunications integration device (CTI) may further include a CTI interface (such as CTI-Link), an ACD module, and the like. The CTI-Link and the EVENT Socket interface can communicate bidirectionally via the ESL mechanism. The computer-telecommunications integration device can communicate with an agent server. The softswitch platform corresponds to the multimedia server in this application. The computer-telecommunications integration device corresponds to the computer-telecommunications integration device in this application. The agent server, interactive voice response system (IVR), and robotic response system all correspond to specific implementations of the third-party device in this application.

[0088] exist Figure 3 In the system architecture shown, FreeSwitch needs to configure different dialplans according to the destination addresses (Destination) contained in different call requests. In addition, in the dialplan, it is necessary to use the action tag (action tag) to call the Lua application (an application based on Lua script) in FreeSwitch to execute a custom Lua script (the script can call the API / APP in FreeSwitch), or directly call other APPs through the aciton tag to implement various third-party systems (i.e. Figure 4 Various third-party devices in the system) such as phone calls, IVR, audio playback, ESL sending, etc. The above-mentioned methods in the related art have at least the following drawbacks:

[0089] (1) FreeSwitch needs to dynamically maintain the dialplan, which results in a bloated and complex routing table, high operational difficulty, and affects routing efficiency for calls. For example, in the routing table, it is necessary to accurately match the various parameters in the call request (such as the caller, the called party, the call time, etc.), and pre-set multiple routing branches such as voicemail, point-to-point callback, customer service hotline, and transfer to XXX skill group based on the matching results. It can be seen that FreeSwitch, as a media service, needs to complete complex routing logic judgments. In addition, for each judgment result, FreeSwitch also needs to trigger different types of events, resulting in a wide variety of events (i.e., ESL events) between FreeSwitch and CTI.

[0090] (2) FreeSwitch, a media service, is deeply bound and highly coupled with the business side, which is not conducive to rapid iteration. Figure 3 As shown in the figure, FreeSwitch needs to call different Lua scripts separately to achieve communication with different third-party devices (such as interactive voice response systems and robot response systems). In actual situations, FreeSwitch may need to perform multiple rounds of interaction with the same third-party device, or FreeSwitch needs to perform multiple rounds of interaction with different third-party devices in succession. In this case, FreeSwitch needs to repeatedly call Lua scripts to achieve communication processing with different third-party devices. It can be seen that FreeSwitch is deeply coupled with third-party devices, resulting in high communication costs between the two, and after any device is updated, the other device needs to be updated synchronously, which makes the system update operation complicated.

[0091] (3) Some methods in the Lua scripts in FreeSwitch use blocking mode, which means that other tasks cannot be executed until the waiting conditions are met. Therefore, blocked sessions occupy system resources, reduce the system's concurrency capabilities, and lead to a decrease in the overall performance of the call system. In addition, the interaction between FreeSwitch's media service and CTI is also complex.

[0092] For example, in the related art, various extensions can be configured in the FreeSwitch routing table (different extensions have different matching hit conditions), and the action tag in the extension (i.e., routing table entry) can be used to schedule FreeSwitch applications. In particular, a custom Lua script can be executed through a Lua application. The Lua script interacts with a third-party device (also known as a third-party system) via HTTP. Based on the "action" returned by the third-party device, the Lua script directly schedules the FreeSwitch-related API to complete the execution of relevant instructions, implementing functions such as audio broadcast, keystroke capture, sending various ESL events, and call forwarding. At the same time, CTI also needs to monitor multiple types of ESL events and perform different operations for different types of ESL events, such as agent ACD. As can be seen, the routing table configuration in the related art is complex, requiring a separate routing table entry (i.e., an extension) for each called number / transfer short number, resulting in a very large routing table and increasing the time consumed by FreeSwitch during the routing phase. Furthermore, the interaction between media services and CTI is complex, requiring the pre-definition of various non-system ESL events to implement business logic control. Furthermore, a large amount of business logic must be carried out by Lua scripts. Every business change may involve configuration changes in routing tables, Lua scripts, and other aspects, significantly reducing media service performance.

[0093] In order to solve the above problems, this example proposes an improved calling system and provides a call control method based on the improved calling system. Figure 4 The diagram shows the architecture of the improved call system in this example. Figure 4 The multimedia server in Figure 3 The soft switch platform in the system can be implemented through FreeSwitch or other forms. Figure 4As shown, in this example, the following simplifications are made to the functions of the multimedia server: (1) The original complex routing table is replaced with a wildcard routing table. The routing query process is simple and efficient, and there is no need to trigger multiple types of events. Instead, only one type of event needs to be triggered uniformly, which simplifies the routing process and unifies the event type. (2) The multimedia server does not need to communicate directly with the third-party device. The communication process between the two is all transferred by the computer telecommunications integration device (CTI). Therefore, the multimedia server does not need to maintain multiple Lua scripts corresponding to third-party devices with different functions. Accordingly, the functions originally implemented by the Lua script are provided through CTI. In addition, the following improvements are made to CTI: According to the functions of the Lua script in the multimedia server and the communication requirements of each third-party device, multiple preset communication interfaces are provided, such as pre-packaged RPC (Remote Procedure Call) interfaces, so that the third-party device and / or the multimedia server can directly call the preset communication interface for communication, simplifying the communication cost between different devices. For example, in the wildcard routing table, multiple call parameters can be matched through wildcards, so that multiple call parameters can trigger the same type of call event uniformly. For another example, each third-party device can directly communicate with the ACD module in CTI by calling the RPC interface provided by CTI.

[0094] From this we can see that Figure 4 The solution in this paper adopts at least the following optimization methods: (1) de-luaizing media services, transferring process rules, logical judgment and other operations to CTI or third-party devices; (2) simplifying the media service and CTI event-driven model, and adopting a single event-driven model for call distribution; (3) simplifying the routing table, and transferring routing operations and configuration processing to the omni-channel ACD module in CTI.

[0095] First, the solution in this example has made at least the following improvements at the system configuration level:

[0096] (1) The dialplan in the multimedia server was simplified to a single, universal extension, eliminating the numerous existing Lua APP extensions. Furthermore, the universal extension action was simplified to executing a park event. The park event is triggered by the media server application, similar to Lua.

[0097] (2) Configure specific routing rules on the CTI side: for example, called number 1 is connected to the IVR Studio Server (a specific form of interactive voice response system); called number 2 is connected to the Agent Server (a specific form of agent server); called number 3 is connected to the Robot Server (a specific form of robot response system); called number 4 is connected to the Voicemail Server (a specific form of voice mailbox system).

[0098] (3) Configure corresponding business rules and processes for third-party systems such as third-party devices: For example, configure the IVR process in the IVR Studio Server and bind the called number; configure the transfer rules in the Agent Server and bind the agent skill group short number. For example, you can configure an IVR process in the IVR Studio Server and bind it to a binding number such as 30061. For another example, you can configure the transfer short number mapping relationship of the agent skill group in the Agent Server. Specifically, you can configure a corresponding transfer short number for each skill group.

[0099] Secondly, the solution in this example has made at least the following improvements in terms of technical implementation:

[0100] (1) Traffic routing based on a single type of call event (e.g., CHANNEL_PARK event) on the multimedia server: After the call reaches the routing stage, the multimedia server does not need to perform actual routing judgment. Instead, it only needs to send a single system-type CHANNEL_PARK ESL event, and the CTI drives subsequent actions based on this event. At the same time, the CTI side does not need to subscribe to multiple custom types of ESL events (in related technologies, due to the existence of multiple Lua scripts, and Lua scripts triggering multiple custom events, such as transfer to agent events, transfer to extension number events, transfer to IVR events, message leaving events, etc., the CTI side needs to subscribe to multiple custom types of ESL events). Instead, it only needs to subscribe to one type of ESL event, thus achieving message-driven standardization.

[0101] (2) All third-party systems, such as third-party devices, can actively call the services provided by the ACD module in CTI when configuring or changing their own information, thereby registering with CTI and reporting instances to ensure that the configured or updated third-party devices can communicate with CTI. For example, after the third-party device reports its own configuration information or change information to CTI, CTI can provide a corresponding RPC interface based on the configuration information or change information of the third-party device, so that the third-party device can communicate with CTI by calling the RPC interface. In short, the interface configuration rules such as the interface functions and interface parameters of the RPC interface provided by CTI can be dynamically updated based on the configuration information or change information of the third-party device.

[0102] (3) Since the multimedia server no longer contains Lua scripts, the various business logics originally implemented by Lua scripts need to be implemented by the business system. Accordingly, CTI-Link can use the existing communication link (ESL link) between the multimedia server to execute APIs and apps, encapsulating all the required media service APIs and apps into RPC interfaces and providing them to third-party systems and other devices for invocation.

[0103] (4) In the third-party system, based on the original RPC interface provided by CTI-link, an RPC interface with certain atomic capabilities (with transaction status) can be encapsulated for use by business personnel or for calls by downstream systems.

[0104] For example, normally, the RPC interface encapsulated by CTI-link is only implemented based on the original API and APP capabilities of the multimedia server, and cannot directly implement business logic that has relatively certain business significance. In this example, in order to facilitate calling, a custom RPC interface can be pre-encapsulated through CTI-link. Suppose the business needs to implement the broadcast processing of the welcome message, such as broadcasting "Dear XXX, hello! Welcome to call our customer service hotline." Among them, XXX represents the customer's name, and the specific value changes dynamically. It is impossible for the company to prepare an audio file corresponding to each customer's name in advance. Therefore, the TTS broadcast function can be called in this interface. In order to facilitate calling, it is necessary to pre-encapsulate a custom RPC interface, which is used to implement the broadcast processing of the welcome message, wherein the input parameters of the interface can include: synthesized text + fixed audio. For example, the custom RPC interface specifically includes the following information:

[0105] File playback RPC sub-interface 1, input parameter: audio file address;

[0106] TTS playback RPC sub-interface 2, input parameter: synthesized text.

[0107] Correspondingly, through this custom RPC interface, two calls can be automatically implemented through the following code:

[0108] func welcome message broadcast interface (parm1 text, parm2 audio file)

[0109] {

[0110] cti-link tts playback interface (text)

[0111] cti-link file playback interface (audio file)

[0112] }

[0113] (5) A new distribution layer design is added within the ACD module of CTI: When a call request reaches CTI, it first enters the new distribution layer for broad category routing (i.e., routing for multiple third-party devices based on the preset business routing strategy). After matching the corresponding routing rules, it is handed over to the lower-level service for logical processing. At the same time, in the ACD module, through the existing seats and the call distribution RPC interface of each third-party system, when the call needs to be redistributed, the third-party system can directly initiate an RPC call, ensuring that the underlying media service is unaware and also realizing the ACD module's call distribution to the third-party system.

[0114] In addition, the solution in this example has at least the following improvements at the execution level: when the call arrives at the multimedia server, the multimedia server creates a session channel (i.e., a channel). After completing the channel creation and a series of initialization tasks, the session enters the routing stage, and matches the conditions through the wildcard routing table in the multimedia server (the conditions of the wildcard routing table are wildcard, so it will definitely be hit). After the routing is completed, the application park in FreeSwitch is executed, thereby triggering the CHANNEL_PARK event (i.e., a call event) and broadcasting it. After the CTI-link module receives the ESL event (which needs to be subscribed in advance), it parses the message header and message body in the event and forwards it to the ACD module. The ACD module matches the routing rules according to the specific fields in the message body content (based on the business routing policy). After hitting the matching result, it generates the first business control instruction and forwards it to the matching third-party device. After receiving the first service control command, the third-party device performs a series of internal rule checks and then calls the corresponding RPC interface of CTI-link to perform the relevant actions (such as answering the call, playing audio, transferring to a human operator, or transferring the call), thus establishing a "dialogue" with the customer and returning a response message to CTI. CTI-link determines the parameter type of the response message based on the corresponding RPC interface, generates the corresponding call instruction, and then sends the call instruction to the multimedia server via the ESL channel.

[0115] Among them, in actual business scenarios, the same third-party device is often unable to provide all the business functions required for customers to complete business services, and therefore needs to be transferred to other third-party devices for services (i.e., traffic redistribution). In this case, the third-party device A directly sends a response message to the ACD module, and carries parameter information for indicating the traffic allocation RPC interface corresponding to the third-party device B in the response message, and also carries accompanying data for traffic redistribution. The ACD module redistributes the traffic to the third-party device B based on the response message and the accompanying data. At this time, the user is handed over to the third-party device B for service. The third-party device B calls the RPC interface corresponding to the CTI-link according to the customer input or process rule settings to complete the relevant actions, thereby realizing a "dialogue" with the customer, and repeating the cycle until the service is completed and the phone is hung up.

[0116] The following example illustrates the process of a user calling an enterprise hotline (IVR) and triggering a call to an agent via a keystroke. The process includes the following steps:

[0117] (1) A user calls the hotline number XXXXX, and the call is transmitted through the network to a multimedia server (such as a media server) in the call system.

[0118] (2) The multimedia server creates a channel and performs routing (hitting the wildcard routing extension).

[0119] (3) The multimedia server executes the media service park application to trigger a CHANNEL_PARK event, which can carry various call parameters such as the original caller, the current caller, the caller ID, and the event time.

[0120] (4) CTI-link obtains the call parameters in the above events, such as the original caller, current caller, call-ID, event time, etc., and forwards them to the ACD module.

[0121] (5) After receiving the call request generated based on the above call parameters, the ACD module performs routing matching at the distribution layer according to the preset service routing strategy. Assuming that the current called number matches the interactive voice response system, the relevant event message field is forwarded to the interactive voice response system.

[0122] (6) The interactive voice response system queries the internal IVR process based on the called number. Here, the process is assumed to be: play the welcome message - main menu button selection (press 1 for sub-service; press 2 for sub-service 2; press 0 for expert seat transfer).

[0123] (7) The interactive voice response system calls the corresponding RPC interface in CTI-link to broadcast the welcome message.

[0124] (8) After receiving the RPC interface call request, CTI-link dispatches the playbackAPP ​​in the multimedia server to play the sound file. After the file is played, a message is returned to notify the interactive voice response system.

[0125] (9) The interactive voice response system further calls the RPC interface in the CTI-link for performing voice playback and number collection processing to broadcast the menu, while waiting for user input and capturing the keystrokes entered by the user.

[0126] (10) CTI-link receives a call request for the RPC interface used to perform audio playback and digit collection processing, dispatches the play_and_get_digits APP (audio playback application interface) in the multimedia server to play the sound file, and performs key capture. Assuming that the user enters the key "0" according to the prompt, the captured key message is returned and notified to the interactive voice response system.

[0127] (11) The interactive voice response system calls the Agent Server RPC interface in the ACD module (the input parameter of this interface includes the skill group short number of the target agent) to facilitate manual transfer (it can also be transferred to any type of third-party device such as the message system, fax system, AI agent assistant system, etc.).

[0128] (12) After receiving the above call request, the ACD module performs routing matching at the distribution layer according to the preset service routing strategy, matches the current called number to the Agent Server, and forwards the relevant event message fields to the Agent Server.

[0129] (13) The Agent Server searches for idle seats under the expert skill group according to the preset rules, and dispatches the call RPC interface in the CTI-link (the interface is used to pass the registration account of the idle agent) based on the search results.

[0130] (14) After receiving the call request for the above-mentioned call RPC interface, CTI-link dispatches the original API in the multimedia server (the called party is set to the agent's registered account) to call the agent. After the agent answers the call, the user and the agent are bridged and the call begins.

[0131] In summary, this example has at least the following beneficial effects: (1) decoupling media services from business, which is more conducive to engineering iteration; (2) de-luaizing media services, which improves media service performance; tasks can be executed in parallel throughout the entire life cycle of a session, which reduces the complexity and improves the feasibility of implementing some high-level functions; (3) reducing the complexity of interactions between media services and CTI; through a single event-driven model, custom ESL event drivers are eliminated, making event specifications more standardized; (4) call distribution can be completed between the three-party system (i.e., the business execution module) and the ACD module and CTI-link, without the media service being aware of it; (5) the enhanced capabilities of the ACD module enrich the call distribution capabilities.

[0132] It is understood that the above-mentioned various method embodiments mentioned in this disclosure can be combined with each other to form combined embodiments without violating the principle logic. Due to space limitations, this disclosure will not go into details. It is understood by those skilled in the art that in the above-mentioned methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0133] In addition, the present disclosure also provides a call control device, an electronic device, and a computer-readable storage medium, all of which can be used to implement any call control method provided by the present disclosure. The corresponding technical solutions and descriptions are referred to the corresponding records in the method section and will not be repeated here.

[0134] Figure 5 This is a block diagram of a call control device provided by an embodiment of the present disclosure, wherein the call control device can be applied to the above-mentioned computer telecommunication integrated device.

[0135] Reference Figure 5 , an embodiment of the present disclosure provides a call control device, the call control device comprising:

[0136] An acquisition module 51 is adapted to acquire, in response to a call event triggered by a multimedia server according to a first routing policy, a call parameter in the call event; the first routing policy is used to trigger the same type of call event for multiple different call parameters;

[0137] a matching module 52 adapted to match the call parameters in the call event with a plurality of routing table entries in a second routing policy, and determine a routing table entry that matches the call parameters in the call event from the plurality of routing table entries; wherein the second routing policy is configured to trigger different types of call events for the plurality of different call parameters, and each routing table entry in the second routing policy corresponds to a matching condition;

[0138] a sending module 53 adapted to filter third-party devices according to the matched routing table entries, send control instructions to the third-party devices, and obtain response data from the third-party devices;

[0139] The calling module 54 is adapted to generate a calling instruction corresponding to the response data, wherein the calling instruction is used to instruct the multimedia server to execute a call process.

[0140] In an optional implementation, the matching module is specifically adapted to:

[0141] selecting at least two call parameters from a plurality of call parameters in the call event;

[0142] For any routing table entry, matching the at least two call parameters with at least two matching conditions in the routing table entry respectively;

[0143] Among them, the at least two call parameters include at least two of the following: calling class call parameters, called class call parameters, call type parameters, and call period class parameters; and the at least two matching conditions include at least two of the following: matching conditions corresponding to calling class call parameters, matching conditions corresponding to called class call parameters, matching conditions corresponding to call type parameters, and matching conditions corresponding to call period class parameters.

[0144] In an optional implementation, the sending module is specifically adapted to:

[0145] receiving, via a preset communication interface, a response message returned by the third-party device;

[0146] Determining the parameter type and / or parameter quantity corresponding to the preset communication interface according to the interface type of the preset communication interface;

[0147] The response message is parsed according to the parameter type and / or parameter quantity corresponding to the preset communication interface, and the response data is obtained according to the parsing result.

[0148] In an optional implementation, the sending module is specifically adapted to:

[0149] In the case where the interface type of the preset communication interface is a voice broadcast type, determining the parameters corresponding to the preset communication interface includes: audio parameters and text parameters; wherein the audio parameters are used to perform voice broadcast according to the acquired audio data; and the text parameters are used to perform voice broadcast according to the acquired text data;

[0150] In the case where the interface type of the preset communication interface is a key capture type, determining the parameters corresponding to the preset communication interface includes: key capture class parameters; wherein the number of key combination digits supported by the key capture class parameters is greater than or equal to 2; and the parameter verification rules of the key capture class parameters are determined according to the user type of the calling user.

[0151] In an optional implementation, the sending module is specifically adapted to: screen a third-party device from a plurality of third-party devices according to the matched routing table entry, and send a first control instruction to the screened third-party device;

[0152] determining, according to a data type of the response data, an execution device corresponding to the response data;

[0153] In a case where the execution device corresponding to the response data is the multimedia server, executing the step of generating a call instruction corresponding to the response data;

[0154] In the case that the execution device corresponding to the response data is any third-party device among the multiple third-party devices, a second control instruction corresponding to the response data is generated, the second control instruction is sent to the any third-party device, and for the response data returned by the any third-party device, the step of determining the execution device corresponding to the response data based on the data type of the response data is executed until the execution device corresponding to the response data is the multimedia server.

[0155] In an optional implementation, the device is a computer-telecommunications integration device, and multiple third-party devices are respectively used to implement different types of business functions, and the multiple third-party devices include at least two of the following: a third-party device for implementing interactive voice response, a third-party device for implementing manual response, a third-party device for implementing voice messages, and a third-party device for implementing robot services; wherein, when there are multiple multimedia servers, the multiple multimedia servers communicate with the computer-telecommunications integration device through multiple communication methods.

[0156] In an optional implementation, the computer-telecommunications integration device further includes an interface database for storing multiple preset communication interfaces; the device also includes an update module adapted to, upon detecting an update to the service logic corresponding to the third-party device, update the preset communication interface in the interface database according to the updated service logic, so that the third-party device returns a response message via the updated preset communication interface. Furthermore, the present application also discloses a call system comprising the aforementioned call control device, a multimedia server, and multiple third-party devices.

[0157] Each module in the call control device described above may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor in a computer device in hardware form, or may be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0158] Figure 5 A block diagram of an electronic device provided in an embodiment of the present disclosure.

[0159] Reference Figure 5 An embodiment of the present disclosure provides an electronic device, which includes: at least one processor 501; at least one memory 502, and one or more I / O interfaces 503, connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 to enable the at least one processor 501 to perform the above-mentioned call control method.

[0160] Each module in the above-mentioned electronic device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0161] The present disclosure also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-mentioned call control method when executed by a processor. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0162] An embodiment of the present disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above-mentioned call control method.

[0163] It will be understood by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable storage medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium).

[0164] As is well known to those skilled in the art, the term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (such as computer-readable program instructions, data structures, program modules or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technology, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, as is well known to those skilled in the art, communication media typically contains computer-readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0165] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in the computer-readable storage medium in each computing / processing device.

[0166] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., utilizing an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions. The electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0167] The computer program product described herein may be implemented in hardware, software, or a combination thereof. In one embodiment, the computer program product is implemented as a computer storage medium. In another embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).

[0168] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0169] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0170] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0171] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of a module, program segment or instruction includes one or more executable instructions for realizing the prescribed logical function. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart, can be implemented by a dedicated hardware-based system that performs the prescribed function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0172] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A call control method, characterized in that: The method comprises: In response to a call event triggered by the multimedia server according to a first routing policy, obtaining a call parameter in the call event; the first routing policy is used to trigger the same type of call event for multiple different call parameters; matching the call parameters in the call event with a plurality of routing table entries in a second routing policy, and determining a routing table entry that matches the call parameters in the call event from the plurality of routing table entries; wherein the second routing policy is used to trigger different types of call events according to the plurality of different call parameters, and each routing table entry in the second routing policy corresponds to a matching condition; screening a third-party device according to the matched routing table entry, sending a control instruction to the third-party device, and obtaining response data from the third-party device; A call instruction corresponding to the response data is generated, where the call instruction is used to instruct the multimedia server to perform call processing.

2. The method according to claim 1, characterized in that The matching of the call parameters in the call event with the multiple routing table entries in the second routing strategy includes: selecting at least two call parameters from a plurality of call parameters in the call event; For any routing table entry, matching the at least two call parameters with at least two matching conditions in the routing table entry respectively; Among them, the at least two call parameters include at least two of the following: calling class call parameters, called class call parameters, call type parameters, and call period class parameters; and the at least two matching conditions include at least two of the following: matching conditions corresponding to calling class call parameters, matching conditions corresponding to called class call parameters, matching conditions corresponding to call type parameters, and matching conditions corresponding to call period class parameters.

3. The method according to claim 1 or 2, characterized in that The obtaining of response data returned by the third-party device includes: receiving, via a preset communication interface, a response message returned by the third-party device; Determining the parameter type and / or parameter quantity corresponding to the preset communication interface according to the interface type of the preset communication interface; The response message is parsed according to the parameter type and / or parameter quantity corresponding to the preset communication interface, and the response data is obtained according to the parsing result.

4. The method according to claim 3, characterized in that The determining, according to the interface type of the preset communication interface, the parameter type and / or parameter quantity corresponding to the preset communication interface includes: In the case where the interface type of the preset communication interface is a voice broadcast type, determining the parameters corresponding to the preset communication interface includes: audio parameters and text parameters; wherein the audio parameters are used to perform voice broadcast according to the acquired audio data; and the text parameters are used to perform voice broadcast according to the acquired text data; In the case where the interface type of the preset communication interface is a key capture type, determining the parameters corresponding to the preset communication interface includes: key capture class parameters; wherein the number of key combination digits supported by the key capture class parameters is greater than or equal to 2; and the parameter verification rules of the key capture class parameters are determined according to the user type of the calling user.

5. The method according to claim 3, characterized in that The filtering of the third-party device according to the matched routing table entry and sending the control instruction to the third-party device includes: filtering a third-party device from a plurality of third-party devices according to the matched routing table entry, and sending a first control instruction to the filtered third-party device; After obtaining the response data according to the parsing result, the method further includes: determining, according to a data type of the response data, an execution device corresponding to the response data; In a case where the execution device corresponding to the response data is the multimedia server, executing the step of generating a call instruction corresponding to the response data; In the case that the execution device corresponding to the response data is any third-party device among the multiple third-party devices, a second control instruction corresponding to the response data is generated, the second control instruction is sent to the any third-party device, and for the response data returned by the any third-party device, the step of determining the execution device corresponding to the response data based on the data type of the response data is executed until the execution device corresponding to the response data is the multimedia server.

6. The method according to any one of claims 1 to 5, characterized in that: The method is performed by a computer telecommunications integrated device, wherein a plurality of third-party devices are respectively used to implement different types of service functions, and the plurality of third-party devices include at least two of the following: a third-party device for implementing interactive voice response, a third-party device for implementing manual response, a third-party device for implementing voice messaging, and a third-party device for implementing robot service; Wherein, in the case that there are multiple multimedia servers, the multiple multimedia servers communicate with the computer telecommunication integration device through multiple communication modes.

7. The method according to claim 6, characterized in that The computer telecommunication integration device further comprises: an interface database for storing a plurality of preset communication interfaces; The method further includes: when it is detected that the service logic corresponding to the third-party device is updated, updating the preset communication interface in the interface database according to the updated service logic, so that the third-party device returns a response message through the updated preset communication interface.

8. A call control device, characterized in that: include: an acquisition module, adapted to, in response to a call event triggered by the multimedia server according to the first routing policy, acquire call parameters in the call event; The first routing strategy is used to trigger the same type of call event for multiple different call parameters; a matching module, adapted to match the call parameters in the call event with a plurality of routing table entries in a second routing policy, and determine a routing table entry that matches the call parameters in the call event from the plurality of routing table entries; wherein the second routing policy is used to trigger different types of call events according to the plurality of different call parameters, and each routing table entry in the second routing policy corresponds to a matching condition; a sending module, adapted to screen a third-party device according to the matched routing table entry, send a control instruction to the third-party device, and obtain response data from the third-party device; The calling module is adapted to generate a calling instruction corresponding to the response data, wherein the calling instruction is used to instruct the multimedia server to execute a call process.

9. A calling system, characterized in that: include: The call control device, multimedia server, and multiple third-party devices as claimed in claim 8.

10. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs executable by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the computer program implements the method according to any one of claims 1 to 7.

12. A computer program product, characterized in that The invention comprises a computer-readable code or a non-volatile computer-readable storage medium carrying the computer-readable code, wherein when the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the method according to any one of claims 1 to 7.

Images