A system and method for implementing custom call flow based on IPPBX

Abstract

The present invention belongs to the field of Internet telephony switching and discloses a system and method for implementing a customized call flow based on an IPPBX. The system includes a web terminal, middleware, and an IPPBX. The web terminal is used to obtain a user-customized call flow design for a first call number. The middleware is used to obtain the call flow design, convert the call flow design into JSON data, save the JSON data, and notify the IPPBX to update the first call number to a call flow configuration container. The IPPBX is used to receive a call request from a caller. If a second call number carried in the call request is in the call flow configuration container, the middleware is requested for the JSON data corresponding to the second call number, the JSON data is translated into a call plan, and the call flow is implemented according to the call plan. The present invention flexibly configures the call flow design and has good scalability. The IPPBX dynamically obtains the JSON data from the middleware, thereby increasing the number of configurable call flows and reducing the memory usage of the IPPBX.

Description

Technical Field

[0001] The present invention belongs to the technical field of Internet telephone exchange, and in particular relates to a system and method for realizing a user-defined call flow based on IPPBX. Background Art

[0002] An Internet Protocol Private Branch Exchange (IPPBX) is an IP-based telephone switching system used to manage telephone communications within an enterprise. It integrates voice communications into the data network, achieving seamless convergence of voice and data services. It also offers advanced features not found in traditional PBXs, such as voicemail, call forwarding, and video calling.

[0003] In related technologies, the call flow of an IPPBX is implemented based on inbound routing configuration. Specifically, DID (Direct Inward Dialing) rules and time condition rules are used to forward the caller's request to a designated destination, where the destination can be an IVR (Interactive Voice Response), queue, or ring group.

[0004] However, the above-mentioned call routing configuration method can only complete relatively limited branch operations. If the user needs more branch operations and more flexible destination configuration, it cannot be met. That is, the technical solution of the existing technology has the technical problem of not being able to meet more branch operations and not being able to flexibly configure the destination. Summary of the Invention

[0005] This invention aims to flexibly configure call flow design, reducing user learning curves and improving the efficiency of custom call flow design. It also offers excellent scalability, supporting a large number of call function components while also providing components tailored to more specialized developers. Furthermore, the IPPBX uses dynamic loading to retrieve JSON data from the middleware, increasing the number of configurable call flows and reducing the IPPBX's memory usage.

[0006] In a first aspect, an embodiment of the present invention provides a system for implementing a custom call flow based on an IPPBX, the system comprising a Web terminal, middleware, and an IPPBX;

[0007] The web terminal is used to obtain a call flow design customized by the user for the first call number, the call flow design including multiple nodes and connection relationships between the multiple nodes, each node representing a component, attribute information of each component including a component ID, a component description, and branch content, the branch content including a subcomponent ID, a requirement type, and a subcomponent description; component types are divided into basic context types and common component types, and initialization components and loop components belong to the basic context type;

[0008] The middleware is used to obtain a call flow design, convert the call flow design into JSON data, save the JSON data, and notify the IPPBX to update the first call number into the call flow configuration container;

[0009] The IPPBX is configured to receive a call request from a caller, and if a second call number carried in the call request is in the call flow configuration container, request the middleware for JSON data corresponding to the second call number, translate the JSON data into a call plan, and implement the call flow according to the call plan;

[0010] The IPPBX translates the JSON data into a call plan, including:

[0011] Determine the initialization context and loop context based on the component type in the JSON data; the initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components;

[0012] The initialization context and the loop context are translated according to a preset translation module, and the translation result is used as a call plan. The preset translation module includes the second call number, priority and component attribute information.

[0013] Optionally, the IPPBX is further configured to:

[0014] After translating the JSON data into a call plan, using the translated call plan as the call plan corresponding to the second call number, and caching the call plan corresponding to the second call number in a call flow design container;

[0015] Determine the reference count of the call plan corresponding to the second call number to 1;

[0016] If a call request carrying the second call number is received again, the call process is implemented directly according to the call plan corresponding to the second call number cached in the call process design container, and the reference count of the call plan corresponding to the second call number is increased according to the number of call requests.

[0017] Optionally, before requesting the middleware for the JSON data corresponding to the second call number, the IPPBX is further configured to:

[0018] Searching the call flow design container through the second call number to determine whether a call plan corresponding to the second call number has been cached;

[0019] If the call plan corresponding to the second call number has been cached in the call flow design container, the call flow is directly implemented according to the cached call plan corresponding to the second call number;

[0020] The reference count of the call plan corresponding to the second call number in the call process design container is increased by 1.

[0021] Optionally, the IPPBX is further configured to:

[0022] Through the call flow configuration management thread, traverse the call plans cached in the call flow design container;

[0023] For each call plan cached in the call flow design container, monitor whether the Web terminal has deleted the call flow design corresponding to the call plan; if the Web terminal has deleted the call flow design corresponding to the call plan, delete the call plan.

[0024] Optionally, the IPPBX is further configured to:

[0025] For each call plan cached in the call flow design container, determining, through the call flow configuration management thread, whether the time difference between the current time and the creation time of the call plan is greater than a preset time;

[0026] If the time difference between the current time and the creation time of a call plan is greater than the preset time, determine whether the reference count of the call plan is less than 2. If the reference count is less than 2, delete the call plan from the call process design container.

[0027] Optionally, the IPPBX is further configured to:

[0028] After receiving a call request from a caller, parsing the call request to obtain a calling number carried in the call request;

[0029] Determining whether the calling number carried in the call request is in the call flow configuration;

[0030] If the calling number carried in the call request is not in the call process configuration, the preset normal dialing process is entered.

[0031] Optionally, the IPPBX implements a call process according to the call plan, including:

[0032] Enter the initialization context and run each component in the order included in the initialization context. After each component finishes running, find the attribute information of its subcomponents and run the subcomponents. After the subcomponents finish running, run the next component of the component, and execute all components of the initialization context.

[0033] Enter the loop context, run the loop components and common components included in the loop context, and exit the loop context when the loop end component is reached.

[0034] In a second aspect, an embodiment of the present invention provides a method for implementing a custom call flow based on an IPPBX, which is applied to a custom call flow implementation system based on an IPPBX, the system comprising a web terminal, middleware, and an IPPBX. The method comprises:

[0035] The web terminal obtains a call flow design customized by the user for the first call number, the call flow design including a plurality of nodes and a connection relationship between the plurality of nodes, each node representing a component, attribute information of each component including a component ID, a component description, and branch content, the branch content including a subcomponent ID, a requirement type, and a subcomponent description; component types are divided into basic context types and common component types, and initialization components and loop components belong to the basic context type;

[0036] The middleware obtains the call flow design, converts the call flow design into JSON data, saves the JSON data, and notifies the IPPBX to update the first call number into the call flow configuration container;

[0037] The IPPBX receives a call request from the caller, and if the second call number carried in the call request is in the call flow configuration container, requests the middleware for JSON data corresponding to the second call number, translates the JSON data into a call plan, and implements the call flow according to the call plan;

[0038] The IPPBX translates the JSON data into a call plan, including:

[0039] Determine the initialization context and loop context based on the component type in the JSON data; the initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components;

[0040] The initialization context and the loop context are translated according to a preset translation module, and the translation result is used as a call plan. The preset translation module includes the second call number, priority and component attribute information.

[0041] In a third aspect, an embodiment of the present invention provides an electronic device, equipped with the system described in the first aspect, including:

[0042] at least one processor;

[0043] a memory for storing the at least one processor-executable instruction;

[0044] The at least one processor is configured to execute the instructions to run the system described in the first aspect.

[0045] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, which, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to run the system described in the first aspect.

[0046] In a fifth aspect, an embodiment of the present invention provides a computer program product, comprising a computer program, which runs the system described in the first aspect when executed by a processor.

[0047] The embodiment of the present invention provides an IPPBX-based custom call flow implementation system, comprising a web terminal, middleware, and an IPPBX. Users can customize the call flow design for any call number within the web terminal's visual interface. This call flow design includes multiple components and the connections between them. Through visual operation, flexible call flow configuration is achieved, reducing user learning curves and improving the efficiency of custom call flow design. The system also offers excellent scalability, supporting a large number of call function components while also providing components tailored to more specialized developers.

[0048] Furthermore, the middleware, acting as a bridge between the web terminal and the IPPBX, first obtains the customized call flow design from the web terminal, stores the JSON in JSON format, and updates the call number of the user-customized call flow design to the call flow configuration container through the IPPBX. After the IPPBX receives a call request, if the call number carried in the call request is in the call flow configuration container, it loads the JSON data corresponding to the call number into the middleware. The JSON data is divided into an initialization context and a loop context based on the component type in the JSON data. The initialization context and loop context are translated according to a preset translation module to obtain the customized call plan and implement the call flow according to the call plan. The IPPBX uses dynamic loading to obtain JSON data from the middleware, which increases the number of configurable call flows and reduces the IPPBX's memory usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 A schematic diagram of the overall system architecture provided by an embodiment of the present invention;

[0050] Figure 2 A schematic diagram of the interaction between a Web terminal, middleware, and an IPPBX in a custom call flow implementation system based on an IPPBX provided by an embodiment of the present invention;

[0051] Figure 3 A schematic diagram of a call flow design provided by an embodiment of the present invention;

[0052] Figure 4 A flowchart of the entire process of lifecycle management of a call plan provided by an embodiment of the present invention;

[0053] Figure 5 A schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The present invention will be described in detail below through examples.

[0055] An Internet Protocol Private Branch Exchange (IPPBX) is an IP-based telephone switching system used to manage telephone communications within an enterprise. It integrates voice communications into the data network, achieving seamless convergence of voice and data services. It also offers advanced features not found in traditional PBXs, such as voicemail, call forwarding, and video calling.

[0056] In related technologies, the call flow of an IPPBX is implemented based on inbound routing configuration. Specifically, DID (Direct Inward Dialing) rules and time condition rules are used to forward the caller's request to a designated destination, where the destination can be an IVR (Interactive Voice Response), queue, or ring group.

[0057] However, the above-mentioned call routing configuration method can only complete relatively limited branch operations. If the user needs more branch operations and more flexible destination configuration, it cannot be met. That is, the technical solution of the existing technology has the technical problem of not being able to meet more branch operations and not being able to flexibly configure the destination.

[0058] In order to solve the above technical problems existing in the prior art, the embodiment of the present invention proposes a custom call flow implementation system based on IPPBX. In order to describe the solution clearly, the overall system architecture of the embodiment of the present invention will be described below. Figure 1 As shown in the figure, the custom call process implementation system includes a web terminal, middleware, and an IPPBX. The operations and interaction processes performed by the three are as follows:

[0059] Step 1. Users can customize a call flow design for one or multiple call numbers on the web terminal as needed. This call flow design is called a Call Flow Design (CFD) in English. Users can configure one or more CFDs in the web terminal's visual interface, configure the corresponding call numbers and DIDs, and save the configuration. The call numbers can be mapped to the DIDs. A customized call flow design consists of two parts: components and branches. Components are used to process calls, such as time conditions, transfers, and playing prompts. Branches are connections between components. For example, a conditional component can have branches consisting of multiple expressions. For some components, the branch content / conditions can also be customized. Finally, users can save the customized call flow design through the web terminal's visual interface.

[0060] Step 2: The middleware requests the customized call flow design from the web terminal and verifies its validity. If it meets the requirements, it formats the customized call flow design into JSON format, obtains the JSON data, adds the JSON data to the cache, and notifies the IPPBX to update the call number in the customized call flow design to the call flow configuration. The full name of the call flow configuration is Call Flow Config, which can be abbreviated as CFC. CFC can be thought of as a container, and the call number updated to the CFC can be thought of as an object in the CFC.

[0061] Step 3: The caller dials the number through SIP signaling or physical line. After receiving the call request, the IPPBX parses the data in the call request and detects the calling number requested by the call request.

[0062] Step 4: The IPPBX searches the CFC container to see if the calling number in step 3 is in the CFC container. If the search is successful, that is, the call sign number is in the CFC container, then it proceeds to step 5. If the search fails, that is, the call sign number is not in the CFC container, then it enters the predefined normal dialing process and does not consider the calling number in the user-defined call process.

[0063] Step 5: Obtain the object in the CFC container (i.e., the call number requested by the call request). Use the call number to search the CFD container to check whether the call flow corresponding to the call number is enabled. If the search is successful, the CFD container already has a call plan corresponding to the call number cached, and proceed to Step 8. If the search fails, the CFD container does not have a call plan cached for the call number, and proceed to Step 6. At this point, the call plan corresponding to the call number needs to be obtained from the middleware.

[0064] Step 6: Get the object in the CFC container (i.e., the call number requested by the call request) and use the call number to request the corresponding JSON data from the middleware. After obtaining the JSON data, translate it into the corresponding call plan.

[0065] Step 7: Create a CFD object based on the call plan translated in Step 6 and save it to the CFD container. The reference count of the created CFD object is now 1. Furthermore, the call plan cached in the CFD container can be used for subsequent repeated call hits, reducing the number of interactions between the IPPBX and the middleware, thereby improving call efficiency.

[0066] Step 8: Execute the reference count +1 for the CFD object and jump to the call plan corresponding to the call process.

[0067] Step 9. Execute the complete call planning process.

[0068] Step 10: After the call ends, the CFD object's reference count is decremented by 1. When the CFD object's reference count reaches 0, the dial plan is recycled to free up memory. This means that after a certain period of time, if there are any unused call plans in the CFD container, the IPPBX will recycle them to reduce memory usage.

[0069] The IPPBX-based custom call flow implementation system provided by the embodiment of the present invention has the following technical effects:

[0070] 1. High flexibility: Users can use visual operation to reduce their learning cost and time.

[0071] 2. Scalability. It has good scalability, supports a large number of call function components, and also has developer components that are more professional.

[0072] 3. Improve memory usage. Unlike the original IPPBX dial plan implementation, this system uses a dynamic loading method to maximize the number of user-configurable call flows. It also manages the lifecycle of call flows to ensure that memory is cleared in a timely manner when no longer needed, thus reducing memory usage.

[0073] After describing the overall system architecture of the embodiment of the present invention, a custom call flow implementation system based on IPPBX provided by the embodiment of the present invention will be described in detail below.

[0074] like Figure 2 As shown, an IPPBX-based custom call flow implementation system provided by an embodiment of the present invention may include a Web terminal 210 , a middleware 220 , and an Internet telephone switch IPPBX 230 .

[0075] Specifically, the Web terminal 210 is used to obtain a call flow design customized by the user for the first calling number.

[0076] Among them, the call process design includes multiple nodes and the connection relationships between multiple nodes. Each node represents a component. The attribute information of each component includes component ID, component description and branch content. The branch content includes sub-component ID, requirement type and sub-component description; component types are divided into basic context types and ordinary component types. Initialization components and loop components belong to basic context types.

[0077] It should be noted that the first call number can be any call number, and the first call number can be one or more. The user can customize the call process design of any call number according to actual needs. In other words, the call process design can be one or more, and the embodiment of the present invention does not make specific limitations on this.

[0078] Specifically, components can include initialization components, reminder components, office hours components, menu components, user input components, language components, recording components, loop components, dial-by-number components, conditional components, developer components, hang-up components, and transfer components. Each component has an inherent ID attribute, and its content consists of three parameters: description (desc), order (order), and branch (branch). Branch content is further composed of three parameters: child component ID (chilid), requirement type (require), and description (desc).

[0079] Component types can be divided into two categories. One is the basic context type, which includes loop components and initialization components. When the IPPBX customizes the plan translation, different contexts are created to categorize the components contained in different areas. In addition, the components themselves are translated into template sentences and assigned to the corresponding contexts. The other type is the common component type. All components except the basic context type are common components. When the IPPBX customizes the plan translation, these components are assigned to the corresponding context and translated into template sentences. To clarify the solution description, the custom plan translation process will be described below.

[0080] by Figure 3 For example, Figure 3 A schematic diagram of a call flow design provided by an embodiment of the present invention. Figure 3 The head node is the initialization component with the description number 6900, which means that the user has customized the call flow design for 6900; then there is a loop component below. Figure 3 The other components in are all common components.

[0081] The middleware 220 is used to obtain the call flow design, convert the call flow design into JSON data, save the JSON data, and notify the IPPBX to update the first call number into the call flow configuration container.

[0082] Specifically, after the web terminal obtains the user-defined call flow design, the middleware retrieves the call flow design from the web terminal, stores it in JSON format, and notifies the IPPBX to update the first call number to the call flow configuration container. In other words, the IPPBX is notified that the user has customized the call flow for the first call number. Upon receiving the notification, the IPPBX stores the first call number in the call flow configuration. Subsequently, upon receiving a call request from the caller, the IPPBX determines whether the call request matches the call number stored in the call flow configuration. If so, the call can be processed according to the customized call flow corresponding to the call number.

[0083] IPPBX230 is used to receive the call request from the caller. If the second call number carried in the call request is in the call process configuration container, it requests the middleware for JSON data corresponding to the second call number, translates the JSON data into a call plan, and implements the call process according to the call plan.

[0084] The IPPBX translates the JSON data into a call plan, which may include the following steps: step a1 and step a2:

[0085] Step a1: Determine the initialization context and loop context according to the component type in the JSON data. The initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components.

[0086] Step a2: translating the initialization context and the ring context according to a preset translation module, and using the translation result as the call plan. The preset translation module includes the second call number, priority and component attribute information.

[0087] Specifically, if the second call number carried in the call request is in the call process configuration container, it means that the user has customized the call process of the second call number. Therefore, the IPPBX requests the JSON data corresponding to the second call number from the middleware and translates the JSON data into a call plan.

[0088] The final format of the customized call plan on the IPPBX is:

[0089] [context]

[0090] exten = number,priority(label),App(data)

[0091] exten = number,priority(label),App(data)

[0092] Among them, context is the context attribute, which describes the components included in the entire custom plan. exten = number, priority(label), App(data) can be understood as the preset translation template, and number is the number configured for the initialization component; priority is an inherent attribute, which is the priority. It starts from 1 and increases in positive order. Generally, after an incoming request is made to a custom call plan, it will start running from priority 1 in this context. After running the application with priority 1, it will run 2, 3, 4, and so on; label is the node ID of the component; App is the implementation name of each component, such as CF_Initial for the prompt tone component; data is the component data, that is, the attribute information of the component, including the component description (comp.desc), component sequence number (comp.order), and component branch (comp.branch).

[0093] Still Figure 3 For example, the head node is an Initialization component with a description number of 6900. Below it is a Loop component. The component type is divided into two contexts: an Initialization context and a Loop 1 context. The Initialization context includes the Initialization component, Menu 1 component, Loop 1 component, Hangup 1 component, and Transfer 1 component. The Loop 1 context includes the Prompt Tone 1 component and the Loop component, which can include the Loop End component.

[0094] Next, the initialization context (which can be called context_initail) and loop 1 context (which can be called context_loop) are translated separately. The translation results are as follows:

[0095]

context_initail

[0096] exten = 6900,1(initial.id),CF_Initial(data) initializes the translation result of the component;

[0097] exten = 6900,2(Menu1.id),CF_Menu(data) translation result of menu 1 component;

[0098] exten = 6900,3(Loop1.id),CF_Loop(data) Translation result of loop 1 component;

[0099] exten = 6900,4(Hangup1.id),CF_Hangup(data) Translation result of Hangup 1 component;

[0100] exten = 6900,5(Transfer1.id),CF_Transfer(data) Transfer 1 component's translation result;

[0101]

context_loop

[0102] exten = 6900,1(Prompt.id),CF_Prompt(data) Translation result of the prompt sound component;

[0103] exten = 6900,2(LoopEnd1.id),CF_LoopEnd(data) The translation result of the loop component.

[0104] As an implementation of the embodiment of the present invention, the IPPBX implements a call flow according to the call plan, which may include the following steps, namely step b1 and step b2:

[0105] Step b1: Enter the initialization context and run each component in the order of the components included in the initialization context.

[0106] Among them, after each component finishes running, the attribute information of the component's subcomponent is searched, and the subcomponent is run. After the subcomponent finishes running, the next component of the component is run, and all components of the initialization context are executed.

[0107] Step b2: Enter the loop context, run the loop components and common components included in the loop context, and exit the loop context when the loop end component is reached.

[0108] Specifically, when executing a call plan, the initialization context must first be entered and the components of the initialization context executed. After each component is executed, the subcomponent ID is retrieved from the branch.child (i.e., child component) in the data [comp.desc|comp.order|branch.child;branch.require;branch.desc]. The corresponding statement is queried using the subcomponent ID as a label. After obtaining the statement, the priority of the statement is determined. The priority of the next statement to be executed is set to the statement, and the next component is executed according to the correct branch flow diagram configured by the web terminal.

[0109] When the loop component is reached, in addition to the initialization context component mentioned above, the context of the statement is retrieved and the context address of the next statement to be executed is set to it, thus entering the loop context. Then, when the loop context reaches the LoopEnd component, the context address of the previous statement is retrieved and set to it, thus exiting the loop context.

[0110] When implementing a call flow, if you encounter a multi-branch component, such as Menu 1 at the beginning, it is divided into invalid input, response timeout, and button 1 (users can configure more in actual situations). Multiple branch data will be appended to the data in the following format:

[0111]

comp.desc|comp.order|branch1.child;branch1.require;branch1.desc;branch2.child;branch2.require;branch2.desc;branch3.child;branch3.require;branch3.desc

[0112] The corresponding application will analyze the caller's keystrokes to determine whether they meet the conditions. Then, it will find the corresponding child component ID in the corresponding branch and search for the corresponding statement to complete the jump. The same operation process applies to other multi-branch components.

[0113] The embodiment of the present invention provides an IPPBX-based custom call flow implementation system, comprising a web terminal, middleware, and an IPPBX. Users can customize the call flow design for any call number within the web terminal's visual interface. This call flow design includes multiple components and the connections between them. Through visual operation, flexible call flow configuration is achieved, reducing user learning curves and improving the efficiency of custom call flow design. The system also offers excellent scalability, supporting a large number of call function components while also providing components tailored to more specialized developers.

[0114] Furthermore, the middleware, acting as a bridge between the web terminal and the IPPBX, first obtains the customized call flow design from the web terminal, stores the JSON in JSON format, and updates the call number of the user-customized call flow design to the call flow configuration container through the IPPBX. After the IPPBX receives a call request, if the call number carried in the call request is in the call flow configuration container, it loads the JSON data corresponding to the call number into the middleware. The JSON data is divided into an initialization context and a loop context based on the component type in the JSON data. The initialization context and loop context are translated according to a preset translation module to obtain the customized call plan and implement the call flow according to the call plan. The IPPBX uses dynamic loading to obtain JSON data from the middleware, which increases the number of configurable call flows and reduces the IPPBX's memory usage.

[0115] Based on the above embodiment, the IPPBX is further configured to perform the following steps c1 to c3:

[0116] Step c1, after translating the JSON data into a call plan, using the translated call plan as the call plan corresponding to the second call number, and caching the call plan corresponding to the second call number in a call process design container.

[0117] Step c2 determines the reference count of the call plan corresponding to the second call number to be 1.

[0118] Step c3: If a call request carrying a second call number is received again, the call process is directly implemented according to the call plan corresponding to the second call number cached in the call process design container, and the reference count of the call plan corresponding to the second call number is increased according to the number of call requests.

[0119] Specifically, the call plan corresponding to the second call number is cached in the call flow design container (CFD container) for subsequent repeated call hits, reducing the number of interactions between the IPPBX and the middleware and improving call flow execution efficiency. Since the call plan corresponding to the second call number is cached for the first time, its reference count is set to 1 and incremented based on the number of call requests. Assuming there are 10 incoming call requests for the second call number at the same time, the reference count of the call plan corresponding to the second call number is incremented by 10 to facilitate subsequent lifecycle management of the call plan in the CFD container.

[0120] Based on the above embodiment, before requesting the middleware for the JSON data corresponding to the second call number, the IPPBX is further configured to execute steps d1 to d3:

[0121] Step d1: searching the call flow design container through the second call number to see whether a call plan corresponding to the second call number has been cached.

[0122] Step d2: If the call plan corresponding to the second call number has been cached in the call flow design container, the call flow is directly implemented according to the cached call plan corresponding to the second call number.

[0123] Step d3: Increase the reference count of the call plan corresponding to the second call number in the call process design container by 1.

[0124] Specifically, in order to improve the execution efficiency of the call process, before interacting with the middleware, the IPPBX first searches its local call process design container (CFD container) to see whether the call plan corresponding to the second call number has been cached. If the CFD container has cached the call plan corresponding to the second call number, it means that the call process of the second call number has been started. The call process is directly implemented according to the cached call plan corresponding to the second call number, and the reference count of the call plan corresponding to the second call number is updated so that the subsequent steps can perform life cycle management on the call plan in the CFD container.

[0125] Based on the above embodiment, the IPPBX is further configured to perform the following steps e1 and e2:

[0126] Step e1: traverse the call plans cached in the call flow design container through the call flow configuration management thread.

[0127] Step e2: for each call plan cached in the call flow design container, monitor whether the Web terminal has deleted the call flow design corresponding to the call plan. If the Web terminal has deleted the call flow design corresponding to the call plan, delete the call plan.

[0128] Specifically, this implementation method is to perform lifecycle management on the call plans cached in the call process design container, traverse the call plans cached in the call process design container through the call process configuration management thread, and monitor whether the Web terminal has deleted the call process design corresponding to the call plan. If it has been deleted, it means that the user has not currently customized the call plan. In order to improve the execution accuracy of the call process and reduce the memory usage of the IPPBX, the call plan is deleted.

[0129] On the basis of the above embodiment, as an implementation of the embodiment of the present invention, the IPPBX is further configured to perform the following steps f1 and f2:

[0130] Step f1: for each call plan cached in the call flow design container, determine through the call flow configuration management thread whether the time difference between the current time and the creation time of the call plan is greater than a preset time.

[0131] Step f2: If the time difference between the current time and the creation time of a call plan is greater than the preset time, determine whether the reference count of the call plan is less than 2. If the reference count is less than 2, delete the call plan from the call process design container.

[0132] Specifically, this implementation method also performs lifecycle management on the call plans cached in the call process design container. If it is determined that the time difference between the current time and the creation time of a call plan is greater than the preset time, it means that the call plan has been created for a long time. In order to determine whether the call plan is still useful, it is further determined whether the reference count of the call plan is less than 2. If it is determined that the reference count is less than 2, it means that the call plan is currently useless. In order to reduce the memory usage of the IPPBX, the call plan is deleted.

[0133] In order to describe the solution clearly, the entire process of call plan life cycle management will be described in detail below. Figure 4 As shown, the following process may be included:

[0134] 1. Create a CFD management thread and traverse the CFD container at regular intervals. The interval period can be configured (1~5s)

[0135] 2. Get the next CFD object (i.e., call plan). If not, return to step 1.

[0136] 3. Determine whether the CFD object has been forcibly deleted (whether the Web terminal has executed CFD deletion). If so, delete the call plan from the CFD container, set the reference count to -1, and skip to step 2. Otherwise, go to step 4.

[0137] 4. Determine whether the TTL period of the CFD object has expired. Specifically, the TTL period is the current time minus the creation time of the call plan. Determine whether the TTL period has an expiration time set. If yes, proceed to step 5. Otherwise, skip to step 2.

[0138] 5. Determine whether the reference count of the CFD object is greater than 2. If so, jump to step 2; if not, delete the call plan from the CFD container, and the reference count is -1, jump to step 2.

[0139] By managing the lifecycle of the call plan in the CFD container, you can improve the execution accuracy of the call process and reduce the memory usage of the IPPBX. Delete the call plan.

[0140] An embodiment of the present invention further provides a method for implementing a custom call flow based on an IPPBX, which is applied to a custom call flow implementation system based on an IPPBX. The system includes a Web terminal, middleware, and an IPPBX. The method includes:

[0141] The web terminal obtains a call flow design customized by the user for the first call number, the call flow design including a plurality of nodes and a connection relationship between the plurality of nodes, each node representing a component, attribute information of each component including a component ID, a component description, and branch content, the branch content including a subcomponent ID, a requirement type, and a subcomponent description; component types are divided into basic context types and common component types, and initialization components and loop components belong to the basic context type;

[0142] The middleware obtains the call flow design, converts the call flow design into JSON data, saves the JSON data, and notifies the IPPBX to update the first call number into the call flow configuration container;

[0143] The IPPBX receives a call request from the caller, and if the second call number carried in the call request is in the call flow configuration container, requests the middleware for JSON data corresponding to the second call number, translates the JSON data into a call plan, and implements the call flow according to the call plan;

[0144] The IPPBX translates the JSON data into a call plan, including:

[0145] Determine the initialization context and loop context based on the component type in the JSON data; the initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components;

[0146] The initialization context and the loop context are translated according to a preset translation module, and the translation result is used as a call plan. The preset translation module includes the second call number, priority and component attribute information.

[0147] The embodiment of the present invention further provides an electronic device, such as Figure 5 As shown, the system according to the first aspect is installed, including:

[0148] at least one processor 501;

[0149] a memory 502 for storing the at least one processor-executable instruction;

[0150] The at least one processor is configured to execute the instructions to run the system of the above embodiment.

[0151] An embodiment of the present invention further provides a computer-readable storage medium. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to run the system of the above embodiment.

[0152] An embodiment of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, the system of the above embodiment is executed.

[0153] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention without departing from the principles and purpose of the present invention.

Claims

1. A custom call flow implementation system based on IPPBX, characterized in that: The system includes a Web terminal, middleware and an Internet telephone switch IPPBX; The web terminal is used to obtain a call flow design customized by the user for the first call number, the call flow design including multiple nodes and connection relationships between the multiple nodes, each node representing a component, attribute information of each component including a component ID, a component description, and branch content, the branch content including a subcomponent ID, a requirement type, and a subcomponent description; component types are divided into basic context types and common component types, and initialization components and loop components belong to the basic context type; The middleware is used to obtain a call flow design, convert the call flow design into JSON data, save the JSON data, and notify the IPPBX to update the first call number into the call flow configuration container; The IPPBX is configured to receive a call request from a caller, and if a second call number carried in the call request is in the call flow configuration container, request the middleware for JSON data corresponding to the second call number, translate the JSON data into a call plan, and implement the call flow according to the call plan; The IPPBX translates the JSON data into a call plan, including: Determine the initialization context and loop context based on the component type in the JSON data; the initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components; The initialization context and the loop context are translated according to a preset translation module, and the translation result is used as a call plan. The preset translation module includes the second call number, priority and component attribute information.

2. The system according to claim 1, wherein: The IPPBX is also used to: After translating the JSON data into a call plan, using the translated call plan as the call plan corresponding to the second call number, and caching the call plan corresponding to the second call number in a call flow design container; Determine the reference count of the call plan corresponding to the second call number to 1; If a call request carrying the second call number is received again, the call process is implemented directly according to the call plan corresponding to the second call number cached in the call process design container, and the reference count of the call plan corresponding to the second call number is increased according to the number of call requests.

3. The system according to claim 1, wherein: Before requesting the middleware for the JSON data corresponding to the second calling number, the IPPBX is further configured to: Searching the call flow design container through the second call number to determine whether a call plan corresponding to the second call number has been cached; If the call plan corresponding to the second call number has been cached in the call flow design container, the call flow is directly implemented according to the cached call plan corresponding to the second call number; The reference count of the call plan corresponding to the second call number in the call process design container is increased by 1.

4. The system according to claim 2 or 3, characterized in that The IPPBX is also used to: Through the call flow configuration management thread, traverse the call plans cached in the call flow design container; For each call plan cached in the call flow design container, monitor whether the Web terminal has deleted the call flow design corresponding to the call plan; if the Web terminal has deleted the call flow design corresponding to the call plan, delete the call plan.

5. The system according to claim 2 or 3, characterized in that The IPPBX is also used to: For each call plan cached in the call flow design container, determining, through the call flow configuration management thread, whether the time difference between the current time and the creation time of the call plan is greater than a preset time; If the time difference between the current time and the creation time of a call plan is greater than the preset time, determine whether the reference count of the call plan is less than 2. If the reference count is less than 2, delete the call plan from the call process design container.

6. The system according to any one of claims 1 to 3, characterized in that The IPPBX is also used to: After receiving a call request from a caller, parsing the call request to obtain a calling number carried in the call request; Determining whether the calling number carried in the call request is in the call flow configuration; If the calling number carried in the call request is not in the call process configuration, the preset normal dialing process is entered.

7. The system according to any one of claims 1 to 3, characterized in that The IPPBX implements the call process according to the call plan, including: Enter the initialization context and run each component in the order included in the initialization context. After each component finishes running, find the attribute information of its subcomponents and run the subcomponents. After the subcomponents finish running, run the next component of the component, and execute all components of the initialization context. Enter the loop context, run the loop components and common components included in the loop context, and exit the loop context when the loop end component is reached.

8. A method for implementing a custom call flow based on IPPBX, characterized in that: The method is applied to a custom call flow implementation system based on IPPBX, the system including a Web terminal, middleware and an IPPBX. The web terminal obtains a call flow design customized by the user for the first call number, the call flow design including a plurality of nodes and a connection relationship between the plurality of nodes, each node representing a component, attribute information of each component including a component ID, a component description, and branch content, the branch content including a subcomponent ID, a requirement type, and a subcomponent description; component types are divided into basic context types and common component types, and initialization components and loop components belong to the basic context type; The middleware obtains the call flow design, converts the call flow design into JSON data, saves the JSON data, and notifies the IPPBX to update the first call number into the call flow configuration container; The IPPBX receives a call request from the caller, and if the second call number carried in the call request is in the call flow configuration container, requests the middleware for JSON data corresponding to the second call number, translates the JSON data into a call plan, and implements the call flow according to the call plan; The IPPBX translates the JSON data into a call plan, including: Determine the initialization context and loop context based on the component type in the JSON data; the initialization context includes initialization components, common components, and loop components, and the loop context includes loop components and common components; The initialization context and the loop context are translated according to a preset translation module, and the translation result is used as a call plan. The preset translation module includes the second call number, priority and component attribute information.

9. An electronic device, characterized in that: A system according to any one of claims 1 to 7 is installed, comprising: at least one processor; a memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to run the system according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to run the system according to any one of claims 1 to 7.

Images